Subject: WG Last Call: draft-ietf-sasl-gs2-14

From: Tom Yu <[email-masked]>
Date: Mon, 13 Jul 2009 22:17:01 -0400

This message commences a WG Last Call on the following Internet-Draft:

	Title           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)       : S. Josefsson, N. Williams
	Filename        : draft-ietf-sasl-gs2-14.txt
	Pages           : 23
	Date            : 2009-06-27

This Last Call will expire on 03 August 2009.  This document is
intended for the Standards Track.  Please review this document and
send technical feedback to the WG mailing list, and editorial comments
to the authors.

-- 
Tom Yu
IETF SASL WG co-chair

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Jul 2009 19:39:08 +0100

Tom Yu wrote:

> Author(s) : S. Josefsson, N. Williams Filename : 
> draft-ietf-sasl-gs2-14.txt Pages : 23 Date : 2009-06-27 This Last Call 
> will expire on 03 August 2009. This document is intended for the 
> Standards Track. Please review this document and send technical 
> feedback to the WG mailing list, and editorial comments to the authors.

In general I think the document is in a good shape. I have some minor, 
mostly editorial changes. I don't believe another WGLC would be needed 
after they are addressed.

I've already sent a couple of comments to the mailing earlier (See 
<http://www.imc.org/ietf-sasl/mail-archive/msg04104.html> and 
<http://www.imc.org/ietf-sasl/mail-archive/msg04105.html>). Here are my 
remaining comments:

1). SCRAM contains the following text about authorization identity, 
which I think is missing from GS2:

    Upon the receipt of this value the server verifies its
    correctness according to the used SASL protocol profile.
    Failed verification results in failed authentication exchange.

I think this should also be mentioned in section 7.

2). In Section 3:

   If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
   implementation need some other mechanism to map mechanism OIDs to
   SASL name internally.  In this case, the implementation can only
   support the mechanisms for which it knows the SASL name.  If the
   GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation
   cannot map the OID to a SASL mechanism name using some other means,
   it cannot use the particular GSS-API mechanism since it does not know
   its SASL mechanism name.

Is the last sentence still correct? I think this is out of sync with 
section 10, which now says:

      The output variable sasl_mech_name will hold the IANA registered
      mechanism name for the GSS-API mechanism, or if none is
      registered, a mechanism named computed from the OID as
      described in section 3.1 of this document.

3). In section 5:

   If the client supports channel binding and the server does not appear
   to (i.e., the client did not see a -PLUS name) then the client MUST

I know this is probably too subtle, but does "a -PLUS name" means "any 
SASL mechanism name ending with -PLUS, even if it is not the same base 
SASL mechanism we are talking about", or "the base SASL mechanism name"? 
I.e. should "a" be "the"?

   either fail authentication or it MUST chose the non-PLUS mechanism
   name and use a "y" gs2-cb-flag.

 [...]

   If the client supports channel binding and the server appears to
   support it (i.e., the client see a -PLUS name) then the client MUST

Note that SCRAM also says:

, or if the client wishes to use channel
            binding but the client does not negotiate
            mechanisms

   use a "p" gs2-cb-flag to indicate the channel binding type it is
   using.

4). In Section 6: Multiple missing commas in examples.

According to the ABNF:

    gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
                        ;; The GS2 header is gs2-header.

>   Example #2: a one and one half round-trip GSS-API context token
>   exchange, no channel binding.
>
>         C: Request authentication exchange
>         S: Empty Challenge
>         C: n,<initial context token with standard
>                            header removed>
>  
>
Should be "C: n,,<initial context token with standard"

>         S: Send reply context token as is
>         C: Send reply context token as is
>         S: Outcome of authentication exchange
>
>   Example #3: a two round-trip GSS-API context token exchange, no
>   channel binding, no standard token header.
>
>         C: Request authentication exchange
>         S: Empty Challenge
>         C: F,n,<initial context token without
>                             standard header>
>  
>
C: F,n,,...

>         S: Send reply context token as is
>         C: Send reply context token as is
>         S: Send reply context token as is
>         C: Empty message
>         S: Outcome of authentication exchange
>
>   Example #5: using channel binding.
>
>         C: Request authentication exchange
>         S: Empty Challenge
>         C: p=tls-unique,<initial context token with standard
>  
>
C: p=tls-unique,,

>                                header removed>
>         S: Send reply context token as is
>         ...
>
>   Example #6: using non-standard channel binding (requires out-of-band
>   negotiation).
>
>         C: Request authentication exchange
>         S: Empty Challenge
>         C: p=tls-server-end-point,<initial context token with standard
>  
>
C: p=tls-server-end-point,,

>                                header removed>
>         S: Send reply context token as is
>         ...
>  
>
5). Section 9 says:

   There's no requirement that any particular GSS-API name-types be
   used.  However, typically SASL servers will have host-based acceptor
   principal names (see [RFC2743] section 4.1) and clients will
   typically have username initiator principal names (see [RFC2743]
   section 4.2).

This might be trivial, but I am missing the following text from RFC 4752:
   ... targ_name equal to output_name from GSS_Import_Name called with 
input_name_type
   of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
   "service@hostname" where "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.

So possibly reword this paragraph to read:

   There's no requirement that any particular GSS-API name-types be
   used.  However, typically SASL servers will have host-based acceptor
   principal names (see [RFC2743] section 4.1) and clients will
   typically have username initiator principal names (see [RFC2743]
   section 4.2). When a host-based acceptor principal name is used
   ("service@hostname"), "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.

?

6).

> 10.1.  gss_inquire_saslname_for_mech
>
>    The C binding for the GSS_Inquire_SASLname_for_mech call is as
>    follows.
>
>       OM_uint32 gss_inquire_saslname_for_mech(
>         OM_uint32     *minor_status,
>         const gss_OID  desired_mech,
>         gss_buffer_t   sasl_mech_name,
>         gss_buffer_t   mech_name,
>         gss_buffer_t   mech_description,

Do the 3 output parameters need to be freed?

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Jul 2009 15:43:20 +0200

> after they are addressed.

Thanks for your comments!

> <http://www.imc.org/ietf-sasl/mail-archive/msg04105.html>). Here are
> my remaining comments:

I'll look at these next.

> I think this should also be mentioned in section 7.

I added it to section 4.  Section 7 already contains this:

	      <t>Authorization of client principal (i.e., src_name in
		GSS_Accept_sec_context) to requested authzid
		failed.</t>

>      described in section 3.1 of this document.

I think the last sentence is still needed -- consider if the function
returns an error code (e.g., out of memory).

> SASL mechanism we are talking about", or "the base SASL mechanism
> name"? I.e. should "a" be "the"?

I agree -- I changed "a" into "the".

>   support it (i.e., the client see a -PLUS name) then the client MUST

I changed "a" into "the" here too.

>   use a "p" gs2-cb-flag to indicate the channel binding type it is

Should this be added?  I'm not sure.

> Should be "C: n,,<initial context token with standard"

Fixed.

>>         C: F,n,<initial context token without

Fixed.

>>         C: p=tls-unique,<initial context token with standard

Fixed.

> C: p=tls-server-end-point,,

Fixed.

>   the protocol's profile, and "hostname" is the fully qualified host

Nico?

> Do the 3 output parameters need to be freed?

Not sure if this needs to be mentioned, I can't find much discussion in
RFC 2743 on this.  Nico?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Jul 2009 13:42:20 +0200

> Should this be added?  I'm not sure.

After re-reading the relevant text again, I think it should be added.
Done in my copy.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Jul 2009 10:05:26 -0500

> >   the protocol's profile, and "hostname" is the fully qualified host

Fine with me.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Jul 2009 10:08:53 -0500

> Not sure if this needs to be mentioned, I can't find much discussion in

Things that are constant-like don't need to be freed.  For example,
mechanism OIDs returned by GSS_Indicate_mechs(),
GSS_Inquire_sec_context(), ...

The same should apply here to these three output arguments.

Yes, that means that if an implementation were to malloc memory for
them, then it could only freed them when the shared object is unloaded
or the process exits.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Jul 2009 17:26:16 +0200

>> >   the protocol's profile, and "hostname" is the fully qualified host

Great, I've changed my local copy.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jul 2009 17:29:35 +0200

>them, then it could only freed them when the shared object is unloaded
This is fine with me. I would recommend adding this to the document.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Jul 2009 17:35:08 +0200

> them, then it could only freed them when the shared object is unloaded

The GS2 document could also say that applications needs to release
memory for these output variables.  However, I think these three output
variables would typically be stored in static storage and wouldn't need
to be released.  We could clarify this.  How about adding

   The memory allocate for the output variables need not be released
   by the application.

to the sections for new GSS-API interfaces?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Jul 2009 17:39:10 +0200

> This is fine with me. I would recommend adding this to the document.

Is my proposal to add

   The memory allocated for the output variables must not be released
   by the application.

OK?  (Note I changed "should" into "must" here.)

My text takes care of guidance for application writers, which I think is
more important.  What Nico wrote is guidance for GSS-API authors.  Text
proposals welcome to add that welcome. ;)

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Jul 2009 10:32:27 -0500

> This is fine with me. I would recommend adding this to the document.

I'd say we must add it.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Jul 2009 10:51:32 -0500

> OK?  (Note I changed "should" into "must" here.)

Capitalized?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Jul 2009 10:46:51 -0500

> to the sections for new GSS-API interfaces?

That's exactly it: there's no need to release these outputs as they
should be constants, effectively.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Jul 2009 19:15:42 +0200

>> OK?  (Note I changed "should" into "must" here.)

Right, I'm now using that text with MUST NOT in my local copy [1].

/Simon

[1] Always available from
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jul 2009 19:17:14 +0200

[...]

>proposals welcome to add that welcome. ;)
Your version is fine as well.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Jul 2009 15:52:10 -0500

Jeff Hutzelman points out that RFC2744 specifically requires that all
gss_buffer_t outputs be released.  That wouldn't bother me at all here
(we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
chance to do that and didn't, so I'd say that these output buffers
should be released by the app.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Jul 2009 23:21:11 +0200

> should be released by the app.

Good catch, I have removed the paragraph.  How memory should be managed
by applications (i.e., they have to be released) then follows directly
from the normative RFC 2744 and GS2 shouldn't say anything about it.
Alexey, I hope this resolves your question.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Jul 2009 16:39:03 -0500

> Alexey, I hope this resolves your question.

It's useful for GS2 to remind the reader of the application's
responsibility to release these buffers (RFC5587 will do just that).

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 30 Jul 2009 12:10:26 +0200

> responsibility to release these buffers (RFC5587 will do just that).

RFC 2743 uses comments on the output variables, so I used the same, as
in:

   o sasl_mech_name UTF-8 STRING -- SASL name for this
     mechanism; caller must release with
     GSS_Release_buffer()

   o mech_name UTF-8 STRING -- name of this mechanism, possibly
     localized; caller must release with GSS_Release_buffer()

   o mech_description UTF-8 STRING -- possibly localized
     description of this mechanism; caller must release with
     GSS_Release_buffer()

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Jul 2009 13:19:56 +0200

>Alexey, I hope this resolves your question.
Can we say that informatively in the document, considering that this 
mistake was done before?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Jul 2009 13:29:21 +0200

Simon Josefsson wrote:

>Yep, the variable descriptions now follows the style used by RFC 2743 to
>document this, e.g.:
>
>Is this clear enough?
Yes.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 30 Jul 2009 13:25:20 +0200

Is this clear enough?

/Simon