Subject: RE: CFX Last call comment: section 4.1.1

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 17 Dec 2003 14:05:08 -0800

Here is the text dealing with the extension field Nicolas proposed.  Ken
helped on the new text together with Nicolas. For completeness, section
4.1.1.1 is also included. 

We believe this is a small change to the document overall.

Thx, Larry

=======================================================================
4.1.1. Authenticator Checksum 
 
   The authenticator in the KRB_AP_REQ message MUST include the 
   optional sequence number and the checksum field.  The checksum field 
   is used to convey service flags, channel bindings, and optional 
   delegation information.   
    
   The checksum type MUST be 0x8003. When delegation is used, a ticket-
   granting ticket will be transferred in a KRB_CRED message.  This 
   ticket SHOULD have its forwardable flag set.  The EncryptedData 
   field of the KRB_CRED message [KRBCLAR] MUST be encrypted in the 
   session key of the ticket used to authenticate the context. 
    
   The format of the authenticator checksum field is as follows. 
       
      Octet        Name      Description 
     ----------------------------------------------------------------- 
      0..3         Lgth    Number of octets in Bnd field;  Represented  
                           in little-endian order;  Currently contains

                           hex value 10 00 00 00 (16). 
      4..19        Bnd     Channel binding information, as described in

                           section 4.1.1.2. 
      20..23       Flags   Four-octet context-establishment flags in 
                           little-endian order as described in section  
                           4.1.1.1.  
      24..25       DlgOpt  The Delegation Option identifier (=1)  
                           [optional]. 
      26..27       Dlgth   The length of the Deleg field in little- 
                           endian order [optional]. 
      28..(n-1)    Deleg   A KRB_CRED message (n = Dlgth + 28)  
                           [optional].  
      n..last      Exts    Extensions [optional]. 
    
   The length of the checksum field MUST be at least 24 octets when 
   GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at

   least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set.  When

   GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth and Deleg fields of the 
   checksum data MUST immediately follow the Flags field.  The optional 
   trailing octets (namely the "Exts" field) facilitate future 
   extensions to this mechanism.  When delegation is not used but the 
   Exts field is present, the Exts field starts at octet 24 (DlgOpt, 
   Dlgth and Deleg are absent). 
    
   Initiators that do not support the extensions MUST NOT include more 
   than 24 octets in the checksum field, when GSS_C_DELEG_FLAG is not 
   set, or more than 28 octets plus the KRB_CRED in the Deleg field, 
   when GSS_C_DELEG_FLAG is set.  Acceptors that do not understand the 
   extensions MUST ignore any octets past the Deleg field of the 
   checksum data, when GSS_C_DELEG_FLAG is set, or past the Flags field 
   of the checksum data, when GSS_C_DELEG_FLAG is not set.

4.1.1.1. Checksum Flags Field 
    
   The checksum "Flags" field is used to convey service options or 
   extension negotiation information.    
    
   The following context establishment flags are defined in [RFC-2744]. 
    
        Flag Name              Value     
      --------------------------------- 
       GSS_C_DELEG_FLAG           1        
       GSS_C_MUTUAL_FLAG          2       
       GSS_C_REPLAY_FLAG          4       
       GSS_C_SEQUENCE_FLAG        8        
       GSS_C_CONF_FLAG           16      
       GSS_C_INTEG_FLAG          32     
        
   Context establishment flags are exposed to the calling application.  
   If the calling application desires a particular service option then 
   it requests that option via GSS_Init_sec_context() [RFC-2743].  If 
   any of the above flag values are returned by the current call to 
   GSS_Init_sec_context() to indicate that an optional context level 
   service is supported, the same flag value MUST be set in the checksum

   Flags field. 
    
   Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for use

   with legacy vendor-specific extensions to this mechanism. 
    
   All other flag values not specified herein are reserved for future 
   use.
=====================================================================

-----Original Message-----
From: Liqiang(Larry) Zhu 
Sent: Tuesday, December 16, 2003 6:34 PM
To: 'Sam Hartman'; [email-masked]
Subject: RE: CFX Last call comment: section 4.1.1

It can use the bit GSS_C_DELEG_FLAG in the checksum Flags field to
handle this.

Here is the text for this that Nicolas and I worked on.

   The length of the checksum field MUST be at least 24 octets when 
   GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at

   least 28 octets, plus Dlgth octets when GSS_C_DELEG_FLAG is set.  
   When GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth and KRB-CRED fields 
   of the checksum data MUST immediately follow the Flags field.  The 
   optional trailing octets (namely the "Exts" field) facilitate future 
   extensions to this mechanism.  Acceptors that do not understand the 
   extensions MUST ignore any octets past the KRB-CRED field of the 
   checksum data, when GSS_C_DELEG_FLAG is set, or past the Flags field 
   of the checksum data, when GSS_C_DELEG_FLAG is not set.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Tuesday, December 16, 2003 1:23 PM
To: [email-masked]
Subject: Re: CFX Last call comment: section 4.1.1

What if I want extensions but do not want delegation?  You should
specify how to do this.

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Dec 2003 15:47:26 +0100 (MET)

>    The following context establishment flags are defined in [RFC-2744]. 

RFC-2744 defines 3 more context establishment flags:
	 GSS_C_ANON_FLAG           64
         GSS_C_PROT_READY_FLAG    128
	 GSS_C_TRANS_FLAG         256

GSS_C_PROT_READY_FLAG and GSS_C_TRANS_FLAG are a purely local matter
between a gssapi implementation and its application caller describing
API semantics and NOT genuine characteristics of the established
security context.  Therefore GSS_C_PROT_READY and GSS_C_TRANS_FLAG
SHOULD NOT be sent within context token and MUST BE ignored by the
receiving peer in case they're present.

GSS_C_ANON_FLAG on the other hand is a context attribute that should be
sent to the peer if it ever gets specified and implemented how this is
to be done with Kerberos 5.  GSS-API v1 provided two kinds of authentication:
  (1) unidirectional initiator authenticates to acceptor
      "client authentication" or (to) target authentication
  (2) mutual authentication "client and server authentication".
GSS_C_ANON_FLAG is to request the missing 3rd authentication type
  (3) unidirectional acceptor authenticates to initiator "server authentication"
which is the scenario commonly used by HTTPS.

>    All other flag values not specified herein are reserved for future 

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Dec 2003 10:53:43 -0500

I think the right way to make it clear what is going on here is to
make it clear that we are mapping flags from 2744 into Kerberos
mechanism space.  We do not guarantee that flags in revisions to 2744
will be mapped into this mechanism, nor do we guarantee that future
mappings will use the same numbers as revisions to 2744.  Perhaps
referencing 2743 to get the semantics and not even mentioning the
numeric mapping is the same is ideal.

Since we do not support anonymous we should not map the flag at this
time.

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Dec 2003 18:13:31 +0100 (MET)

> Since we do not support anonymous we should not map the flag at this

I think it should be explicitly spelled out what to do with all of
the context flags, since every gssapi mechanism will get them at
the API and have to deal with them.

i.e. the document should specify that all other bits in the context
attributes value SHOULD be set to zero by the sender and MUST be ignored
by the receiver in case the sender failed to clear them.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 18 Dec 2003 09:35:01 -0800

> the API and have to deal with them.

IIRC mechanisms are allowed to ignore flags they don't support and MUST
set the ret_flags output parameters to the set of flags that apply to
the given context; see rfc2743 section 1.2.1.2 and rfc2744 section 4.

Therefore it should suffice to state which flags CFX supports and
implementors should be able to figure out what to do about the other
from rfcs 2743/2744.

> by the receiver in case the sender failed to clear them.

Yes.

Nico
--