Subject: [nfsv4] [PATCH 1/7] Bump version to 08

From: <[email-masked]>
Date: Tue, 3 Jun 2014 12:52:44 -0400

From: Andy Adamson <[email-masked]>

Signed-off-by: Andy Adamson <[email-masked]>
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 6c82194..0d4bcbe 100755
--- a/Makefile
+++ b/Makefile
@@ -4,8 +4,8 @@
 YEAR=`date +%Y`
 MONTH=`date +%B`
 DAY=`date +%d`
-PREVVERS=06
-VERS=07
+PREVVERS=07
+VERS=08
 XML2RFC=/Users/andros/ietf/xml2rfc-1.36/xml2rfc.tcl
 
 autogen/%.xml : %.x
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Tue, 3 Jun 2014 12:52:43 -0400

Responding to comments from Connectathon 2014 and from IETF 89.
Still need to:
 	- review Label Assertion section
	- describe RPCSEC_GSS_LABEL_PROBLEM use

Andy Adamson (7):
  Bump version to 08
  Change Compound Authentication to Multi-principal Authentication
  Multi-principal error processing
  Structured privilege error processing
  Move Version Negotiation section
  Child handle MUST NOT be used as a parent
  Misc edits

 Makefile                            |   4 +-
 rpcsecgssv3_front.xml               |   5 +-
 rpcsecgssv3_middle_introduction.xml | 239 ++++++++++++++++++++----------------
 3 files changed, 137 insertions(+), 111 deletions(-)

-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Tue, 3 Jun 2014 12:52:45 -0400

IETF 89 comment that "Compound" has too many meanings - especially in NFSv4
Also change "outer" handle to "parent" handle

Signed-off-by: Andy Adamson <[email-masked]>
---
 rpcsecgssv3_front.xml               |  5 +-
 rpcsecgssv3_middle_introduction.xml | 96 +++++++++++++++++++------------------
 2 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/rpcsecgssv3_front.xml b/rpcsecgssv3_front.xml
index 15042f8..b7f0505 100644
--- a/rpcsecgssv3_front.xml
+++ b/rpcsecgssv3_front.xml
@@ -46,8 +46,9 @@
     <abstract>
       <t>
         This document specifies version 3 of the Remote Procedure Call (RPC)
-        security protocol (RPCSEC_GSS).  This protocol provides for compound
-        authentication of client hosts and users to server (constructed by
+        security protocol (RPCSEC_GSS).  This protocol provides
+        for multi-principal authentication of client hosts and
+        user principals to server (constructed by
         generic composition), security label assertions for
         multi-level and type enforcement, structured privilege assertions,
         and channel bindings.
diff --git a/rpcsecgssv3_middle_introduction.xml b/rpcsecgssv3_middle_introduction.xml
index 219d2e7..4be202e 100644
--- a/rpcsecgssv3_middle_introduction.xml
+++ b/rpcsecgssv3_middle_introduction.xml
@@ -32,7 +32,7 @@
     the destination.  In secure NFSv4 inter-server server-side copy
     (see Section 3.4.1 of <xref target='ref:nfsv4.2' />),
     the user first secures access to both source and destination files,
-    and then uses RPCSEC_GSSv3 compound authentication and structured
+    and then uses RPCSEC_GSSv3 multi-principal authentication and structured
     privileges to authorize the destination to copy the file from the
     source on behalf of the user.
   </t>
@@ -54,7 +54,7 @@
         see server-side copy <xref target='ref:nfsv4.2' />.
       </t>
       <t>
-        Compound authentication of the client host and user to the server
+        Multi-principal authentication of the client host and user to the server
         done by binding two RPCSEC_GSS handles. For an example
         see server-side copy <xref target='ref:nfsv4.2' />.
       </t>
@@ -289,7 +289,7 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
     </t>
     <t>
       The RPCSEC_GSS_CREATE procedure binds any combination of assertions:
-      compound authentication, labels, structured privileges, or channel
+      multi-principal authentication, labels, structured privileges, or channel
       bindings to a new RPCSEC_GSSv3 context returned in the rgss3_create_res
       rcr_handle field.
     </t>
@@ -336,14 +336,14 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
       <figure>
         <artwork>
    ///  struct rgss3_create_args {
-   ///          rgss3_gss_binding    *rca_comp_auth;
+   ///          rgss3_gss_mp_auth    *rca_mp_auth;
    ///          rgss3_chan_binding   *rca_chan_bind_mic;
    ///          rgss3_assertion      rca_assertions<>;
    ///  };
    ///
    ///  struct rgss3_create_res {
    ///          opaque               rcr_handle<>;
-   ///          rgss3_gss_binding    *rcr_comp_auth;
+   ///          rgss3_gss_mp_auth    *rcr_mp_auth;
    ///          rgss3_chan_binding   *rcr_chan_bind_mic;
    ///          rgss3_assertion      rcr_assertions<>;
    ///  };
@@ -380,7 +380,7 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
         RPCSEC_GSSv3 context handle called the "child" handle:
         <list style='symbols'>
           <t>
-            Compound authentication: another RPCSEC_GSS context handle
+            Multi-principal authentication: another RPCSEC_GSS context handle
           </t>
           <t>
             Authorization assertions: labels and or privileges
@@ -411,17 +411,17 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
         the GSS-API.  
       </t>
 
-      <section anchor="ss:ca" title="Compound Authentication">
+      <section anchor="ss:ca" title="Multi-principal Authentication">
         <t>
           &lt;CODE BEGINS&gt;
         </t>
         <figure>
           <artwork>
    ///
-   ///  struct rgss3_gss_binding {
-   ///          opaque          rgb_handle<>; /* inner handle */
-   ///          opaque          rgb_nonce<>;
-   ///          opaque          rgb_nounc_mic<>;
+   ///  struct rgss3_gss_mp_auth {
+   ///          opaque          rgmp_handle<>; /* inner handle */
+   ///          opaque          rgmp_nonce<>;
+   ///          opaque          rgmp_nounc_mic<>;
    ///  };
    ///
           </artwork>
@@ -430,30 +430,8 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
           &lt;CODE ENDS&gt;
         </t>
         <t>
-          RPCSEC_GSSv3 clients MAY assert a compound authentication of the
-          client host and a user. This is done by including an assertion of
-          type rgss3_gss_binding in the RPCSEC_GSS_CREATE rgss3_create_args
-          call data.
-          In addition to the <xref target="sec:protocol">parent handle</xref>,
-          the compound authentication rgss3_gss_binding call data has an
-          RPCSEC_GSS version 3 handle referenced via the rgb_handle field
-          termed the "inner" handle.
-          A nonce and a MIC of that nounce created using the GSS-API security
-          context associated with the inner handle is also provided.
-        </t>
-        <t>
-          The target verifies the compounding by verifying the rgb_nouce_mic.
-          On a successful reply, the rgss3_gss_binding field in the
-          rgss3_create_res reply uses the
-          parent RPCSEC_GSSv3 context as the rgb_handle, the same rgb_nounce
-          as was sent in the call data with the rgb_nounce_mic created using
-          the GSS-API security context associate with the parent handle.
-          Verification of the rbg_nounce_mic by the initiator demonstrates
-          that the target agrees to the compounding. On failure, the
-          rgss3_gss_binding field is not sent.
-          (rgss3_gss_binding is an optional field)
-        </t>
-        <t>
+          RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of
+          the client host principal and a user principal.
           This feature is needed, for example, when a client wishes to use
           authority assertions that the server may only grant if a user and a
           client are authenticated together to the server.  Thus a server may
@@ -472,22 +450,48 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
           user security context.
         </t>
         <t>
-          Clients using RPCSEC_GSSv3 compound authentication MUST use
+          In addition to the <xref target="sec:protocol">parent handle</xref>,
+          the multi-principal authentication call data has an
+          RPCSEC_GSS version 3 handle referenced via the rgmp_handle field
+          termed the "inner" handle.
+          Clients using RPCSEC_GSSv3 multi-principal authentication MUST use
           an RPCSEC_GSSv3 context handle that corresponds to a
           GSS-API security context that authenticates the client host for
-          the outer handle. The inner context handle it SHOULD use a context
-          handle to authenticate a user.  The reverse (outer handle
+          the parent handle. The inner context handle it SHOULD use a context
+          handle to authenticate a user.  The reverse (parent handle
           authenticates user, inner authenticates client) MUST NOT be used.
-          Other compounds might eventually make sense.
+          Other multi-principal parent and inner context handle uses might
+          eventually make sense.
         </t>
         <t>
-          An inner RPCSEC_GSSv3 context handle that is bound to an outer
-          RPCSEC_GSS context MUST be treated by servers as authenticating the
+          An inner RPCSEC_GSSv3 context handle that is bound to a parent
+          RPCSEC_GSS context through multi-principal authentication
+          MUST be treated by servers as authenticating the
           GSS-API initiator principal authenticated by the inner context
-          handle's GSS- API security context.  This principal may be mapped
+          handle's GSS-API security context.  This principal may be mapped
           to a server-side notion of user or principal.
         </t>
-      </section> <!-- Compound Authentication -->
+        <t>
+          Multi-principal binding is done by including an assertion of
+          type rgss3_gss_mp_auth in the RPCSEC_GSS_CREATE rgss3_create_args
+          call data. The inner context handle is place in the rbmp_handle
+          field.  A nonce and a MIC of that nounce created using the
+          GSS-API security context associated with the inner handle is also
+          provided.
+        </t>
+        <t>
+          The target verifies the multi-principal authentication by verifying
+          the rgmp_nouce_mic.
+          On a successful reply, the rgss3_gss_mp_auth field in the
+          rgss3_create_res reply uses the
+          parent RPCSEC_GSSv3 context as the rgmp_handle, the same rgmp_nounce
+          as was sent in the call data with the rgmp_nounce_mic created using
+          the GSS-API security context associate with the parent handle.
+          Verification of the rbg_nounce_mic by the initiator demonstrates
+          that the target agrees to the multi-principal authentication.
+        </t>
+
+      </section> <!-- Multi-principal Authentication -->
 
       <section anchor="ss:la" title="Label Assertions">
         <t>
@@ -819,7 +823,7 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
           fix above into YYY. All the entries are TBD...
         </cref>
         <cref anchor='AI5' source='AA'>
-          The compound authentication problems are: can't find the handle plus
+          The multi-principal authentication problems are: can't find the handle plus
 	  handle version on the target, or the MIC of the nounce does not
 	  match. Both of these errors already have auth_stat entries:
 	  RPCSEC_GSS_CREDPROBLEM for the first and "reply status of
@@ -866,7 +870,7 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
     The RPCSEC_GSSv3 protocol allows for client-side assertions of data
     that is relevant to server-side authorization decisions.  These
     assertions must be evaludated by the server in the context of whether
-    the client and/or user are authenticated, whether compound
+    the client and/or user are authenticated, whether multi-principal
     authentication was used, whether the client is trusted, what ranges
     of assertions are allowed for the client and the user (separately or
     together), and any relevant server-side policy.
@@ -911,7 +915,7 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
   <t>
     <cref anchor='AI7' source='AA'>
       AFAICS the reason to use SSV is to avoid using a client machine credential
-      which means compound authentication can not be used.
+      which means multi-principal authentication can not be used.
     </cref>
   </t>
 </section> <!-- Security Considerations -->
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Tue, 3 Jun 2014 12:52:46 -0400

Change RPCSEC_GSS_COMPOUND_PROBLEM to RPCSEC_GSS_INNER_CREDPROBLEM.

Signed-off-by: Andy Adamson <[email-masked]>
---
 rpcsecgssv3_middle_introduction.xml | 87 ++++++++++++++++++++++---------------
 1 file changed, 53 insertions(+), 34 deletions(-)

diff --git a/rpcsecgssv3_middle_introduction.xml b/rpcsecgssv3_middle_introduction.xml
index 4be202e..181fb23 100644
--- a/rpcsecgssv3_middle_introduction.xml
+++ b/rpcsecgssv3_middle_introduction.xml
@@ -282,6 +282,29 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
     </t>
   </section> <!-- New Version Number -->
 
+  <section anchor="ss:nasv" title="New auth_stat Values">
+    <t>
+      RPCSEC_GSSv3 requires the addition of several values to the auth_stat
+      enumerated type definition. The use of each of these new auth_stat
+      values is explained later in this document.
+    </t>
+
+    <figure>
+        <artwork>
+           enum auth_stat {
+                   ...
+                   /*
+                    * RPCSEC_GSSv3 errors
+                    */
+                   RPCSEC_GSS_INNER_CREDPROBLEM = 15,
+                   RPCSEC_GSS_LABEL_PROBLEM = 16,
+                   RPCSEC_GSS_UNKNOWN_PRIVILEGE = 17,
+                   RPCSEC_GSS_UNKNOWN_MESSAGE = 18 
+           };
+        </artwork>
+    </figure>
+  </section> <!-- New Auth Stat Values -->
+
   <section anchor="ss:cm" title="New Control Procedures">
     <t>
       There are two new RPCSEC_GSSv3 control procedures: RPCSEC_GSS_CREATE,
@@ -490,6 +513,36 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
           Verification of the rbg_nounce_mic by the initiator demonstrates
           that the target agrees to the multi-principal authentication.
         </t>
+        <t>
+          On failure, the rgss3_gss_mp_auth field is not sent
+          (rgss3_gss_mp_auth is an optional field).
+          A MSG_DENIED reply to an RPCSEC_GSS_CREATE formulated as usual.
+          A new value, RPCSEC_GSS_INNER_CREDPROBLEM, has been added to the
+          auth_stat type.
+          As described in Section 5.3.3.3 of <xref target="RFC2203" />
+          the server maintains a list of contexts for the clients that are
+          currently in session with it. When a client request comes in, there
+          may not be a context corresponding to its handle. When this occurs
+          on an RPCSEC_GSS3_CREATE request processing of the parent handle,
+          the server rejects the request with a reply status of MSG_DENIED
+          with the reject_stat of AUTH_ERROR and with an auth_stat value of
+          RPCSEC_GSS_CREDPROBLEM.
+        </t>
+        <t>
+          With a multi-pricipal authorization request, the server must also have
+          a context corresponding to the inner context handle. When the server
+          does not have a context handle corresponding to the inner
+          context handle of a multi-pricipal authorization request, the server
+          send a reply status of MSG_DENIED with the reject_stat of AUTH_ERROR
+          and with an auth_stat value of RPCSEC_GSS_INNER_CREDPROBLEM.
+        </t>
+        <t>
+          When processing the multi-principal authentication request, if the
+          GSS_VerifyMIC() call on the inner handle nouce fails to return
+          GSS_S_COMPLETE, the server sends a reply status of MSG_DENIED with
+          the reject_stat of AUTH_ERROR and with an auth_stat value of
+          RPCSEC_GSS_INNER_CREDPROBLEM.
+        </t>
 
       </section> <!-- Multi-principal Authentication -->
 
@@ -798,40 +851,6 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
       </t>
     </section> <!-- Extensibility -->
 
-  <section anchor="ss:nasv" title="New auth_stat Values">
-    <t>
-        RPCSEC_GSSv3 requires the addition of several values to the auth_stat
-        enumerated type definition:
-    </t>
-
-    <figure>
-        <artwork>
-           enum auth_stat {
-                   ...
-                   /*
-                    * RPCSEC_GSSv3 errors
-                    */
-                   RPCSEC_GSS_COMPOUND_PROBLEM = <>,
-                   RPCSEC_GSS_LABEL_PROBLEM = <>,
-                   RPCSEC_GSS_UNKNOWN_PRIVILEGE = <>
-                   RPCSEC_GSS_UNKNOWN_MESSAGE = <>
-           };
-        </artwork>
-    </figure>
-      <t>
-        <cref anchor='AI4' source='NW'>
-          fix above into YYY. All the entries are TBD...
-        </cref>
-        <cref anchor='AI5' source='AA'>
-          The multi-principal authentication problems are: can't find the handle plus
-	  handle version on the target, or the MIC of the nounce does not
-	  match. Both of these errors already have auth_stat entries:
-	  RPCSEC_GSS_CREDPROBLEM for the first and "reply status of
-          MSG_ACCEPTED, and an acceptance status of GARBAGE_ARGS."
-      </cref>
-      </t>
-    </section> <!-- New Auth Stat Values -->
-
 </section> <!-- The RPCSEC_GSSv3 Protocol -->
 
 <section title="Version Negotiation">
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Tue, 3 Jun 2014 12:52:47 -0400

Also:
Change RPCSEC_GSS_UNKNOWN_PRIVILEGE to RPCSEC_GSS_PRIVILEGE_PROBLEM

Signed-off-by: Andy Adamson <[email-masked]>
---
 rpcsecgssv3_middle_introduction.xml | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/rpcsecgssv3_middle_introduction.xml b/rpcsecgssv3_middle_introduction.xml
index 181fb23..0655d47 100644
--- a/rpcsecgssv3_middle_introduction.xml
+++ b/rpcsecgssv3_middle_introduction.xml
@@ -298,7 +298,7 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
                     */
                    RPCSEC_GSS_INNER_CREDPROBLEM = 15,
                    RPCSEC_GSS_LABEL_PROBLEM = 16,
-                   RPCSEC_GSS_UNKNOWN_PRIVILEGE = 17,
+                   RPCSEC_GSS_PRIVILEGE_PROBLEM = 17,
                    RPCSEC_GSS_UNKNOWN_MESSAGE = 18 
            };
         </artwork>
@@ -602,14 +602,6 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
           sec_label attribute.
         </t>
         <t>
-          <cref anchor='AI2' source='AA'>
-           Check that this Label discussion provides all the required pieces to
-           enable full mode when combined with NFSv4.2 LNFS. Specifically, how
-           does the client find out and respond if a server has
-           changed a label. 
-          </cref>
-        </t>
-        <t>
           If a label itself requires privacy protection (i.e., that the user
           can assert that label is a secret) then the client MUST use the
           rpc_gss_svc_privacy protection service for the RPCSEC_GSS_CREATE
@@ -663,6 +655,15 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
           the rcr_assertions field of the rgss3_create_res
           RPCSEC_GSS_CREATE reply.
         </t>
+	<t>
+          If a server receives a structured privilege assertion that it
+          does not recognize the assertion is rejected with MSG_DENIED,
+          a reject_status of AUTH_ERROR, and an auth_stat of
+          RPCSEC_GSS_UNKNOWN_MESSAGE. If the server fails the RPC application
+          defined server verification for a structured privilege, the
+          assertion is rejected with MSG_DENIED, a reject_status of AUTH_ERROR,
+          and an auth_stat of RPCSEC_GSS_PRIVILEGE_PROBLEM.
+        </t>
         <t>
           Section 3.4.1.2. "Inter-Server Copy with RPCSEC_GSSv3"
           of <xref target='ref:nfsv4.2' /> shows an example of structured
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Tue, 3 Jun 2014 12:52:48 -0400

Signed-off-by: Andy Adamson <[email-masked]>
---
 rpcsecgssv3_middle_introduction.xml | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/rpcsecgssv3_middle_introduction.xml b/rpcsecgssv3_middle_introduction.xml
index 0655d47..711e9b6 100644
--- a/rpcsecgssv3_middle_introduction.xml
+++ b/rpcsecgssv3_middle_introduction.xml
@@ -150,6 +150,22 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
   </t>
   </section> <!-- Compatibility with RPCSEC_GSSv2 -->
 
+<section title="Version Negotiation">
+  <t>
+    An initiator that supports version 3 of RPCSEC_GSS simply issues an
+    RPCSEC_GSS request with the rgc_version field set to
+    RPCSEC_GSS_VERS_3.  If the target does not recognize
+    RPCSEC_GSS_VERS_3, the target will return an RPC error per Section
+    5.1 of <xref target="RFC2203" />.
+  </t>
+  <t>
+    The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned
+    by version 3 of a target with version 1 or version 2 of the same target.
+    The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by
+    version 1 or version 2 of a target with version 3 of the same target.
+  </t>
+</section> <!-- Version Negotiation -->
+
   <section title="New REPLY verifier">
   <t> 
     The RPCSEC_GSSv3 child handle uses the same GSS context as the parent
@@ -854,22 +870,6 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'

-<section title="Version Negotiation">
-  <t>
-    An initiator that supports version 3 of RPCSEC_GSS simply issues an
-    RPCSEC_GSS request with the rgc_version field set to
-    RPCSEC_GSS_VERS_3.  If the target does not recognize
-    RPCSEC_GSS_VERS_3, the target will return an RPC error per Section
-    5.1 of <xref target="RFC2203" />.
-  </t>
-  <t>
-    The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned
-    by version 3 of a target with version 1 or version 2 of the same target.
-    The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by
-    version 1 or version 2 of a target with version 3 of the same target.
-  </t>
-</section> <!-- Version Negotiation -->
-
 <section title="Operational Recommendation for Deployment">
 
   <t>
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Tue, 3 Jun 2014 12:52:49 -0400

Signed-off-by: Andy Adamson <[email-masked]>
---
 rpcsecgssv3_middle_introduction.xml | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/rpcsecgssv3_middle_introduction.xml b/rpcsecgssv3_middle_introduction.xml
index 711e9b6..fe6f8d8 100644
--- a/rpcsecgssv3_middle_introduction.xml
+++ b/rpcsecgssv3_middle_introduction.xml
@@ -130,9 +130,6 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
         A client uses an existing RPCSEC_GSSv3 context
         handle to protect RPCSEC_GSSv3 exchanges, this will be termed the
         "parent" handle.
-        <cref anchor='AI1' source='AA'>
-          CAN A CHILD handle be used as a parent?    
-        </cref>
       </t> 
       <t> 
         The server issues a "child" RPCSEC_GSSv3 handle in the
@@ -140,6 +137,10 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
         underlying GSS-API security context of the parent handle in all
         subsequent exchanges that uses the child handle.
       </t>
+      <t>
+	An RPCSEC_GSSv3 child handle MUST NOT be used as the parent handle
+        in an RPCSEC_GSS3_CREATE control message.
+      </t>
     </list>
   </t> 
 
-- 
1.8.5.2 (Apple Git-48)

---

From: <[email-masked]>
Date: Tue, 3 Jun 2014 12:52:50 -0400

Signed-off-by: Andy Adamson <[email-masked]>
---
 rpcsecgssv3_middle_introduction.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rpcsecgssv3_middle_introduction.xml b/rpcsecgssv3_middle_introduction.xml
index fe6f8d8..1968bd8 100644
--- a/rpcsecgssv3_middle_introduction.xml
+++ b/rpcsecgssv3_middle_introduction.xml
@@ -179,7 +179,7 @@ grep "^  *///" | sed 's?^  */// ??' | sed 's?^  *///$??'
     This is easily addressed: RPCSEC_GSS version 3 MUST change the verifier of
     the reply to compute the verifier using the exact same input as that is
     used for verifier of the request, except for the mtype change from CALL
-    to REPLY:
+    to REPLY. The new reply verifier computes a MIC over the following data:
     <figure>
       <artwork>
   unsigned int xid;
-- 
1.8.5.2 (Apple Git-48)

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Jun 2014 17:33:33 -0400 (EDT)

> +          GSS_VerifyMIC() call on the inner handle nouce fails to return

I assume that's supposed to be "nonce"?

-Ben