[AFS3-std] updates from last call comments on draft-wilkinson-afs3-rxgk-afs-04

Benjamin Kaduk kaduk@MIT.EDU
Wed, 1 May 2013 11:09:36 -0400 (EDT)


In response to the comments made during the last-call period on this 
draft, I made some changes in my git repository, which are included inline 
below.  Please let me know if you think your comment(s) have not been 
addressed either in an email reply or the changes below.

I have not attempted to rewrite the description of the GSS negotiation 
loop for clarity.  Looking at RFC 4462 (ssh gssapi keyex) for inspriation, 
it seems that the flow of description is largely similar, but the RFC's 
formatting is more spread out and helps readability.  They have the luxury 
of being able to describe the messages sent in each direction on a 
per-message basis, after the outline of the GSS control flow.  Our control 
flow does not have a persistent connection, and the client drives the loop 
using the GSSNegotiate RPC; I think it would be confusing to excise the 
actual message passing portions to the end of the description as is done 
in the ssh RFC.

Reformatting could go hand-in-hand with adding subsections for the key 
negotiation section, but I'd like to hear from the chairs that it's worth 
the time before I go and do that.  ("The document is going to need another 
last call" will be considered to imply "it's worth doing the work to 
reformat".)

-Ben



git log -p --reverse:
commit 3a37c19e09df3241d16a1508ad62fabf5dc8367f
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Fri Apr 26 18:59:05 2013 -0400

     Correct omissions in GSS loop description

     Change-Id: Iba911f65d995be30596e4b2131d574acbacfa850

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index d2cd9f2..19829c3 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -289,7 +289,10 @@ enum RXGK_Level {
             terminates.  If the major status code is GSS_S_COMPLETE and the
             output token is zero length, this is a success condition and
             the negotiation loop terminates (this cannot happen on the first
-           iteration of the loop).  Otherwise, if the major status code
+           iteration of the loop).  If the major status code is GSS_S_COMPLETE
+           and the output token is of nonzero length, the negotiation loop
+           proceeds and the token is sent to the server.
+           Otherwise, if the major status code
             does not include GSS_S_CONTINUE_NEEDED, the negotiation loop
             is in an error condition and terminates.  If the major status code
             includes GSS_S_CONTINUE_NEEDED, the output token is sent to the
@@ -304,8 +307,13 @@ enum RXGK_Level {
             GSS_S_CONTINUE_NEEDED, the server also returns an opaque identifier
             in the opaque_out field of the RPC, which will allow the server to
             associate a future RPC call with this partially formed
-           security context.  If the major status code is GSS_S_COMPLETE,
-           the server constructs an RXGK_ClientInfo structure per below.</t><t>The client receives the results of the GSSNegotiate() RPC.
+           security context.  If the major status code is GSS_S_COMPLETE
+           and the ret_flags output of GSS_Accept_sec_context() has the flags
+           GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG both set to true,
+           the server constructs an RXGK_ClientInfo structure per below.
+           If one or both of these flags are false, then negotiation has
+           failed and will be indicated by the server returning a major
+           status code of GSS_S_BAD_QOP.</t><t>The client receives the results of the GSSNegotiate() RPC.
             If the major status code is not GSS_S_COMPLETE and does not
             include GSS_S_CONTINUE_NEEDED, the negotiation loop is in an error
             condition and terminates.  If the most recent call to

commit 58df95ba56b289934c7e7283d6f03f9c69b926e9
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:35:56 2013 -0400

     tweak limits for variable-length arrays

     Change-Id: Ia2253fd64d6d0fe44c575bb961a02ba68aa808df

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 19829c3..5b8a176 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -182,9 +182,9 @@ enum RXGK_Level {
        <figure>
          <artwork>
      /* limits for variable-length arrays */
-    const RXGK_MAXENCTYPES = 10;
-    const RXGK_MAXLEVELS = 10;
-    const RXGK_MAXMIC = 16384;
+    const RXGK_MAXENCTYPES = 255;
+    const RXGK_MAXLEVELS = 255;
+    const RXGK_MAXMIC = 1024;
      const RXGK_MAXNONCE = 1024;

      typedef int RXGK_Enctypes&lt;RXGK_MAXENCTYPES&gt;;

commit 64e97bf3052dff2e614f8772af3fd6013f03bf57
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:38:31 2013 -0400

     tweak max authenticator size to match comment

     Change-Id: I222ed85d32388a227feb52efc807084447beda70

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 5b8a176..c2ebb7d 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -617,7 +617,7 @@ enum RXGK_Level {
          <t>The rxgk response is an XDR encoded structure, with the following
         signature:
  <figure><artwork>
-    const RXGK_MAXAUTHENTICATOR = 1500	/* better fit in a packet! */
+    const RXGK_MAXAUTHENTICATOR = 1416	/* better fit in a packet! */
      struct RXGK_Response {
          rxgkTime start_time;
          RXGK_Data token;

commit 2953fd7cb8e53d1523405be368f019369ba6fdfe
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:28:22 2013 -0400

     Reword intro a bit

     We do describe many integration details.

     Change-Id: Ie68b0c04b8b9646df0e5d7d1523b790e1623ada2

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index c2ebb7d..1779bd1 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -36,9 +36,9 @@
         framework to provide an authentication service that provides
         authentication, confidentiality and integrity protection for the
         rxgk security class.
-       This document provides a general description of rxgk. A
-       further document will provide details of integration with specific
-       RX applications. </t>
+       This document provides a general description of rxgk and how to
+       integrate it into generic RX applications. Application specific
+       behaviour will be described, as necessary, in future documents.</t>
      </abstract>
    </front>
    <middle>

commit fc9460c78a01fac05b369afbb1502e957754ba75
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:33:36 2013 -0400

     xref rfc3961 for kerberos crypto

     Change-Id: Ida8be508b9bb19fe34199f7180c7e0b3af0fb6c9

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 1779bd1..0c36107 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -55,7 +55,8 @@
       on the wire and in the code fragments contained within this document. </t>
        <t>Architecturally, rxgk is split into two parts. The rxgk rx security
       class provides strong encryption using previously negotiated ciphers and
-     keys. It builds on the Kerberos crypto framework for its encryption 
+     keys. It builds on the Kerberos crypto framework <xref target="RFC3961" />
+     for its encryption
       requirements, but is authentication mechanism independent -- the class
       itself does not require the use of either Kerberos, or GSSAPI. The
       security class simply uses a previously negotiated encryption type, and

commit 721c82ae76e7279d8bc277fbc0440b0424f23270
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:33:55 2013 -0400

     detabify key usage values

     Change-Id: I33db4cb49fe7bd5137872d05f21d401f571d2b2f

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 0c36107..d7f167b 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -100,12 +100,12 @@ typedef hyper rxgkTime;
         space documented in section 4 of <xref target="RFC4120">RFC4120</xref>.

  <figure><artwork>
-const RXGK_CLIENT_ENC_PACKET		= 1026;
-const RXGK_CLIENT_MIC_PACKET		= 1027;
-const RXGK_SERVER_ENC_PACKET		= 1028;
-const RXGK_SERVER_MIC_PACKET		= 1029;
-const RXGK_CLIENT_ENC_RESPONSE		= 1030;
-const RXGK_SERVER_ENC_TOKEN		= 1036;
+const RXGK_CLIENT_ENC_PACKET            = 1026;
+const RXGK_CLIENT_MIC_PACKET            = 1027;
+const RXGK_SERVER_ENC_PACKET            = 1028;
+const RXGK_SERVER_MIC_PACKET            = 1029;
+const RXGK_CLIENT_ENC_RESPONSE          = 1030;
+const RXGK_SERVER_ENC_TOKEN             = 1036;
  </artwork></figure>

         The application of these key usage numbers is specified in

commit 84679fcbe88ece0e30ec7da66dbf6f35fecc022a
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:34:11 2013 -0400

     wordsmith client usage of token

     Change-Id: Ieda8ad43f276bfb03864d39d01cedfd6060031f9

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index d7f167b..e825498 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -145,7 +145,8 @@ enum RXGK_Level {
      <section anchor="tokens" title="Token Format">
        <t>An rxgk token is an opaque identifier which is specific to a particular
       application's implementation of rxgk. The token is completely opaque to
-     the client, which just transmits it from server to server. The token MUST
+     the client, which just receives it from one server and passes it
+     to another. The token MUST
       permit the receiving server to identify the corresponding user and session
       key for the incoming connection -- whether that be by decrypting the
       information within the token, or making the token a large random

commit c6c9a639da8575fde24a9bd402574f6cadfb69ec
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:35:13 2013 -0400

     Clarify GSS loop overview and reference service name generation

     Change-Id: I2dac599ed44d9ea3b3ee99990dd3dab5e0517841

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index e825498..e97d993 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -163,7 +163,7 @@ enum RXGK_Level {
       by observing other connections. An attacker MUST NOT be able to forge
       tokens which convey a particular session key or identity.</t>
      </section>
-    <section title="Key Negotiation">
+    <section title="Key Negotiation" anchor="keyneg">
        <t>rxgk uses an independent RX RPC service for key negotiation. The
         location of this service is application dependent. Within a given
         application protocol, a client MUST be able to locate the key
@@ -249,8 +249,10 @@ enum RXGK_Level {
   	 at their earliest convenience.</t><t hangText="client_nonce:">A client-generated string of random bytes,
  	 to be used as input to the key generation.  This nonce SHOULD
  	 be at least 20 octets in length.</t></list>
-       The client then calls GSS_Init_sec_context() to obtain an output token
-       to send to the server. The GSS service name is application dependent.</t>
+       The client then continues the negotiation loop (described below) by
+       calling GSS_Init_sec_context() to obtain an output token
+       to send to the server. The GSS service name is application dependent;
+       for constructing a service name see <xref target="keyneg" />.</t>
        <t>The client then calls RXGK_GSSNegotiate, as defined above. This takes
         the following parameters:
      <list style="hanging" hangIndent="6"><t hangText="client_start">The client params structure detailed above.

commit b4aae69564e8a470315322c3c3ded9a8415927c3
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:36:43 2013 -0400

     Be descriptive about StartParams' invariance

     Change-Id: I9b46f019e66f76613eae69156194cc110331a71f

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index e97d993..c73226d 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -256,7 +256,7 @@ enum RXGK_Level {
        <t>The client then calls RXGK_GSSNegotiate, as defined above. This takes
         the following parameters:
      <list style="hanging" hangIndent="6"><t hangText="client_start">The client params structure detailed above.
-        This should remain constant across the negotiation.</t><t hangText="input_token_buffer">The token produced by a call to
+        This will remain constant across the negotiation.</t><t hangText="input_token_buffer">The token produced by a call to
  	GSS_Init_sec_context().</t><t hangText="opaque_in">An opaque token, which was returned by the
  	server following a previous call to GSSNegotiate in this negotiation.
  	If this is the first call, opaque_in should be zero-length.</t><t hangText="output_token_buffer">The token output by the server's call

commit 6a6f8c9bff860e615507505c53df4a3c460d64bc
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:37:16 2013 -0400

     condense the three GSS flags needed

     Change-Id: Ifadef2bebefcd4021711aed074ff1b939fa78032

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index c73226d..f944601 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -283,13 +283,11 @@ enum RXGK_Level {
         <list style="hanging" hangIndent="6"><t>The client calls GSS_Init_sec_context(), supplying an input token
             if one was returned by a previous call to GSSNegotiate().
             The client MUST set the mutual_req_flag, conf_req_flag, and
-           integ_req_flag booleans to true.</t><t>If the major status code from GSS_Init_sec_context() includes a
-           fatal error code, the negotiation loop is in an error condition and
+           integ_req_flag booleans to true.</t><t>If the major status code from GSS_Init_sec_context() indicates
+           a GSSAPI error, the negotiation loop is in an error condition and
             terminates.  If the major status code is GSS_S_COMPLETE
-           and the mutual_state flag is not true, or the major status code
-           is GSS_S_COMPLETE and the conf_avail flag is not true, or the
-           major status code is GSS_S_COMPLETE and the integ_avail flag is
-           not true, the negotiation loop is in an error condition and
+           and the mutual_state, conf_avail integ_avail flags are not all
+           true, the negotiation loop is in an error condition and
             terminates.  If the major status code is GSS_S_COMPLETE and the
             output token is zero length, this is a success condition and
             the negotiation loop terminates (this cannot happen on the first

commit 611871a9e79f803311c7de4777c843a31a27bb04
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:37:27 2013 -0400

     Remove unneeded statement

     The next GSS call will detect this error; we don't need to do it
     ourselves (though we could if we wanted to).

     Change-Id: I13ce08a2b806c4f17a56cbed3bc9ae9d8b4817ca

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index f944601..83e01b0 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -321,10 +321,7 @@ enum RXGK_Level {
             condition and terminates.  If the most recent call to
             GSS_Init_sec_context() returned the major status code
             GSS_S_COMPLETE and an output token, the negotiation loop is in a
-           success condition and terminates.  If the most recent call to
-           GSS_Init_sec_context() returned a major status code including
-           GSS_S_CONTINUE_NEEDED and the output_token_buffer is zero length,
-           the negotiation loop is in error and terminates.  Otherwise,
+           success condition and terminates.  Otherwise,
             the client proceeds to begin the next cycle of the negotiation
             loop.</t></list>
         In general, an error condition at the server

commit ce35a4be0b7124d15fbe4cc925b2cde6f37e5c65
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:38:09 2013 -0400

     clarify that conf_state is returned by gss_unwrap()

     Change-Id: Iec329b113bddb0a71e1b0a33d385bd9c70791461

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 83e01b0..757d77e 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -334,7 +334,8 @@ enum RXGK_Level {
         the XDR representation of a
         RXGK_ClientInfo structure, encrypted using gss_wrap() with
         confidentiality protection. The client should decrypt this structure
-       using gss_unwrap().  If the returned value of conf_state is zero,
+       using gss_unwrap().  If the value of conf_state returned from
+       gss_unwrap() is zero,
         the negotiation has failed.</t>
        <t>RXGK_ClientInfo contains the following server populated
         fields:

commit 61e39c2f08717acdb2749e15cbe8b3f9c1085016
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:38:50 2013 -0400

     Reword security considerations for client_nonce

     The MIC of the StartParams structure (which contains the client_nonce)
     is returned to the client in an encrypted structure, so a
     direct man-in-the-middle downgrade attack on the starting parameters
     is not possible.  Uniqueness of the structure can still be useful, though.

     Change-Id: Ife0d175a49828fcf906b0fbde062331ba10e276e

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 757d77e..412990f 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -912,8 +912,7 @@ end
  	   serve slightly different purposes.  A random nonce is also
  	   used in the challenge-response authentication protocol, which
  	   serves yet a different purpose.</t>
-        <t>The client_nonce is important for using the MIC of the StartParams
-	   structure as a defense against man-in-the-middle attacks,
+        <t>The client_nonce ensures that the StartParams structure is unique,
  	   and should be long enough that the client will not generate
  	   collisions within the lifetime of a given set of GSS credentials.
  	   The client_nonce also contributes to the uniqueness of the

commit 7833535f62d9a8d9f8a4998e87dac2f986f0d6ff
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Mon Apr 29 21:48:58 2013 -0400

     Roll changelog

     Change-Id: I3a0f2125350468c9347e60836a1c901609154d62

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 412990f..0d7f943 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -1041,6 +1041,10 @@ end
          <t>Use abstract GSSAPI routine names, not the C binding names.</t>
          <t>Discuss packet handling for received packets.</t>
        </section>
+      <section title="Since 04">
+        <t>Correct omissions from description of GSS negotiation loop.</t>
+        <t>Adjust limits on variable-length array lengths.</t>
+      </section>
      </section>
    </back>
  </rfc>

commit 30d29268d7d0830db29be7022ba37a4dee0235fa
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Tue Apr 30 22:13:21 2013 -0400

     Add xref for rekeying on advisory lifetimes

     To just say "this is advisory" is not very useful, but we do have
     text to describe what happens when the the lifetimes are surpassed.

     Change-Id: I414aa048ab2ba44054d6b3ab0d8bfdf69479cb69

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 0d7f943..f62de69 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -238,7 +238,8 @@ enum RXGK_Level {
  	 levels. See <xref target="levels"/> for allowed values.</t><t hangText="lifetime:">The maximum number of seconds that a connection
  	 key should be used before rekeying. A value of 0 indicates that the
  	 connection should not be rekeyed based on its lifetime. This lifetime
-         is advisory.</t><t hangText="bytelife:">The maximum amount of data to be transferred
+         is advisory; <xref target="rekeying" /> describes its use.</t>
+         <t hangText="bytelife:">The maximum amount of data to be transferred
  	 over the connection before it should be rekeyed, expressed as
  	 log base 2 of the number of bytes. A
   	 value of 0 indicates that there is no limit on the number of
@@ -246,7 +247,10 @@ enum RXGK_Level {
  	 connection that is over its byte lifetime should be permitted to
  	 continue, but endpoints SHOULD attempt to rekey the connection
  	 (as per <xref target="rekeying" />)
- 	 at their earliest convenience.</t><t hangText="client_nonce:">A client-generated string of random bytes,
+ 	 at their earliest convenience.  The use of the bytelife to determine
+	 when to rekey a connection is described in <xref target="rekeying" />
+	 along with the lifetime.</t>
+       <t hangText="client_nonce:">A client-generated string of random bytes,
  	 to be used as input to the key generation.  This nonce SHOULD
  	 be at least 20 octets in length.</t></list>
         The client then continues the negotiation loop (described below) by

commit 0e9d82085a658800c964f74edef9a4e6b89fcb29
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Wed May 1 10:22:44 2013 -0400

     Mention 'rxkad' with 'traditional'

     Change-Id: I9e5b2f2cd6ba2d2fd3b5cd0899d71c9618251356

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index f62de69..7037ecc 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -121,12 +121,13 @@ const RXGK_SERVER_ENC_TOKEN             = 1036;
  	 authentication, without either integrity or confidentiality
  	 protection. This mode of operation can provide higher throughput, but
  	 is vulnerable to man in the middle attacks. This corresponds
- 	 to the traditional 'clear' security level.</t><t hangText="Integrity"> (1) Provides integrity protection only. 
+ 	 to the traditional rxkad 'clear' security level.</t>
+         <t hangText="Integrity"> (1) Provides integrity protection only.
  	  Data is protected from modification by an attacker, but not against 
-	  eavesdropping. This corresponds to the traditional 'auth' security
+	  eavesdropping. This corresponds to the traditional rxkad 'auth' security
  	  level, authenticating the data payload as well as the Rx connection.</t><t hangText="Encryption"> (2) Provides both integrity and
  	  confidentiality protection. This corresponds to the traditional
-	  'crypt' security level.</t></list>
+	  rxkad 'crypt' security level.</t></list>
       The authentication only, or clear, security level provides faster
       throughput, at the expense of connection security.  The 'clear'
       security level is vulnerable to a man in the middle altering the data

commit 890b7c951c45f0ac6d0daaf815b428ed32d6968a
Author: Ben Kaduk <kaduk@mit.edu>
Date:   Wed May 1 10:44:37 2013 -0400

     Put a limit on the length of an RXGK_Data

     Change-Id: I34f8d67cb5354b89c8bcab8e6bdde121fa6753c2

diff --git a/src/rxgk/draft-wilkinson-afs3-rxgk.xml b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
index 7037ecc..0648ea4 100644
--- a/src/rxgk/draft-wilkinson-afs3-rxgk.xml
+++ b/src/rxgk/draft-wilkinson-afs3-rxgk.xml
@@ -181,7 +181,10 @@ enum RXGK_Level {
         construct the target principal name as
         &lt;service name&gt;@&lt;hostname&gt; using the name type
         GSS_C_NT_HOSTBASED_SERVICE.</t>
-      <t>The key negotiation protocol is defined by the following RPC-L:</t>
+      <t>The key negotiation protocol is defined by the RPC-L below.
+       The maximum length of data allowable in an RXGK_Data object,
+       RXGK_MAXDATA, is application-specific, but MUST NOT be less
+       than 1048576.</t>
        <figure>
          <artwork>
      /* limits for variable-length arrays */
@@ -189,9 +192,10 @@ enum RXGK_Level {
      const RXGK_MAXLEVELS = 255;
      const RXGK_MAXMIC = 1024;
      const RXGK_MAXNONCE = 1024;
+    /* const RXGK_MAXDATA = 1048576; */

      typedef int RXGK_Enctypes&lt;RXGK_MAXENCTYPES&gt;;
-    typedef opaque RXGK_Data&lt;&gt;;
+    typedef opaque RXGK_Data&lt;RXGK_MAXDATA&gt;;

      struct RXGK_StartParams {
          RXGK_Enctypes enctypes;