Subject: sasl-gssapi questions: base32 and context flags

From: "John Brezak" <[email-masked]>
Date: Mon, 4 Jun 2001 18:21:07 -0700

Is the base32 encoding method used for anything other than the 10 bytes
used in the suffix for the gssapi mechanism encoding? If so why go
through all of this complexity - why not just use the text version of
the OID for the mechtype?

There should also be some details about the mapping of the SASL
protection profile mapping to the GSSAPI context establishment flags
(GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG). This should also be extended to
cover the use of the context flags in NegTokenInit of SPNEGO and the
GSSAPI Context flags specified in the optimistic protocol.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Brezak                       * mailto:[email-masked]
Microsoft Corporation        * 425-936-2602
One Microsoft Way
Redmond, WA 98052

---

From: "John Brezak" <[email-masked]>
Date: Tue, 5 Jun 2001 12:50:52 -0700

The settings of the integ_req_flag and conf_req_flag are specified for
the use of the GSSAPI mechanism for the exchange of the security layer.
However there should be some explaination on the use of the security
layer that is negotiated and how it is applied to the GSS security
context that was used during the SASL exchanges.

For example, the GSSAPI context needed for performing the SASL exchange
requires that integ and optionally conf (if the client is requesting
conf) are set for the purposes of exchanging the security layer. If the
resulting security layer does not specify conf, then what is to be done
with the security context that was used for SASL negotiation? If the
server responds that integ is only accepted, then should the client
security context that was created with integ+conf be discarded?

In section 6.1:
- Why restrict name types to only the HOSTBASED names? You should allow
any name type available to the GSS mechanisms (same for 6.2).
- When the client calls GSS_Unwrap, the conf_flag must be returned as
false, since the server (client) wraps with no confidentiality (same for
6.2).

> -----Original Message-----
> From: John Gardiner Myers [mailto:[email-masked]] 
> Sent: Tuesday, June 05, 2001 11:34 AM
> To: [email-masked]
> Subject: Re: sasl-gssapi questions: base32 and context flags
> 
> 
> 
> 
> John Brezak wrote:
> > (GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG).
> 
> I see no mention of either "GSS_C_CONF_FLAG" or 
> "GSS_C_INTEG_FLAG" in RFC 2743.  The appropriate use of 
> conf_req_flag, integ_req_flag, sequence_req_flag, and 
> mutual_req_flag is specified in draft-ietf-cat-sasl-gssapi-05?
> 
> > This should also be extended to
> Why is such extension necessary?  Does not the SPNEGO draft 
> already specify this?
> 
> Please be more specific as to what is underspecified.  
> Proposed wording would be particularly helpful.
>

---

From: "John Brezak" <[email-masked]>
Date: Thu, 7 Jun 2001 12:52:27 -0700

Thanx for pointing out the limit.

So the base32 is to avoid the need for a registration authority? It
still seems that this base32 encoding is over-kill to avoid the use of
names. Keeping the names at least makes it consistent with the other
authentication mechanism names. Why not just register the GSSAPI
mechtype names with IANA (like the other SASL names)?

Maybe define a different type like "GSS-OID" and put the full OID after
the name section.

> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Monday, June 04, 2001 7:34 PM
> To: John Brezak
> Cc: [email-masked]
> > Is the base32 encoding method used for anything other than the 10 
> > bytes used in the suffix for the gssapi mechanism encoding? 
> If so why 
> > go through all of this complexity - why not just use the 
> text version 
> > of the OID for the mechtype?
> 
> IMHO, there are two reasons:
> 
> 1). Allowed characters for mechanism name are uppercase 
> letters, digits, "-" and "_" (thus "." is not allowed) 2). 
> There is a limit of 20 characters for mechanism name. Having 
> prefix "GSS-" this leaves 16 characters.
> 
> __________________________________________
> Alexey Melnikov
> R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
> phone 780.424.4922 x357
> 
> I speak for myself only, not for my employer. 
> __________________________________________
> 
> 
>