8 rxgk is a new crypto class, mostly since the interface need to
9 be changed in the ktc for openafs anyway (at least binary
12 rxgk (krb5) can be used when the kdc returns a non des enctype.
16 There are two layer, the transport layer that is authentiation
17 mechamism independent, and the authentiation layer.
19 The glue between the authentiation layer and the transport
20 layer is the RXGK authenticator.
24 The only reson for the RXGK authenticator exists is that there
25 are not fragmentation in the Challange/Response protocol in
26 Rx. This limits the authentization in Rx to MTU sized packages.
28 - RXGK authenticator lifetime
30 The server has a local key that is used to encrypt the gk
31 authenticators. The local key is semi stateful, the
32 server need to remember the old keys al long as there are
33 valid RXGK authenticators held by any client. New RXGK
34 authenticators can be fetched at any time but might require
37 - Getting RXGK authenticator
39 the authenticator is fetched using a service rx_null on the
40 same port as the server the client wants to talk too.
47 Each connection get separate key for each connection/epoch.
48 Each direction get a separate key for each direction.
52 counter = key generation (nonce)
53 K{server} = Key from server direction
54 K{client} = Key from client direction
56 X{cn} = epoch{32} | cid{32} | key_counter{64}
58 CN = random-to-key(pseudo-random(S, X{cn})
60 K{server} = KD(CN, 0) { key used on data from server }
61 K{client} = KD(CN, 1) { key used on data from client }
63 Checksum field in the header (spare1) is always set to the
64 lower 4 bits of the key_counter field. Ie server may not
65 request rekeying faster the (4 * rc_max_seq_skew) packets.
67 K depends on {S,epoch,cid,key_counter}
71 Rekeing is needed since kcrypt assumes that data isn't
72 encrypted for the 2**48 messages with the same key.
76 When the client is unknown to the server it sends a challenge
77 with opcode RXKG_OPCODE_CHALLENGE (nonce).
79 The client the send back a rxgk authenticator and the
86 Each packet are encrypted as [KCRYPTO] specifies. The data is
87 prefixed with parts of the rx header that matter.
91 Each packet are checksumed as [KCRYPTO] specifies. The data is
92 prefixed with parts of the rx header that matter [4]. In auth
93 mode the rx header subsitute is not sent over write to save
96 The part of the header that is checksumed are these fields:
102 uint8_t someflags (RX_PRESET_FLAGS)
110 To be later specified.
112 There is an information API to, with a RXGK authenticator, the
113 client can verify what authentiation mechamisms is supported,
114 both insecure and authenticated.
116 - Kerberos 5 to rxgk authenticator RPCs
118 key{KerbS} - kerberos session subkey key
120 The mutual auth data in the RXGK_EstablishKrb5Context is
121 encrypted with the key{KerbS} key.
123 Client sends acceptable enctypes and nonce to the server in
126 Server sends back key(auth-cred-key) and nonce + 1 to the
127 client together with a RXGK authenticator cred encrypted with
130 auth-cred is protected by key{gkkey}
132 key{S} = key{auth-cred-key}
134 - GSS-API to rxgk authenticator RPCs
136 To be later specified.
144 gkkey@L.NXS.SE and afs@L.NXS.SE key exists in default keytab
147 implementation/higher level issues
150 - RXGK_AUTH_CRED needs checking
152 [ 2. should we use the session key or the a random octet
153 string generatated by the server, the key(auth-cred-key) below ]
155 [ 3. ac_principal: gss exported name ? this to make it idependant
156 of kerberos 5. Problem with gss name only specifed gss-mechs
157 can be used. Server local so it can really be anything the
158 server wants it to be. Need to be kept short so it will fit on
159 one MTU. Also see {{10}}. ]
161 The RXGK authenticator is fetch by doing either the RXGK
162 GSSAPI rpc's or the RXGK_EstablishKrb5Context rpc to the RXGK
163 service on the same port as the service that rxgk
164 secures. Doing the RPC call gives you a gk authenticator and a
165 key(S) that is valid for one server. The input to GSSAPI rpc
166 and EstablishKrb5Context are mech specific.
169 [ 11. see rxgss how this should me implemented ... ]
173 all mech's need to have a rxgk name to krb4 name function
174 until pts is changed to support rxgk names.
176 [ 10. Proposal: the protection interface have GKNAME to
179 In this proposal all names are mapped to one AFS username.
181 For example, gss exported named KRB5:lha@SU.SE, krb5 native
182 lha@SU.SE and krb5 native krb5 lha@KTH.SE all map to the same
193 - Pass length since krb encryption doesn't preserve length (some enctypes does)
195 [ 8. Is this really needed, packets are always send full ]
199 More the MTU since rpcs
200 Stored packets packets, compare generate packages
206 - Diffrent keys for fileservers
208 I think we should ignore this for rxgk/kerberos 5 or do
209 "fileserver groups" as discuss on Pittsburgh so this will
210 happen. For "fileserver groups" a get groups rpc should be
211 added to the vlserver (this will make non rx afslogs harder
212 to implement) and in the first version we just insert a rpc
213 stub that return one name only, "default", or something
216 The reson you want to have diffrent keys for fileservers are
218 - increased security (more keys, less data encrypted with the
219 same key, one server compromised doesn't compromise all servers)
221 - give a fileserver to someone else that you not trust
222 to have the master key
224 Depricated since we can get consensus, rxgk/gssapi will/must solve