Subject: Comments on draft-ietf-sasl-gs2-11.txt

From: Alexey Melnikov <[email-masked]>
Date: Mon, 13 Apr 2009 23:39:56 +0100

GS2 SASL mechanism names must be 20 characters (after removing “GS2-“ 
prefix and “–PLUS” suffix). The following text in Section 3.3 is out of 
date:

The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
binary, and re-group them in groups of 5, and convert them back to
decimal, which results in these computations:

It should say instead “the first 7 octets, drop 1 bit”.

In Section 4.1:

Also, the server SHOULD refrain from sending GSS-API error tokens
(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
along with a major status code other than GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.

I am not sure I agree – SASL error reporting is poor.

Later in the same section:

gs2-std-mech = "F"
;; "F" means the mechanism is NOT is a
Extra “is”
;; standard GSS-API mechanism in that the
;; RFC2743 section 3.1 header was missing

The server MUST replace any occurance of "=" (comma) in the string

s/(comma)/(equal sign)

with "=3D".

Should the document require application of SASLPrep to authorization 
identity? I think it should, or SCRAM is not going to match GS2.
If SASLPrep is to be used, then SASLPrep errors should also be listed in 
Section 7.

In Section 5:

If the server supports channel binding then it must list both forms

s/must/MUST

of the SASL mechanism name for each GSS-API mechanism supported via
GS2 (i.e., GSS-API mechanisms that support channel binding).

Example #4: using channel binding.

C: Request authentication exchange
S: Empty Challenge
C: yauthzid=someuser, <initial context token with standard

Should this start with “p”?

header removed>
S: Send reply context token as is

10.  GSS_Mechanism_SASLname call

   To allow SASL implementations to query for the SASL mechanism name of
   a GSS-API mechanism, we specify a new GSS-API function for this
   purpose.

      Inputs:

      o desired_mech OBJECT IDENTIFIER

      Outputs:

      o sasl_mech_name OCTET STRING -- SASL name for this mechanism
        (really, ASCII)

      o mech_name UTF-8 STRING -- name of this mechanism, possibly
        localized

      o mech_description UTF-8 STRING -- possibly localized
        description of this mechanism.

With my Apps AD hat on: if you want to allow localization, you need a 
way to control language/local. So a new parameter for language tags is 
needed (see RFC 4646).

In Section 14.3:

GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
be used as a GS2 mechanism. To make this easier for SASL
implementations we assign a symbolic SASL mechanism name to the
SPNEGO GSS-API mechanism: "SPNEGO".

If SPNEGO is disallowed in GS2, why do we assign a name to it?

The channel binding data MAY be sent (byt the actual GSS-API

Typo: by

mechanism used) without confidentiality protection and knowledge of
it is assumed to provide no advantage to an MITM (who can, in any
case, compute the channel binding data independently). If the
external channel does not provide confidentiality protection and the
GSS-API mechanism does not provide confidentiality protection for the
channel binding data, then passive attackers (eavesdroppers) can
recover the channel binding data. See [RFC5056].

[…]

GS2 does not directly use any cryptographic algorithms, therefore it
is automatically "algorithm agile", or, as agile as the GSS-API
mechanisms that are available for use in SASL apoplications via GS2.

Typo: applications

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 02:14:37 +0200

Alexey Melnikov <[email-masked]> writes:

> prefix and “–PLUS” suffix). The following text in Section 3.3 is out
> of date:
>

Thanks, fixed.

> I am not sure I agree – SASL error reporting is poor.

Are you asking for GSS-API error tokens to be sent?

I agree with you that SASL error reporting is poor, but I'm not sure
sending GSS-API error tokens will help -- the problem is typically the
APIs between the SASL library and the application.  Also, GSS-API error
reporting is also generally poor (e.g., no localization).

> ;; RFC2743 section 3.1 header was missing

Fixed, thanks.

> The server MUST replace any occurance of "=" (comma) in the string

I used 'equals' instead, as per RFC 20.

> If SASLPrep is to be used, then SASLPrep errors should also be listed
> in Section 7.

SASLPrep of authorization identities is an application issue, not a SASL
mechanism issue.  As such, SCRAM should not perform SASLprep of
authzid's.

> GS2 (i.e., GSS-API mechanisms that support channel binding).

Done.

> S: Send reply context token as is

Yes.

> way to control language/local. So a new parameter for language tags is

I removed the part about localization.  Frankly, I'm not sure the
'mech_name' and 'mech_description' fields are useful.  The important
part is the 'sasl_mech_name' field.

> If SPNEGO is disallowed in GS2, why do we assign a name to it?

Presumably in case SPNEGO is going to be used in SASL:

		    [What about SASL apps that don't do mechanism
		    negotiation?  Probably none exist.  But if any did
		    then presumably it would OK to use the SPNEGO
		    mechanism, no?  -Nico]</t>

However, I'm also a bit skeptical about assigning a name for it.

> mechanisms that are available for use in SASL apoplications via GS2.

Thanks.

Updated document:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt

Changes compared to -11:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html

Please verify that your suggestions have been fixed.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Apr 2009 07:35:30 +0100

>Alexey Melnikov <[email-masked]> writes:
 [...]

>Are you asking for GSS-API error tokens to be sent?
Yes. I don't see a reason why it shouldn't.

>reporting is also generally poor (e.g., no localization).
 [...]

>>S: Send reply context token as is    
Should "p" also be preceeded by "F"?
 [...]

>>The channel binding data MAY be sent (byt the actual GSS-API
I've changed "byt" to "but"?

>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html
Other changes look good. (I am still thinking about your SASLPrep response)

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Apr 2009 07:41:35 +0100

Simon Josefsson wrote:

>I removed the part about localization.
>
Actually, I am not convinced this is sufficient.

>Frankly, I'm not sure the
>'mech_name' and 'mech_description' fields are useful.
>
I am not sure the "mech_name" field is useful.

>The important part is the 'sasl_mech_name' field.
>  
>
Yes.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 10:06:01 +0200

> Yes. I don't see a reason why it shouldn't.

Nico, what do you think here?

I don't care strongly.  My experience with GSS-API is that you can't
expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
error tokens on failures.  However, that could be seen as a bug.

I don't see any critical problem in allowing error tokens to be sent.
If we allow it, we need to require that implementations needs to make
sure they don't endlessly send error tokens back and forward, don't we?
Otherwise I think we may end up in an infinite loop.

> Should "p" also be preceeded by "F"?

Yes.  I also noticed it should use 'a=someuser' instead of
'authzid=someuser'.

However, it would be nice with more detailed examples and explaining
text.

> I've changed "byt" to "but"?

Should be fixed.

> Other changes look good. (I am still thinking about your SASLPrep response)

Compare RFC 4616:

   The authorization identity (authzid), authentication identity
   (authcid), password (passwd), and NUL character deliminators SHALL be
   transferred as [UTF-8] encoded strings of [Unicode] characters.  As
   the NUL (U+0000) character is used as a deliminator, the NUL (U+0000)
   character MUST NOT appear in authzid, authcid, or passwd productions.

   The form of the authzid production is specific to the application-
   level protocol's SASL profile [SASL].  The authcid and passwd
   productions are form-free.  Use of non-visible characters or
   characters that a user may be unable to enter on some keyboards is
   discouraged.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 10:13:27 +0200

>>The important part is the 'sasl_mech_name' field.

I agree.  I've removed mech_name and mech_description from the document
now.  The fields are not used by GS2.  They are just a nice thing to
have for GSS-API generally.  Spending time to add it and fix
localization doesn't seem like the best use of our time.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Apr 2009 09:52:57 +0100

>Otherwise I think we may end up in an infinite loop.
IMHO, this would be a bug in a GSS-API mechanism and/or implementation.
But it wouldn't hurt to say explicitly.

>However, it would be nice with more detailed examples and explaining
Oh, good point.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 11:20:33 +0200

> But it wouldn't hurt to say explicitly.

I'm not certain of that: if context establishment enters into an error
case, sending an error token is expected.  The response to an error
token could be another error token.  And so on.  I don't find any text
that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
say something about this.

Hm.  Thinking more about this, I'm not sure it is possible to send an
error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
should fail.  There is no way to associate a SASL failure with some
data, is there?  We could delay the SASL failure though.

So either we replace the paragraph above with:

		<t>The client and server MUST NOT send any GSS-API
		    tokens (tokens output by GSS_Init_sec_context() or
		    GSS_Accept_sec_context() when the major status
		    code is other than GSS_S_COMPLETE or
		    GSS_S_CONTINUE_NEEDED) as this indicate an error
		    situation and the SASL negotiation MUST fail.</t>

Or

		<t>The client and server MAY send GSS-API error tokens
		    (tokens output by GSS_Init_sec_context() or
		    GSS_Accept_sec_context() when the major status
		    code is other than GSS_S_COMPLETE or
		    GSS_S_CONTINUE_NEEDED).  As this indicate an error
		    condition, after sending the token, the sending
		    side should fail the authentication.</t>

Is there any other option?

Thoughts?

I suspect Nico have some insight into this.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 12:00:04 +0200

>> Should "p" also be preceeded by "F"?

No, this was wrong -- the only time the "F" should be present is when
the client were unable to remove the standard GSS-API token header.  I
tried to clarify the document, and fixed the examples.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Apr 2009 11:58:39 +0100

Simon Josefsson wrote:

>data, is there?
There isn't, but an endpoint can send some data that would cause the 
other end to fail the authentication exchange.

>We could delay the SASL failure though.
>
I can't think of any.
Obviously, I prefer the latter.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 14 Apr 2009 10:47:48 -0400

> say something about this.

A GSS-API mechanism spec that allows this to result in an infinite loop is 
buggy.  The simplest way to handle this is for processing of an error token 
to not ever produce an output_token.  More complicated approaches are 
possible, but generally unnecessary, since an "error token" already 
indicates the context establishment is going to fail.

In fact, I think it is reasonable for a GSS-API application to assume that 
any context establishment call which produces a major status other than 
GSS_S_CONTINUE_NEEDED does not expect a reply, and thus the call should not 
be made again.

> data, is there?  We could delay the SASL failure though.

Yes, you'd have to delay the SASL failure for a round trip, if the error 
token is emitted by the SASL server.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 14 Apr 2009 10:56:41 -0400

--On Monday, April 13, 2009 11:39:56 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

> With my Apps AD hat on: if you want to allow localization, you need a way
> to control language/local. So a new parameter for language tags is needed
> (see RFC 4646).

Actually, no, you don't, because this is an abstract API, not a protocol, 
and the correct answer is platform- and language-binding dependent.  In 
particular, the correct answer is almost certainly to extract the name from 
a message catalog corresponding to the user's current locale, or some 
platform-specific equivalent.  In any case, localization of the GSS-API is 
definitely _not_ in the scope of the SASL WG.

I think the right thing to do here is to remove the mech_name and 
mech_description outputs, which are not SASL-specific and have nothing to 
do with the purpose of this call.  That information should be obtained via 
a separate GSS_Display_mech call, to be defined in KITTEN.

For that matter, this call really ought to be renamed something like 
GSS_Inquire_mech_sasl_name, for consistency with the way the abstract 
GSS-API is defined.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 17:37:25 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> Actually, no, you don't, because this is an abstract API, not a
> protocol, and the correct answer is platform- and language-binding
> dependent.  In particular, the correct answer is almost certainly to
> extract the name from a message catalog corresponding to the user's
> current locale, or some platform-specific equivalent.  In any case,
> localization of the GSS-API is definitely _not_ in the scope of the
> SASL WG.

Agreed.

> mech_description outputs, which are not SASL-specific and have nothing
> to do with the purpose of this call.  That information should be
> obtained via a separate GSS_Display_mech call, to be defined in
> KITTEN.

Yup.

> GSS_Inquire_mech_sasl_name, for consistency with the way the abstract

Yes.  I have renamed it to GSS_Inquire_SASLname_for_mech.  I think that
is slightly better because it puts the property to query for first,
which is consistent with the two GSS_Inquire_* support calls.  It also
makes the function name the reverse of the GSS_Inquire_mech_for_SASLname
which also seems good for consistency.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 17:41:27 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> A GSS-API mechanism spec that allows this to result in an infinite
> loop is buggy.

Where is the requirement that makes such behaviour buggy?

If there is none in RFC 2743 I think GS2 needs to discuss this.
Further, in that case, I'm not even sure you can claim that it is buggy.

> The simplest way to handle this is for processing of an error token to
> not ever produce an output_token.  More complicated approaches are

Consider if the receiver is unable to parse an incoming token, and
doesn't know whether it is a normal context token or an error token.
Sending a error token back doesn't seem entirely unreasonable to me.

> In fact, I think it is reasonable for a GSS-API application to assume
> that any context establishment call which produces a major status
> other than GSS_S_CONTINUE_NEEDED does not expect a reply, and thus the
> call should not be made again.

Right, and the GS2 implementation is an GSS-API application here, so the
GS2 document should explain this.

> Yes, you'd have to delay the SASL failure for a round trip, if the
> error token is emitted by the SASL server.

Right.

Do you have a preference between my 1) and 2) option?

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 11:38:49 -0500

> error tokens on failures.  However, that could be seen as a bug.

I don't care strongly, and I don't agree with your experience -- error
tokens are *very* useful.  However, I've had this discussion with Sam in
the past and he's always insisted that there should be an option to not
send error tokens, and the motivation for that is to avoid leaking
information to attackers.

> I don't see any critical problem in allowing error tokens to be sent.

I don't either.  I think we should make that a MAY.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 11:41:14 -0500

> > Should "p" also be preceeded by "F"?

Only if the GSS mechanism is not a "standard" mechanism -- the "F" means
just that.  The Kerberos V mechanism is and SCRAM will be standard in
the RFC2743 sense, therefore the "F" should NOT be present in the case
of SASL/GS2 w/ Kerberos V or SCRAM.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 11:45:59 -0500

> >I removed the part about localization.

No!  These are purely local localizations, not part of any protocol.
There's no need to mention language tags.

Please restore the text about localization.

> I am not sure the "mech_name" field is useful.

Possibly not, indeed.  ("EXTERNAL", "PLAIN" could be localized, others
probably not.)

> >The important part is the 'sasl_mech_name' field.

Not only.  The mech_description is important too for observability.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 11:43:34 -0500

> Where is the requirement that makes such behaviour buggy?

We don't need any stinking RFCs to tell us that infinite loops are bugs.

I almost put in a smiley, but I'm too serious about this assertion.
Some things should be self-evident, and this is one of them.  I will not
work on an update to the GSS-API just to make this clarification if it
isn't already clear.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Apr 2009 18:06:59 +0100

>There's no need to mention language tags.
Well Ok. But the document still needs to say how localization is controlled.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 12:13:43 -0500

> Well Ok. But the document still needs to say how localization is controlled.

It's a _local_ matter.  Like lots of other APIs.  The localization is to
the caller's _locale_, which is a _local_ matter.

There's nothing more for the spec to say, except perhaps that the
localization is to the caller's locale.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 18 Apr 2009 12:53:40 +0200

> localization is to the caller's locale.

I've restored this part of the document.  I don't care strongly about
this feature, but it is marginally potentially useful.  Let's see if it
passes further review.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Apr 2009 12:42:57 +0200

> I don't either.  I think we should make that a MAY.

Two people in favor, none against, and discussion has stopped.  I
incorporated the proposed text.  See http://josefsson.org/sasl-gs2/ for
updated document.

I believe this addresses all of Alexey's comments made in this thread.
If I missed some comment, please let me know.

/Simon