On Thu, 21 Mar 2013, Benjamin Kaduk wrote:
This is git revision 4a3fa6e.
I believe that this draft addresses all known issues that have been raised.
If there continues to be an absence of comments, I'll go ahead and ask the
chairs to start a last call.
Some potentially interesting changes in the history (git log --reverse,
trimmed to remove trivial stuff):
commit 36f0d81920566898704d77978bc597e5aea77a68
Author: Ben Kaduk <[email protected]>
Date: Wed Mar 20 11:35:01 2013 -0400
Improve wording for actions when bytelife exceeded
We just want to rekey, not "establish a new context", whatever
that is. Conveniently, we have a section to link to for this.
Change-Id: I210115c7b6c864729012758a367c8295b7e1c6f8
commit 9efada0c5848f0c01a0c49cfbfe395cd520e1248
Author: Ben Kaduk <[email protected]>
Date: Wed Mar 20 14:16:35 2013 -0400
Add some guidance on nonce lengths for key negotiation
The client nonce is transmitted in the clear and as such does not
really add entropy to the generated master key. It does help ensure
that the generated key is unique, e.g., if a kerberos service ticket
is used to establish multiple GSS security contexts, though.
Arguably more importantly, the client nonce also is included in the
MIC of the startparams, and as such serves to prevent a replay attack
of the returned MIC in concert with a MITM downgrade attack on the
actual StartParams received by the server.
The server nonce is wrapped in the GSS security context and does
contribute real entropy to the resultant key; however, only as many
bits of entropy as will be used for the key could possibly be useful.
Change-Id: I711d955d9767482de366b2be192dfdcc56c1fce7
commit c623f0529227d9cb4b5e0f4dbb7b6a2269480ec4
Author: Ben Kaduk <[email protected]>
Date: Wed Mar 20 14:37:28 2013 -0400
Security considerations on nonce lengths
Change-Id: Iacd5db483f3a0f1953e4aa513106a6ff286a25c7
commit 43a0e9ce7bf471290fa26cf55860d33a6cac7305
Author: Ben Kaduk <[email protected]>
Date: Wed Mar 20 14:51:10 2013 -0400
Attempt to be more clear about encrypted payloads
We call the encrypt() routine. The output bits are what goes on the
wire. Straightforward, right?
Change-Id: I5cff4fdd59926d51cbb25e7649bda8358dc13c36
commit a9177ee165352b7ceea8d1def4e8fd753bee527c
Author: Ben Kaduk <[email protected]>
Date: Wed Mar 20 15:33:24 2013 -0400
Supply bounds for variable-length arrays
Define constants and use them.
There is no limit for the RXGK_Data typedef at this time, though that
is perhaps the most important case to consider. Such a limit should
probably be merged in with a prospective limit on the generic OpenAFS
rx_opaque type.
The authenticator limit implicitly limits the appdata and call_numbers
fields, so separate limits are not needed there.
Change-Id: I40067823738aa8ff0bbf62d1706abe8924f34e3a
commit 0148161da8ec45eeea037866516932fe65639083
Author: Ben Kaduk <[email protected]>
Date: Wed Mar 20 16:53:53 2013 -0400
Use "security sensitive" buzzword for errorcode fields
GSSNegotiate and CombineTokens have errorcode fields in their return
structures, in order to hold security sensitive error codes.
That is, codes which will change the security behavior of the client
that receives them. Mention this justification where these fields are used.
Change-Id: I9f02391d2fca8ce5f0159d95688968c963bf2ac0
commit 609042d180bdc7603f5fe08e98c3fe136818fac8
Author: Ben Kaduk <[email protected]>
Date: Thu Mar 21 18:02:14 2013 -0400
wordsmith bytelife discussion
Change-Id: I7f3c55939b2b0c2aba856830998f5a3d664497e5
commit 3b71f31726bc7cbd3974c8dec492b916ed7795b5
Author: Ben Kaduk <[email protected]>
Date: Thu Mar 21 18:03:55 2013 -0400
Wordsmith GSS negotiation loop a bit
Note that we can get either one or both of an output token and
output opaque.
Change-Id: I7c8bde960c4b91561480efe0e65c93b8059560cf
commit 8779a484e6cee958c2be48a591202004a511a8c2
Author: Ben Kaduk <[email protected]>
Date: Thu Mar 21 18:07:17 2013 -0400
Reorder ClientInfo discussion slightly
Talk about errors first, then success.
Also note that the client should verify that confidentiality
protection was applied to the wrapped message.
Change-Id: I2b0ab9be31e59656f72506813953b008134a4795
commit c58cdbfbfd286e5d028204e2e5bd756313049680
Author: Ben Kaduk <[email protected]>
Date: Thu Mar 21 18:14:37 2013 -0400
Mention ReceivePacket handling
It's just the inverse of PreparePacket (basically), but we also
have to check the connection information to get the security
properties that we want.
Change-Id: I0a23fcf3f3c5849ea5afc75799540fde6516b6ee
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
