Subject: RE: CFX Last call comment: section 4.1.1

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 16 Dec 2003 18:33:56 -0800

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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 19 Dec 2003 13:37:46 -0800

Here we suggest some *very* minor twist of the text in section 4.1.1.1
to cover the points brought up by Martin, Nicolas and Sam. The main
change is to make it clear that it is this draft that defines the
mappings to be used by this mechanism, for optional context level
features. Nicolas helped on the text.

----------------------------------------------------
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 the
corresponding return state values [RFC-2743] indicate that any of above
optional context level services will be active on the context, the
corresponding flag values in the table above 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.
Undefined flag values MUST be cleared by the sender, and unknown flags
MUST be ignored by the receiver.
------------------------------------------------------------------------
--

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Thursday, December 18, 2003 9:35 AM
To: Martin Rex
Cc: Sam Hartman; [email-masked]
Subject: Re: CFX Last call comment: section 4.1.1

On Thu, Dec 18, 2003 at 06:13:31PM +0100, Martin Rex wrote:
> Sam Hartman wrote:
> > 
> > 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.
> 
> 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.

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.

> 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.

Yes.

Nico
--