[AFS3-std] New Version Notification for draft-wilkinson-afs3-rxgk-04.txt (fwd)

[Benjamin Kaduk]

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 <kaduk@mit.edu>
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 <kaduk@mit.edu>
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 <kaduk@mit.edu>
Date:   Wed Mar 20 14:37:28 2013 -0400

     Security considerations on nonce lengths

     Change-Id: Iacd5db483f3a0f1953e4aa513106a6ff286a25c7

commit 43a0e9ce7bf471290fa26cf55860d33a6cac7305
Author: Ben Kaduk <kaduk@mit.edu>
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 <kaduk@mit.edu>
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 <kaduk@mit.edu>
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 <kaduk@mit.edu>
Date:   Thu Mar 21 18:02:14 2013 -0400

     wordsmith bytelife discussion

     Change-Id: I7f3c55939b2b0c2aba856830998f5a3d664497e5

commit 3b71f31726bc7cbd3974c8dec492b916ed7795b5
Author: Ben Kaduk <kaduk@mit.edu>
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 <kaduk@mit.edu>
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 <kaduk@mit.edu>
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