Subject: RE: sasl-gssapi questions: base32 and context flags

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:
> > 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).
> 
> 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
> > cover the use of the context flags in NegTokenInit of 
> SPNEGO and the 
> > GSSAPI Context flags specified in the optimistic protocol.
> 
> 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 Gardiner Myers <[email-masked]>
Date: Mon, 18 Jun 2001 15:41:44 -0700

> context that was used during the SASL exchanges.

Isn't this specified adequately in RFC 2743?  Sections 2.3.3 and 2.4.4
clearly state that the GSS security context is used as an input.

> with the security context that was used for SASL negotiation?

Did you want a statement that the server and client are to call
GSS_Inquire_context, suppressing 2 and 4 of the security layer bit-mask
if integ_avail and conf_avail, respectively, are FALSE?

> If the

No, if the client and server are then willing to communicate with only
integrity protection then the client security context will be needed for
calls to GSS_Wrap and GSS_Unwrap.

> any name type available to the GSS mechanisms (same for 6.2).

I emphatically disagree.

We need to completely specify the targ_name/desired_name in order to
permit interoperability.  Servers and clients will not interoperate
unless they use the same name for these two fields.

SASL protocol profiles know nothing about GSS API name types and names
other than the requirement of the SASL base specification that SASL
protocol profiles specify a service name selected from the IANA registry
of "service" elements for the GSSAPI host-based service name form.  The
SASL-GSSAPI specification needs to specify the targ_name/desired_name to
used based on the information that an implementation is likely to have
available.

> false, since the server (client) wraps with no confidentiality (same for

I see no security need to perform this check.  Could you explain what
purpose mandating such a check would serve?

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 18 Jun 2001 15:41:44 -0700

I emphatically disagree.