Subject: WG Last Call: draft-ietf-sasl-scram-02

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

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

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-02.txt
	Pages           : 33
	Date            : 2009-07-08

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: Chris Newman <[email-masked]>
Date: Mon, 27 Jul 2009 15:17:20 +0200

It's been a while since I read this, so I re-read it from scratch.  Mostly 
editorial nits:

Section 3:
   implementation may chose to use the same iteration count for all
   account.)  The server sends the salt and the iteration count to the
   ^^^^^^^
   accounts

Section 7:
>     generic-message = attr-val *("," attr-val)
>                       ;; Generic syntax of any server challenge
>                       ;; or client response

I observe that gs2-header does not conform to "generic-message" if it 
begins with "y" or "n".  This inconsistency could be resolved by removing 
"generic-message" from the document.

Section 10:
>   SASL Mechanisms registry.  IANA is requested to prevent future
>   registrations of SASL mechanisms starting with SCRAM- without
>   consulting the SASL mailing list <[email-masked]> first.

This at least needs to designate a successor review process if 
[email-masked] goes away.  I'd also prefer the document enumerate 
principles for when to allow registration.  Personally, I consider 
undesirable to have the family be large.  I'd prefer it contain only 
SCRAM-SHA-1, and in the future SCRAM-SHA-3 (with the -PLUS variants). 
Perhaps we could briefly discuss this at the meeting.

I support advancement of this version of the document on the standards 
track.

I intend to implement it excluding section 8 and SASLprep.  I will attempt 
to implement channel bindings, but it has gotten fairly complex 
particularly with all this stuff about different types of channel bindings. 
I am unsure how difficult it will be to add channel binding support to NSS. 
In the event I succeed with channel bindings, but subsequently experience 
interoperability problems with channel bindings, I will remove all channel 
binding support from my implementation.

		- Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 27 Jul 2009 10:48:46 -0400

--On Monday, July 27, 2009 03:17:20 PM +0200 Chris Newman 
<[email-masked]> wrote:

> [email-masked] goes away.

I don't think it does.  There's plenty of precedent for setting up a 
mailing list as the reviewer; if the list goes away, the IESG can designate 
a new reviewer.

>  I'd also prefer the document enumerate

I agree the growth rate should be small, and mostly related to the 
introduction of successor hashes.

> I intend to implement it excluding section 8 and SASLprep.  I will
> attempt to implement channel bindings, but it has gotten fairly complex

If you ignore the discussions and look at the result, it's not that 
complex.  Assuming CB is being used, the client tells the server what type 
to use.  For now the only type is TLS.  If you're a server and see 
something else, you can reject it out of hand.  If you're a client, have a 
TLS channel, and succesfully negotiate the use of channel bindings 
according to the spec, you can assume the server will support TLS.

> I am unsure how difficult it will be to add channel binding
> support to NSS. In the event I succeed with channel bindings, but
> subsequently experience interoperability problems with channel bindings,
> I will remove all channel binding support from my implementation.

What this tells me is that you don't consider this an important feature. 
That's unfortunate, because I consider security to be a very important 
feature, and if implementors won't commit to implementing a security 
feature, we have no chance of getting operators and users to actually use 
it.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Jul 2009 22:57:26 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> mailing list as the reviewer; if the list goes away, the IESG can
> designate a new reviewer.

How about changing the e-mail address to [email-masked] so the e-mail
name is at least under the IETF's control?  The address can be a forward
to this list, if we for some reason don't want to move the list to
[email-masked] as well.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 10:03:29 +0200

I'll get to reviewing the technical part of the document, promise! :)

Running idnits on the document, it says

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

The document has a long history, is the current legal boilerplate ok?

Idnits also complains about these references, but these complaints seems
bogus:

  == Missing Reference: 'I-D.ietf-sasl-gs2' is mentioned on line 1014, but
     not defined

  == Missing Reference: 'RFC2743' is mentioned on line 1019, but not defined

  == Missing Reference: 'RFC4121' is mentioned on line 1025, but not defined

  == Missing Reference: 'RFC3962' is mentioned on line 1022, but not defined

  == Missing Reference: 'RFC4401' is mentioned on line 1030, but not defined

  == Missing Reference: 'RFC4402' is mentioned on line 1034, but not defined

  == Missing Reference: 'RFCXXXX' is mentioned on line 807, but not defined

However there are several documents added as references but not
mentioned in the document itself:

  == Unused Reference: 'I-D.ietf-sasl-rfc2831bis' is defined on line 1050,
     but no explicit reference was found in the text

  == Unused Reference: 'RFC2195' is defined on line 1055, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2202' is defined on line 1059, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4086' is defined on line 1065, but no explicit
     reference was found in the text

The first three should probably be just removed (?).  But the last one
seems useful to reference normatively.  How about adding the following
to Security Considerations?

  See [RFC4086] for more information about generating randomness.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 10:08:12 +0200

> The document has a long history, is the current legal boilerplate ok?

This was fixed in -02, sorry I ran an older document through idnits.

>      reference was found in the text

This comment still holds.  -02 also contain a dangling reference to
PKIX:

  == Unused Reference: 'RFC5280' is defined on line 1042, but no explicit
     reference was found in the text

>   See [RFC4086] for more information about generating randomness.

This comment also still holds.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 11:05:26 +0200

The IANA section says:

   IANA is requested to prevent future registrations of SASL mechanisms
   starting with SCRAM- without consulting the SASL mailing list
   <[email-masked]> first.

I'm not sure how the IANA would parse this request.  Who on this list
has authority to say yes or no to IANA?  For clarity, I think we should
use one of the terms defined by RFC 2434.  Is this IETF Consensus?  Or
Expert Review?  Or Standards Action?

My preference is to explicitly state that the process to register
further SCRAM-* mechanisms is IETF Consensus, defined like this:

      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG. Typically, the IESG will seek
           input on prospective assignments from appropriate persons
           (e.g., a relevant Working Group if one exists).

This appears to match the intention based on my reading.

If there are strong preferences for anything else, I don't feel strongly
about it as long as it uses some term defined in RFC 2434.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 11:13:45 +0200

Regarding

   [tls-unique]
              Zhu, L., "Registration of TLS unique channel binding
              (generic)", IANA http://www.iana.org/assignments/
              channel-binding-types/tls-unique, July 2008.

I think we should replace that with a reference to

http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05

and move that document along.  There is text in the registration that
have direct implementation consequences and security implications, so I
believe it has to be in a persistent and normative document.  Thoughts?

(Yes, this applies to GS2 as well.)

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 11:16:17 +0200

Chris Newman <[email-masked]> writes:

> begins with "y" or "n".  This inconsistency could be resolved by
> removing "generic-message" from the document.

The "generic-message" rule is never mentioned elsewhere (noticed by
running Bill Fenner's ABNF parser), so I would also prefer to remove the
rule.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jul 2009 12:09:33 +0200

>http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05
This would mean a new normative reference and would delay publication of 
both documents.
While I think it would be nice to use this reference, I am against 
blocking SCRAM and GS2 on this.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jul 2009 12:15:59 +0200

>Simon Josefsson <[email-masked]> writes:
 [...]

>     reference was found in the text
All removed in my copy.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jul 2009 12:21:59 +0200

Simon Josefsson wrote:
 [...]

 [...]

>  See [RFC4086] for more information about generating randomness.
Done.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jul 2009 12:27:35 +0200

>running Bill Fenner's ABNF parser), so I would also prefer to remove the
Removed in my copy.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 12:44:13 +0200

Alexey Melnikov <[email-masked]> writes:

> This would mean a new normative reference and would delay publication
> of both documents.

OK, I'm fine with that -- it will mean a downref (right?), and I assumed
those causes other sorts of problems that could be avoided.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jul 2009 13:09:35 +0200

>those causes other sorts of problems that could be avoided.
I am not entirely sure if it is. But I don't think it will be 
problematic with IESG, even if it.

---

From: Chris Newman <[email-masked]>
Date: Tue, 28 Jul 2009 14:11:45 +0200

> feature, we have no chance of getting operators and users to actually use

I consider TLS channel bindings very important, so much so I'm willing to 
invest significant effort attempting an implementation.  But there are 
three directions typical deployments could go here: 1. most people use 
"PLAIN+TLS", 2. SCRAM+TLS-no-channel-bindings gets deployed, 3. 
SCRAM+TLS-with-channel-bindings gets deployed.  If the attempt at 3 is 
non-interoperable, then 1 will be the result as people will associate 
"SCRAM" with "doesn't work".  I strongly prefer option 2 to 1 and will act 
accordingly.  All this talk of channel binding negotiation is leading in 
the direction of non-interoperability and is risking the possibility of 
success with option 3.  I am stating up front that I'll fight for option 2 
if option 3 looks like it will fail.  It's exactly because I care about 
actually getting security deployed that I'm willing to lose the channel 
binding feature if necessary to get an incremental improvement.

Now that you've goaded me to explain my concern.  I'll make a concrete 
suggestion to improve the SCRAM channel bindings section.  I suggest we 
replace this text:

   Clients SHOULD choose the tls-unique channel binding type.
   Conversely, clients MAY choose a different channel binding type based
   on user input, configuration, or a future, as-yet undefined channel
   binding type negotiation protocol.  Servers MUST choose the channel
   binding type indicated by the client, if they support it.

with:

   Clients MUST use the tls-unique channel binding type if a TLS channel is
   active when SCRAM is used.  Clients MAY use a different channel binding 
type if
   an as-yet undefined channel binding type negotiation has confirmed the 
server
   supports the channel-binding type the client selects.

This way, SCRAM+TLS-channel-bindings will interoperate.  With the current 
vague text, it's possible for a compliant client's SCRAM implementation to 
fail to interoperate when communicating with a compliant server's SCRAM + 
TLS-channel-bindings implementation.

		- Chris

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 14:30:39 +0200

Chris Newman <[email-masked]> writes:

> I consider TLS channel bindings very important, so much so I'm willing
> to invest significant effort attempting an implementation.  But there
> are three directions typical deployments could go here: 1. most people
> use "PLAIN+TLS", 2. SCRAM+TLS-no-channel-bindings gets deployed,
> 3. SCRAM+TLS-with-channel-bindings gets deployed.  If the attempt at 3
> is non-interoperable, then 1 will be the result as people will
> associate "SCRAM" with "doesn't work".  I strongly prefer option 2 to
> 1 and will act accordingly.  All this talk of channel binding
> negotiation is leading in the direction of non-interoperability and is
> risking the possibility of success with option 3.  I am stating up
> front that I'll fight for option 2 if option 3 looks like it will
> fail.  It's exactly because I care about actually getting security
> deployed that I'm willing to lose the channel binding feature if
> necessary to get an incremental improvement.

FWIW, I largely share your concern.  I may be more hopeful about getting
3 to work in practice though, technically it seems easy to implement.

> suggestion to improve the SCRAM channel bindings section.  I suggest
> we replace this text:
>
>   active when SCRAM is used.  Clients MAY use a different channel
> binding type if
>   an as-yet undefined channel binding type negotiation has confirmed
> the server
> This way, SCRAM+TLS-channel-bindings will interoperate.  With the
> current vague text, it's possible for a compliant client's SCRAM
> implementation to fail to interoperate when communicating with a
> compliant server's SCRAM + TLS-channel-bindings implementation.

I'm not sure this change is good -- first, the MUST is clearly violated
when the MAY-path is exercised, so it is not internally consistent.
This was one of the motivations for SHOULD, IIRC, although I agree that
it wasn't completely clear before either.  Also you dropped the last
sentence which is necessary to get interoperability.  How about:

   Clients MUST use the tls-unique channel binding type if a TLS channel
   is active when SCRAM is used, or MAY use a different channel binding
   type if an as-yet undefined channel binding type negotiation has
   confirmed the server supports the channel-binding type the client
   selects.  Servers MUST choose the channel binding type indicated by
   the client, if they support it.

?

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 28 Jul 2009 09:50:24 -0400

> Expert Review?  Or Standards Action?

I'm pretty sure it's Expert Review with a mailing list as the expert.  But 
given the agreement we seemed to have during yesterday's meeting that this 
family should have slow growth accommodating only successor hashes, I think 
Standards Action would be more appropriate.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 16:12:53 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> I'm pretty sure it's Expert Review with a mailing list as the expert.

I see.  I didn't know an open mailing list could be a Designated Expert.

> But given the agreement we seemed to have during yesterday's meeting
> that this family should have slow growth accommodating only successor
> hashes, I think Standards Action would be more appropriate.

Works fine with me.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Jul 2009 10:57:08 -0500

> (Yes, this applies to GS2 as well.)

This means that GS2 and SCRAM will block on the RFC-Editor queue on
draft-altman-tls-channel-bindings.  That's not a big deal to me, but it
might be to someone else.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Jul 2009 11:01:11 -0500

> those causes other sorts of problems that could be avoided.

You know, since the registration exists already, it's possible that the
downref could be allowed at publication time.

Or, better yet, how about:

 - have a normative reference to [tls-unique] as in the I-D right now

and

 - have an informative reference to draft-altman-tls-channel-bindings.

A creative idea, maybe too creative :)

But at least readers will be able to find whatever RFC number
draft-altman-tls-channel-bindings is ultimately published as, either by
looking at the IANA registration for tls-unique or by looking in the I-D
DB for draft-altman-tls-channel-bindings.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jul 2009 18:30:24 +0200

>I see.  I didn't know an open mailing list could be a Designated Expert.
I haven't heard of such cases either: somebody has to be a gatekeeper.

>>hashes, I think Standards Action would be more appropriate.
Works for me as well.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Jul 2009 11:10:48 -0500

On Tue, Jul 28, 2009 at 02:11:45PM +0200, Chris Newman wrote:
>          ...  All this talk of channel binding negotiation is leading in 
> success with option 3.  ...

There was an unfortunately long thread on that topic.  The consensus
that we reached was that we'd NOT bother with channel binding type
negotiation for now.

I chatted with you and found that your concern is primarily about the
fact that we say that the client SHOULD, not MUST, use tls-unique.  I'm
willing to tighten this to a MUST.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Jul 2009 11:14:48 -0500

> when the MAY-path is exercised, so it is not internally consistent.

We do this all the time in IETF protocols, where we say that one MUST
send 0 in some field that's reserved for future extensions, and we state
how one must react to non-zero values in that field, then later we relax
that and say what values may be sent.  What should happen here is that
the second sentence in Chris' proposed text should just be removed -- a
future update will not be bound to keep the MUST in the first sentence.

> sentence which is necessary to get interoperability.  How about:

No, _my_ motivation for that SHOULD was to allow clients and servers to
agree a priori and out of band to use some other CB type than
tls-unique.  I'll be happy to see this SHOULD turn into a MUST.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 23:23:20 +0200

> future update will not be bound to keep the MUST in the first sentence.

Right.

> tls-unique.

That is what I meant too.

> I'll be happy to see this SHOULD turn into a MUST.

The last sentence still seems necessary though.  So the paragraph
becomes:

  Clients MUST choose the tls-unique channel binding type.  Servers MUST
  choose the channel binding type indicated by the client, if they
  support it.

I suspect we want SCRAM and GS2 to be consistent on this, right?  So
both documents needs this change.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Jul 2009 16:43:38 -0500

> both documents needs this change.

Yes.

Also, we should allow application protocols to specify a different CB
type.

   Clients MUST choose the default channel binding type for the
   application -- 'tls-unique' for any applications that don't specify
   one.  Servers MUST choose the channel binding type indicated by the
   client, or fail authentication if they don't support it.

Nico
--

---

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

>    client, or fail authentication if they don't support it.

Works for me.  Chris, Alexey, others, are you OK with that text?  I'll
update my copy of GS2 to use it if we all agree on this text.

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Jul 2009 13:31:51 +0200

> problematic with IESG, even if it.

I must say that point to the IANA registration as the definitive
reference for tls-unique confused me, since it is not a specification.
If we could somehow include a reference to the I-D, I think that we
could avoid confusing some implementers.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jul 2009 13:37:00 +0200

>could avoid confusing some implementers.
The reference includes the whole definition.
If the draft describing this in more details is published, I would have 
no problems referencing it.

But as I said earlier, I would rather not block on this extra document.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jul 2009 13:40:39 +0200

Alexey Melnikov wrote:

> If the draft describing this in more details is published, I would 
> have no problems referencing it.

> But as I said earlier, I would rather not block on this extra document.

Having said that, I am Ok with adding an informative reference.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Jul 2009 13:58:28 +0200

> send technical feedback to the WG mailing list, and editorial comments

Some nits...

SECTION 2

Typo: "family of mechanism" => "family of mechanisms"

The second paragraph references security layers, which are not
previously defined (and no reference is made to RFC 5056 here).

Under protocol features, the document says that "A standard attribute is
defined to enable storage of the authentication information in LDAPv3"
but I don't see where this attribute is defined in the spec.

SECTION 3

The specification assumes that "the client is in possession of a
username and password"; does it make sense to mention the fact that
passwordless login can occur in this world (Kerb, X.509, etc.)?

SECTION 4

Typo: "hashed function" => "hash function"

I think the following text is slightly ambiguous:

   The "-PLUS" suffix is used only when the server supports channel
   binding to the external channel.  In this case the server will
   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
   negotiation of the use of channel binding.  See Section 6.

This could be read to mean that if a server does not support channel
bindings, then it will advertise only all and only SCRAM-SHA-1 (but
never, say, SCRAM-SHA-256). I think we mean that if a server does not
support channel bindings, then it will advertise only mechanisms of the
form SCRAM-SHA-length and never mechanisms of the form
SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
other than SHA-1).

SECTION 5

There is an example of "tls-server-end-point" but no reference for this
channel binding type.

SECTION 5.1

For the definition of "n", the text says that "a client must include it
in its first message to the server"; do we mean MUST here?

The "n" attribute specifies a username. Is it up to the using protocol
define exactly what a username is? I am thinking of hosting providers
that might host multiple domains for a given service, such that the the
username is not a "local-part" but could include a domain name (XMPP is
but one example; others might include IMAP).

For the "n" attribute, "the server SHOULD prepare it using the
"SASLPrep" profile". Under what circumstances is it appropriate for the
server to not prepare the value according to SASLPrep?

Typo: "It is important that this be value" => "It is important that this
value be"

Typo: missing close paren after the reference to RFC 5056

For the "i" attribute, the text says that it "must be sent by the server
along with the user's salt"; do we mean MUST here?

SECTION 6

Typo: "MUST chose" => "MUST choose"

SECTION 8.2

Typo: "SHALL BE" => "SHALL be"

APPENDIX A

CRAM-MD5 is mentioned as another authentication mechanism, seemingly
with the meaning that SCRAM is intended to obsolete CRAM-MD5. I recall
an objection by John Klensin at the mic in San Francisco that in fact
SCRAM is intended to obsolete DIGEST-MD5 but not CRAM-MD5. But perhaps
that is a matter for draft-ietf-sasl-crammd5-to-historic, not this
specification.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

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

> Having said that, I am Ok with adding an informative reference.

I've done this to GS2, i.e., add normative reference to IANA
registration and informative reference to
I-D.altman-tls-channel-bindings, both cited at the same place in the
document.

/Simon

---

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

> Having said that, I am Ok with adding an informative reference.

The I-D in question ought to progress very quickly, one would think.
I should ask an AD to shepherd it.  I will.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Jul 2009 10:06:08 +0200

Chris Newman wrote:

> It's been a while since I read this, so I re-read it from scratch.  
> Mostly editorial nits:
>
> Section 3:

Fixed.

Done.

> [email-masked] goes away.

I've added "(or a successor designated by the responsible Security AD)".

> I'd also prefer the document enumerate principles for when to allow 
> registration.  Personally, I consider undesirable to have the family 
> be large.  I'd prefer it contain only SCRAM-SHA-1, and in the future 
> SCRAM-SHA-3 (with the -PLUS variants). Perhaps we could briefly 
> discuss this at the meeting.

I am expecting some text :-).

> attempt to implement channel bindings, but it has gotten fairly 
> complex particularly with all this stuff about different types of 
> channel bindings. I am unsure how difficult it will be to add channel 
> binding support to NSS. In the event I succeed with channel bindings, 
> but subsequently experience interoperability problems with channel 
> bindings, I will remove all channel binding support from my 
> implementation.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Jul 2009 10:04:33 +0200

Simon Josefsson wrote:

>name is at least under the IETF's control?
>
I don't think this matters much, this is a WG mailing list and IETF has 
control over which mailing lists are used by WGs.

>The address can be a forward
As a side note: I've talked to our AD Pasi (who talked to Paul Hoffman) 
and he said that in a few months this mailing list will migrate to 
@ietf.org.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Jul 2009 10:10:53 +0200

> hashes, I think Standards Action would be more appropriate.

I think IESG would prefer a bit of flexibility. What would happen if we 
want to register a SCRAM mechanism for historic reasons (marked as 
"obsolete") in an Informational RFC? So I would rather specify IETF 
Consensus here + provide some guidance on when mechanism should be 
registered.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Jul 2009 11:12:39 +0200

>Some nits...
Some of there are more than just nits :-).
Thank you for the review!
I've responded/addressed most of your comments in my copy, I will reply 
to the rest in a separate message.

Fixed.

>previously defined
Added the reference to RFC 4422.

>(and no reference is made to RFC 5056 here).
>  
>
It is referenced in my copy.

>but I don't see where this attribute is defined in the spec.
This needs an informative reference to another draft I am editing. I 
will add.

>passwordless login can occur in this world (Kerb, X.509, etc.)?
I don't think this would help readability. I've changed "the client" to 
"the SCRAM client" in my copy. Is it any better?

 [...]

>There is an example of "tls-server-end-point" but no reference for this
I will add an informative reference.

>in its first message to the server"; do we mean MUST here?
Sure.

>but one example; others might include IMAP).
My copy already says:
    This attribute specifies the name of the
    user whose password is used for
    authentication (a.k.a. "authentication identity" <xref 
target='RFC4422'/>).

And according to RFC 4422, each mechanism defines how authentication 
identity looks like.
For SCRAM it is a "simple username" (i.e. <localpart>[@<domain>]), for 
Kerberos it is a Kerberos principal, etc.

>server to not prepare the value according to SASLPrep?
This is a cut&paste from the DIGEST-MD5 update I was working on. If I 
remember correctly there was some objection to making this a MUST. To 
this day many implementors don't implement SASLPrep, so I think this is 
a reasonable compromise.

>Typo: missing close paren after the reference to RFC 5056
Both fixed.

Yes.

>Typo: "SHALL BE" => "SHALL be"
Both fixed.

>that is a matter for draft-ietf-sasl-crammd5-to-historic, not this
Agree with the last sentence.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Jul 2009 18:21:10 +0200

> Some of there are more than just nits :-).

Well, they're not huge issues. :)

> "the SCRAM client" in my copy. Is it any better?

I suppose it's fine just to say "the client". My nit was directed elsewhere.

> Kerberos it is a Kerberos principal, etc.

My concern is that "the name of the user" could be construed to mean
"localpart", which is commonly called the "username" portion of an address.

> this day many implementors don't implement SASLPrep, so I think this is

Again, my concern is that some other preparation rule might be
appropriate (e.g., in XMPP [email-masked] is prepared according to
two separate rules because there is one rule for localpart and another
rule for domain).

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Jul 2009 18:38:02 +0200

[...]

>"localpart", which is commonly called the "username" portion of an address.
Can you recommend a better text?

>two separate rules because there is one rule for localpart and another
This applies to authorization identities in XMPP. Authorization identity 
format is protocol specific.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Jul 2009 19:26:19 +0200

> Can you recommend a better text?

So I looked at this again. The concept of a "simple username" has always
been fuzzy to me. It is described in the SASLprep document, RFC 4013. It
seems to be the localpart, not <localpart>[@<domain>] (at least, all the
examples in RFC 4013 look like localparts).

In any case, Alexey and I just talked about this in Stockholm and I
think the confusion comes in from RFC 3920, so I need to fix this in
rfc3920bis.

> format is protocol specific.

I thought that "a" was authorization identity and "n" was authentication
identity, no? In any case, I think the fixes belong in rfc3920bis, so I
shall work on that and remain quiet about this issue in the SCRAM doc.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Jul 2009 19:33:51 +0200

> SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions

Alexey and I talked about this in Stockholm. I suggest the following text:

   The "-PLUS" suffix is used only when the server supports channel
   binding to the external channel.  If the server supports channel
   binding, it will advertise both the "bare" and "plus" versions of
   whatever mechanisms it supports (e.g., if the server supports only
   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
   and SCRAM-SHA-1-PLUS); if the server does not support channel
   binding, then it will advertise only the "bare" version of the
   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
   negotiation of the use of channel binding.  See Section 6.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 30 Jul 2009 10:47:39 -0700

> examples in RFC 4013 look like localparts).

No.  Simple here means that none of the allowed characters of a  
username have any special semantics.  That is, there is no concept of  
local part or a domain part or even separator in a simple username.   
The username, to SASLprep, is just a sequence of characters.  This, of  
course, doesn't preclude implementations or deployers from attaching  
additional semantics usernames they use... but such semantics are  
completely outside of SASLprep and mechanisms that use "simple user  
names" as defined by SASLprep.

Maybe when RFC 4013 we can add an examples such as "a;b@c:d".

-- Kurt

---

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

>   negotiation of the use of channel binding.  See Section 6.
Ok, this text will be in -04.

---

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

> Ok, this text will be in -04.

Please reassure me that the same change isn't needed in GS2?  I don't
see any normative words above, and as far as I can tell the described
behaviour is already covered by other text in both SCRAM and GS2 anyway.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 31 Jul 2009 09:48:21 +0200

>behaviour is already covered by other text in both SCRAM and GS2 anyway.
While I think Peter's text is an improvement, I don't have a strong 
feeling on whether you need to add it to GS2.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 31 Jul 2009 19:14:48 -0400

> behaviour is already covered by other text in both SCRAM and GS2 anyway.

Do you think that the former text was not ambiguous?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

Date: Fri, 31 Jul 2009 19:14:48 -0400
From: Peter Saint-Andre <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

> behaviour is already covered by other text in both SCRAM and GS2 anyway.

Do you think that the former text was not ambiguous?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-scram-04.txt 
Date: Fri, 31 Jul 2009 03:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-04.txt
	Pages           : 34
	Date            : 2009-07-31

The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS.  Unfortunately, the
challenge response mechanisms presently on the standards track all
fail to meet requirements necessary for widespread deployment, and
have had success only in limited use.

This specification describes a family of Simple Authentication and
Security Layer (SASL, RFC 4422) authentication mechanisms called the
Salted Challenge Response Authentication Mechanism (SCRAM), which
addresses the security concerns and meets the deployability
requirements.  When used in combination with TLS or an equivalent
security layer, a mechanism from this family could improve the
status-quo for application protocol authentication and provide a
suitable choice for a mandatory-to-implement mechanism for future
application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-scram-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-gs2-15.txt 
Date: Fri, 31 Jul 2009 02:30:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

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

This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework.  This is done by
defining a new SASL mechanism family, called GS2.  This mechanism
family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of
channel binding.  Only GSS-API mechanisms that support channel
binding are supported.

See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-gs2-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Date: Fri, 31 Jul 2009 10:31:46 +0200
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: SASL IETF75 summary
Sender: [email-masked]

Tom Yu wrote:
 [...]

>Drop EXTERNAL from base spec?  No consensus either way.  Probably not
>a big deal; could possibly get folded into Simon's external-channel
>draft.
>
I think I've heard some support for removing SASL EXTERNAL from the base 
spec.

Date: Fri, 31 Jul 2009 09:48:21 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Peter Saint-Andre <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Peter Saint-Andre <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 30 Jul 2009 20:37:58 +0200
Sender: [email-masked]

/Simon

Date: Thu, 30 Jul 2009 19:55:44 +0200
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Cc: Alexey Melnikov <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Date: Thu, 30 Jul 2009 10:47:39 -0700
Sender: [email-masked]

-- Kurt

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-scram-03.txt 
Date: Thu, 30 Jul 2009 10:45:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-03.txt
	Pages           : 34
	Date            : 2009-07-30

The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS.  Unfortunately, the
challenge response mechanisms presently on the standards track all
fail to meet requirements necessary for widespread deployment, and
have had success only in limited use.

This specification describes a family of Simple Authentication and
Security Layer (SASL, RFC 4422) authentication mechanisms called the
Salted Challenge Response Authentication Mechanism (SCRAM), which
addresses the security concerns and meets the deployability
requirements.  When used in combination with TLS or an equivalent
security layer, a mechanism from this family could improve the
status-quo for application protocol authentication and provide a
suitable choice for a mandatory-to-implement mechanism for future
application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-scram-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Date: Thu, 30 Jul 2009 19:33:51 +0200
From: Peter Saint-Andre <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

Peter

- --
Peter Saint-Andre
https://stpeter.im/

Date: Thu, 30 Jul 2009 19:26:19 +0200
From: Peter Saint-Andre <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

Peter

- --
Peter Saint-Andre
https://stpeter.im/

Date: Thu, 30 Jul 2009 18:38:02 +0200
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

 [...]

Date: Thu, 30 Jul 2009 18:21:10 +0200
From: Peter Saint-Andre <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

Date: Thu, 30 Jul 2009 13:29:21 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

Simon Josefsson wrote:

>>>>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.
>>>>        
>>>>
>>>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.
>>>      
>>>
>>Can we say that informatively in the document, considering that this
>>mistake was done before?
>>    
>>
>Yep, the variable descriptions now follows the style used by RFC 2743 to
>document this, e.g.:
>
>   o sasl_mech_name UTF-8 STRING -- SASL name for this
>     mechanism; caller must release with
>     GSS_Release_buffer()
>
>Is this clear enough?
>  
>
Yes.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 30 Jul 2009 13:25:20 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

>>>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.
>>>    
>>>
>>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.
>>  
>>
> Can we say that informatively in the document, considering that this
> mistake was done before?

Yep, the variable descriptions now follows the style used by RFC 2743 to
document this, e.g.:

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

Is this clear enough?

/Simon

Date: Thu, 30 Jul 2009 13:19:56 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

Simon Josefsson wrote:

>>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.
>>    
>>
>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.
>  
>
Can we say that informatively in the document, considering that this 
mistake was done before?

Date: Thu, 30 Jul 2009 11:12:39 +0200
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
CC: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Fixed.

 [...]

Sure.

My copy already says:

Both fixed.

Yes.

Both fixed.

Date: Thu, 30 Jul 2009 10:06:08 +0200
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Fixed.

Done.

> bindings, I will remove all channel binding support from my 

Date: Thu, 30 Jul 2009 10:10:53 +0200
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>
CC: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Date: Thu, 30 Jul 2009 10:04:33 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 30 Jul 2009 12:10:26 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Jul 29, 2009 at 11:21:11PM +0200, Simon Josefsson wrote:
>> > 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.
>> 
>> 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.
>
> It's useful for GS2 to remind the reader of the application's
> 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

To: [email-masked]
Cc: [email-masked]
Subject: SASL IETF75 summary
From: Tom Yu <[email-masked]>
Date: Thu, 30 Jul 2009 05:22:20 -0400
Lines: 54
Sender: [email-masked]

Simple Authentication And Security Layer (SASL)
IETF75, Stockholm, Sweden

Monday, July 27, 15:20--17:20
=============================

Chairs:

Tom Yu <[email-masked]>
Kurt Zeilenga <[email-masked]>

Scribe: Peter Saint-Andre

Jabber:
http://jabber.ietf.org/logs/sasl/2009-07-27.txt

Audio:
ftp://videolab.uoregon.edu/pub/videolab/media/ietf75/ietf75-mon-rm300-pm.mp3

Agenda slides:
http://www.ietf.org/proceedings/75/slides/sasl-0.pdf

GS2 slide:
http://www.ietf.org/proceedings/75/slides/sasl-1.pdf

====================

- draft-ietf-sasl-gs2-14 -- in WGLC
- draft-ietf-sasl-scram-02 -- in WGLC
- draft-ietf-sasl-4422bis-01 -- not much progress, mostly editorial
- changes
- draft-ietf-sasl-channel-bindings-03 -- some revisions, as side
  effect of SCRAM/GS2 discussion

SCRAM and GS2 in WGLC (concluding Aug. 3); mostly editorial comments
at this point.

SASL base spec to Draft Standard: need implementation report.  4422bis
needs revised SASLprep, which Kurt will work on.  Some discussion
about normative downref to SASLprep.  Probably not a problem because
individual mechanisms are what actually normatively reference it.

Drop EXTERNAL from base spec?  No consensus either way.  Probably not
a big deal; could possibly get folded into Simon's external-channel
draft.

Milestones:

Mar 09 GS2 WGLC -- in progress
Mar 09 SCRAM WGLC -- in progress
Apr 09 decide CRAM-MD5 approach -- done; Tom will summarize to list
Jun 09 4422bis I-D -- initial revisions
Oct 09 implementation report
Oct 09 4422bis WGLC

Date: Wed, 29 Jul 2009 16:39:03 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

On Wed, Jul 29, 2009 at 11:21:11PM +0200, Simon Josefsson wrote:
> > 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.
> 
> 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.

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]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 23:21:11 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

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

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

Date: Wed, 29 Jul 2009 15:52:10 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

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.

Date: Wed, 29 Jul 2009 19:17:14 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

 [...]

>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. ;)
>  
>
Your version is fine as well.

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 19:15:42 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Jul 29, 2009 at 05:39:10PM +0200, Simon Josefsson wrote:
>> 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.)
>
> Capitalized?

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

Date: Wed, 29 Jul 2009 10:51:32 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

On Wed, Jul 29, 2009 at 05:39:10PM +0200, Simon Josefsson wrote:
> 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.)

Capitalized?

Date: Wed, 29 Jul 2009 10:46:51 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

On Wed, Jul 29, 2009 at 05:35:08PM +0200, Simon Josefsson wrote:
> 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?

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

Date: Wed, 29 Jul 2009 10:32:27 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

On Wed, Jul 29, 2009 at 05:29:35PM +0200, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >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.
> >
> This is fine with me. I would recommend adding this to the document.

I'd say we must add it.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 17:39:10 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

>>>>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?
>>>    
>>>
>>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.
>>  
>>
> 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: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 17:35:08 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
>> > 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?
>> 
>> Not sure if this needs to be mentioned, I can't find much discussion in
>> RFC 2743 on this.  Nico?
>
> 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.

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

Date: Wed, 29 Jul 2009 17:29:35 +0200
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

Nicolas Williams wrote:

>On Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
>  
>
>>>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?
>>>      
>>>
>>Not sure if this needs to be mentioned, I can't find much discussion in
>>RFC 2743 on this.  Nico?
>>    
>>
>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.
>  
>
This is fine with me. I would recommend adding this to the document.

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 17:26:16 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
>> > 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.
>> >
>> > ?
>> 
>> Nico?
>
> Fine with me.

Great, I've changed my local copy.

/Simon

Date: Wed, 29 Jul 2009 10:08:53 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

On Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
> > 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?
> 
> Not sure if this needs to be mentioned, I can't find much discussion in
> RFC 2743 on this.  Nico?

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

Date: Wed, 29 Jul 2009 10:05:26 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

On Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
> > 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.
> >
> > ?
> 
> Nico?

Fine with me.

Date: Wed, 29 Jul 2009 10:03:12 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Peter Saint-Andre <[email-masked]>, Simon Josefsson <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 14:13:23 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>> In Section 5.1:
>> 
>> >   The application-data field MUST be set to the gs2-header concatenated
>> >   with, when a gs2-cb-flag of "p" is used, the application's channel
>> >   binding data (if any).
>> 
>> I think "(if any)" should be removed, because for "p" the channel 
>> binding data is always present. I assume that a channel binding data 
>> can't be the empty string.
>
> Sure.

I have removed this in my local copy.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Peter Saint-Andre <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 13:59:29 +0200
Sender: [email-masked]

/Simon

Date: Wed, 29 Jul 2009 13:58:28 +0200
From: Peter Saint-Andre <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

Some nits...

SECTION 2

SECTION 3

SECTION 4

SECTION 5

SECTION 5.1

SECTION 6

SECTION 8.2

APPENDIX A

Peter

- --
Peter Saint-Andre
https://stpeter.im/

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 13:48:12 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Nicolas Williams wrote:
>
>>On Wed, Jul 08, 2009 at 01:11:57PM +0100, Alexey Melnikov wrote:
>>  
>>
>>>Some quick comments.
>>>
>>>In Section 3.5:
>>>    
>>>
>>>>  If the client negotiates mechanisms then clients MUST select the
>>>>  PLUS-variant if offered by the server.
>>>>      
>>>>
>>>This make sense.
>>>    
>>>
>>>>Otherwise, if the client does
>>>>  not negotiate mechanisms then it MUST use the non-PLUS variant.
>>>>      
>>>>
>>> This doesn't make much sense. If the client remembers what the
>>> server advertised previously, then it can just use the same
>>> mechanism.
>>> But even if the client never negotiate mechanisms (e.g. if the user
>>> selected the mechanism in UI), then why should it be restricted to
>>> non-PLUS variant?
>>>    
>>>
>>I think that text had been intended to say that the non-PLUS variant
>>must be selected when the client has no idea what the server supports
>>and the client isn't using CB.  But it doesn't really matter.  I'd be
>>happy with removing this text.
>>  
>>
> Alternatively I suggest correcting the text to read something like this:
>
>    Otherwise (the client does not negotiate mechanisms),
>    if the client has no prior knowledge about mechanisms supported
>    by the server and wasn't explicitly configured to use a particular
>    variant of the GS2 mechanism, then it MUST select
>    only non-PLUS version of the GS2 mechanism.

Works fine with me.  I have made this change in my local copy.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 13:42:20 +0200
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

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

Date: Wed, 29 Jul 2009 13:40:39 +0200
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
CC: Simon Josefsson <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Date: Wed, 29 Jul 2009 13:37:00 +0200
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
CC: Simon Josefsson <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Date: Wed, 29 Jul 2009 13:31:51 +0200
From: Peter Saint-Andre <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: Simon Josefsson <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Sender: [email-masked]

Peter

- --
Peter Saint-Andre
https://stpeter.im/

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Chris Newman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 29 Jul 2009 11:19:21 +0200
Sender: [email-masked]

/Simon

Date: Tue, 28 Jul 2009 16:43:38 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Chris Newman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Yes.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Chris Newman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 23:23:20 +0200
Sender: [email-masked]

Right.

/Simon

Date: Tue, 28 Jul 2009 11:14:48 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Chris Newman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Nico
-- 

Date: Tue, 28 Jul 2009 18:30:24 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Works for me as well.

Date: Tue, 28 Jul 2009 11:10:48 -0500
From: Nicolas Williams <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Nico
-- 

Date: Tue, 28 Jul 2009 11:01:11 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

and

Nico
-- 

Date: Tue, 28 Jul 2009 10:57:08 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 16:12:53 +0200
Sender: [email-masked]

Works fine with me.

/Simon

Date: Tue, 28 Jul 2009 09:50:24 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Tom Yu <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 14:30:39 +0200
Sender: [email-masked]

?

/Simon

Date: Tue, 28 Jul 2009 14:11:45 +0200
From: Chris Newman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
To: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Sender: [email-masked]

with:

		- Chris

Date: Tue, 28 Jul 2009 13:09:35 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 12:44:13 +0200
Sender: [email-masked]

/Simon

Date: Tue, 28 Jul 2009 12:27:35 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Removed in my copy.

Date: Tue, 28 Jul 2009 12:21:59 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Simon Josefsson wrote:
 [...]

 [...]

Done.

Date: Tue, 28 Jul 2009 12:15:59 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

 [...]

All removed in my copy.

Date: Tue, 28 Jul 2009 12:09:33 +0200
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Tom Yu <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

>(Yes, this applies to GS2 as well.)

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 11:16:17 +0200
Sender: [email-masked]

/Simon

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 11:13:45 +0200
Sender: [email-masked]

Regarding

   [tls-unique]

/Simon

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 11:05:26 +0200
Sender: [email-masked]

The IANA section says:

/Simon

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 10:08:12 +0200
Sender: [email-masked]

/Simon

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 28 Jul 2009 10:03:29 +0200
Sender: [email-masked]

/Simon

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 27 Jul 2009 22:57:26 +0200
Sender: [email-masked]

Thanks,
Simon

Date: Mon, 27 Jul 2009 10:48:46 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Chris Newman <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 27 Jul 2009 15:43:20 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

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

Thanks for your comments!

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

I'll look at these next.

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

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>

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

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

> 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"?

I agree -- I changed "a" into "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

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

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

Should this be added?  I'm not sure.

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

Fixed.

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

Fixed.

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

Fixed.

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

Fixed.

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

Nico?

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

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

/Simon

Date: Mon, 27 Jul 2009 15:17:20 +0200
From: Chris Newman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
To: [email-masked]
Sender: [email-masked]

Section 3:

		- Chris

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 presentation
From: Tom Yu <[email-masked]>
Date: Mon, 27 Jul 2009 08:45:51 -0400
Lines: 9
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

> All,
>
> I've prepared one slide on GS2 for the meeting.
>
> /Simon

Thanks.  Now uploaded to the meeting materials site.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: GS2 presentation
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 27 Jul 2009 13:03:25 +0200
Sender: [email-masked]

--=-=-=

All,

I've prepared one slide on GS2 for the meeting.

/Simon

--=-=-=
Content-Type: application/pdf
Content-Disposition: attachment; filename=gs2.pdf
Content-Transfer-Encoding: base64

--=-=-=--

Date: Thu, 23 Jul 2009 00:05:18 +0200
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, RFC Errata System <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Jul 22, 2009 at 10:47:54PM +0200, Alexey Melnikov wrote:
>  
>
>>My understanding is that prohibited characters are never generated 
>>during mapping.
>>    
>>
>
>Nonetheless, it's simpler to prohibit their output than it is to
>prohibit them in the input _and_ check that all other mappings and
>transformations cannot produce these codepoints in the output.
>
>And it doesn't hurt to say that we prohibit their output even though in
>practice it's best to think that we prohibit them as input.
>
>At most a sentence, to say just that, would be appropriate ("by
>prohibiting these codepoints in the output we effectively prohibit them
>in the input").
>  
>
That would be fine with me.

Date: Wed, 22 Jul 2009 16:39:27 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, RFC Errata System <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
Sender: [email-masked]

On Wed, Jul 22, 2009 at 10:47:54PM +0200, Alexey Melnikov wrote:
> My understanding is that prohibited characters are never generated 
> during mapping.

Nonetheless, it's simpler to prohibit their output than it is to
prohibit them in the input _and_ check that all other mappings and
transformations cannot produce these codepoints in the output.

And it doesn't hurt to say that we prohibit their output even though in
practice it's best to think that we prohibit them as input.

At most a sentence, to say just that, would be appropriate ("by
prohibiting these codepoints in the output we effectively prohibit them
in the input").

Date: Wed, 22 Jul 2009 22:47:54 +0200
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Simon Josefsson <[email-masked]>, RFC Errata System <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> --On Wednesday, July 22, 2009 08:20:34 PM +0200 Simon Josefsson 
>> RFC Errata System <[email-masked]> writes:
>>
>>> Section: 2.3
>>>
>>> Original Text
>>> -------------
>>> Section title is "Prohibited Output"
>>>
>>> Corrected Text
>>> --------------
>>> Section title should be "Prohibited Input"
>>>
>>> Notes
>>> -----
>>> Section 2.3 is talking about prohibited input, not prohibited output.
>>
>> I'm not sure about this -- compare RFC 3454 section 5, the terminology
>> and design is about prohibiting code points in the _output_.
>>
>> Testing for code points in the _output_ may be semantically different
>> from testing in the _input_.  Some other IDNA operation may modify code
>> points into one of the prohibited _output_ code points.  See RFC 3454
>> section 2, the map&normalize steps are taken before the prohibit step.
>
> I agree with Simon here.  Prohibiting a code point in the output 
> usually has the effect of making any input containing that code point 
> result in a failure, but the point is that the _output_ will never 
> contain that code point, even as the result of mapping and 
> normalization -- the operation will fail instead.  This distinction 
> was a conscious decision made in stringprep.

Agreed.

> There is, however, an error -- the first sentence of this section does 
> in fact claim to be specifying prohibited input characters.  The 
> correct fix is to that text, not to the section title.

My understanding is that prohibited characters are never generated 
during mapping.

Date: Wed, 22 Jul 2009 16:44:34 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, RFC Errata System <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
Sender: [email-masked]

--On Wednesday, July 22, 2009 08:20:34 PM +0200 Simon Josefsson 
<[email-masked]> wrote:

>
> RFC Errata System <[email-masked]> writes:
>
>> Section: 2.3
>>
>> Original Text
>> -------------
>> Section title is "Prohibited Output"
>>
>> Corrected Text
>> --------------
>> Section title should be "Prohibited Input"
>>
>> Notes
>> -----
>> Section 2.3 is talking about prohibited input, not prohibited output.
>
> I'm not sure about this -- compare RFC 3454 section 5, the terminology
> and design is about prohibiting code points in the _output_.
>
> Testing for code points in the _output_ may be semantically different
> from testing in the _input_.  Some other IDNA operation may modify code
> points into one of the prohibited _output_ code points.  See RFC 3454
> section 2, the map&normalize steps are taken before the prohibit step.

I agree with Simon here.  Prohibiting a code point in the output usually 
has the effect of making any input containing that code point result in a 
failure, but the point is that the _output_ will never contain that code 
point, even as the result of mapping and normalization -- the operation 
will fail instead.  This distinction was a conscious decision made in 
stringprep.

There is, however, an error -- the first sentence of this section does in 
fact claim to be specifying prohibited input characters.  The correct fix 
is to that text, not to the section title.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Jul 2009 20:20:34 +0200
Sender: [email-masked]

RFC Errata System <[email-masked]> writes:

> Section: 2.3
>
> Original Text
> -------------
> Section title is "Prohibited Output"
>
> Corrected Text
> --------------
> Section title should be "Prohibited Input"
>
> Notes
> -----
> Section 2.3 is talking about prohibited input, not prohibited output.

I'm not sure about this -- compare RFC 3454 section 5, the terminology
and design is about prohibiting code points in the _output_.

Testing for code points in the _output_ may be semantically different
from testing in the _input_.  Some other IDNA operation may modify code
points into one of the prohibited _output_ code points.  See RFC 3454
section 2, the map&normalize steps are taken before the prohibit step.

/Simon

Date: Sat, 18 Jul 2009 13:12:49 -0700 (PDT)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Editorial Errata Reported] RFC4013 (1812)
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

The following errata report has been submitted for RFC4013,
"SASLprep: Stringprep Profile for User Names and Passwords".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4013&eid=1812

--------------------------------------
Type: Editorial
Reported by: Alexey Melnikov <[email-masked]>

Section: 2.3

Original Text
-------------
Section title is "Prohibited Output"

Corrected Text
--------------
Section title should be "Prohibited Input"

Notes
-----
Section 2.3 is talking about prohibited input, not prohibited output.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4013 (draft-ietf-sasl-saslprep-10)
--------------------------------------
Title               : SASLprep: Stringprep Profile for User Names and Passwords
Publication Date    : February 2005
Author(s)           : K. Zeilenga
Category            : PROPOSED STANDARD
Source              : Simple Authentication and Security Layer
Area                : Security
Stream              : IETF
Verifying Party     : IESG

Date: Sat, 18 Jul 2009 19:39:08 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
Sender: [email-masked]

Tom Yu wrote:

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

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?

To: [email-masked]
Subject: WG Last Call: draft-ietf-sasl-scram-02
From: Tom Yu <[email-masked]>
Date: Mon, 13 Jul 2009 22:17:08 -0400
Lines: 16
Sender: [email-masked]

-- 
Tom Yu
IETF SASL WG co-chair

To: [email-masked]
Subject: WG Last Call: draft-ietf-sasl-gs2-14
From: Tom Yu <[email-masked]>
Date: Mon, 13 Jul 2009 22:17:01 -0400
Lines: 16
Sender: [email-masked]

	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

-- 
Tom Yu
IETF SASL WG co-chair

Date: Wed, 08 Jul 2009 17:31:53 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Jul 08, 2009 at 01:11:57PM +0100, Alexey Melnikov wrote:
>  
>
>>Some quick comments.
>>
>>In Section 3.5:
>>    
>>
>>>  If the client negotiates mechanisms then clients MUST select the
>>>  PLUS-variant if offered by the server.
>>>      
>>>
>>This make sense.
>>    
>>
>>>Otherwise, if the client does
>>>  not negotiate mechanisms then it MUST use the non-PLUS variant.
>>>      
>>>
>>This doesn't make much sense. If the client remembers what the server 
>>advertised previously, then it can just use the same mechanism.
>>But even if the client never negotiate mechanisms (e.g. if the user 
>>selected the mechanism in UI), then why should it be restricted to 
>>non-PLUS variant?
>>    
>>
>I think that text had been intended to say that the non-PLUS variant
>must be selected when the client has no idea what the server supports
>and the client isn't using CB.  But it doesn't really matter.  I'd be
>happy with removing this text.
>  
>
Alternatively I suggest correcting the text to read something like this:

    Otherwise (the client does not negotiate mechanisms),
    if the client has no prior knowledge about mechanisms supported
    by the server and wasn't explicitly configured to use a particular
    variant of the GS2 mechanism, then it MUST select
    only non-PLUS version of the GS2 mechanism.

Date: Wed, 8 Jul 2009 10:50:02 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Sender: [email-masked]

On Wed, Jul 08, 2009 at 12:22:57PM +0100, Alexey Melnikov wrote:
> Nico,
> 
> I believe I've addressed all your comments in my copy.

OK, thanks.  I'll review.

Date: Wed, 8 Jul 2009 10:46:13 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
Sender: [email-masked]

On Wed, Jul 08, 2009 at 01:11:57PM +0100, Alexey Melnikov wrote:
> Some quick comments.
> 
> In Section 3.5:
> 
> >   If the client negotiates mechanisms then clients MUST select the
> >   PLUS-variant if offered by the server.
> 
> This make sense.
> 
> >Otherwise, if the client does
> >   not negotiate mechanisms then it MUST use the non-PLUS variant.
> 
> This doesn't make much sense. If the client remembers what the server 
> advertised previously, then it can just use the same mechanism.
> But even if the client never negotiate mechanisms (e.g. if the user 
> selected the mechanism in UI), then why should it be restricted to 
> non-PLUS variant?

I think that text had been intended to say that the non-PLUS variant
must be selected when the client has no idea what the server supports
and the client isn't using CB.  But it doesn't really matter.  I'd be
happy with removing this text.

> In Section 5.1:
> 
> >   The application-data field MUST be set to the gs2-header concatenated
> >   with, when a gs2-cb-flag of "p" is used, the application's channel
> >   binding data (if any).
> 
> I think "(if any)" should be removed, because for "p" the channel 
> binding data is always present. I assume that a channel binding data 
> can't be the empty string.

Sure.

Date: Wed, 08 Jul 2009 15:03:12 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-scram-02.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.
>
>
This version bringins SCRAM inline with the latest GS2 (-14). It also 
addresses editorial comments from Nico.
This should be ready for WGLC.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-scram-02.txt 
Date: Wed,  8 Jul 2009 07:00:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS.  Unfortunately, the
challenge response mechanisms presently on the standards track all
fail to meet requirements necessary for widespread deployment, and
have had success only in limited use.

This specification describes a family of Simple Authentication and
Security Layer (SASL, RFC 4422) authentication mechanisms called the
Salted Challenge Response Authentication Mechanism (SCRAM), which
addresses the security concerns and meets the deployability
requirements.  When used in combination with TLS or an equivalent
security layer, a mechanism from this family could improve the
status-quo for application protocol authentication and provide a
suitable choice for a mandatory-to-implement mechanism for future
application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-scram-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Date: Wed, 08 Jul 2009 13:11:57 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.
>
>
>	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
>  
>
Some quick comments.

In Section 3.5:

>    If the client negotiates mechanisms then clients MUST select the
>    PLUS-variant if offered by the server.

This make sense.

> Otherwise, if the client does
>    not negotiate mechanisms then it MUST use the non-PLUS variant.

This doesn't make much sense. If the client remembers what the server 
advertised previously, then it can just use the same mechanism.
But even if the client never negotiate mechanisms (e.g. if the user 
selected the mechanism in UI), then why should it be restricted to 
non-PLUS variant?

In Section 5.1:

>    The application-data field MUST be set to the gs2-header concatenated
>    with, when a gs2-cb-flag of "p" is used, the application's channel
>    binding data (if any).

I think "(if any)" should be removed, because for "p" the channel 
binding data is always present. I assume that a channel binding data 
can't be the empty string.

Date: Wed, 08 Jul 2009 12:22:57 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Sender: [email-masked]

Nicolas Williams wrote:
 [...]

>My only comments are editorial, otherwise I'm happy with this
>Internet-Draft:
>
> - Clarify this sentence:
>
>  "This means that SCRAM is actually both, a GSS-API and SASL mechanism."
>
>   as follows:
>
>  "This means that this document defines both, a GSS-API mechanism and a
>   SASL mechanism."
>
>   Rationale: one must remove the GS2 header from the initial context
>   token and then add the RFC2743 initial context token header in order
>   to get SCRAM as a GSS-API mechanism, therefore the original text
>   above might be confusing to some readers.  See section 8.
>
> - Section 4, there's a typo: (20-length("SCRAM-")-lenght("-PLUS")
>   (the second 'length' is misspelled).
>
> - Section 5, "SCRAM is a text protocol where...".  Really?  I thought
>   SCRAM was a mechanism, not a protocol...  How about:
>
>   "SCRAM is a SASL mechanism whose authentication messages are
>   text-based messages containing one or more attribute-value pairs
>   separated by commas."
>
>   (That these messages are exchanged by a client and server seems
>   superfluous once one describes SCRAM as a SASL mechanism.)
>
> - Section 6:
>
>"
>   o  If the client negotiates mechanisms then client MUST select SCRAM-
>      <hash-function>-PLUS if offered by the server.  Otherwise, if the
>      client does not negotiate mechanisms then it MUST select only
>      SCRAM-<hash-function> (not suffixed with "-PLUS").
>"
>
>   s/then client/then the client/
>
>   s/MUST select SCRAM-<hash-function>-PLUS if offered by the server/
>     MUST select SCRAM-<hash-function>-PLUS if offered by the server and
>     the client wants to select SCRAM with the given hash function/
>
> - Section 6:
>
>   o  If the client supports channel binding but the server does not
>      then the client MUST ...
>
>   s/the server does not/the server does not (i.e., did not offer
>     SCRAM-<hash-function>-PLUS) then the client MUST .../
>  
>
Nico,
I believe I've addressed all your comments in my copy.

To: [email-masked]
Subject: summary of SCRAM TLS channel binding discussion
From: Tom Yu <[email-masked]>
Date: Mon, 06 Jul 2009 23:22:17 -0400
Lines: 83
Sender: [email-masked]

Having reviewed a large quantity of mailing list traffic, I will
attempt to summarize the outcome of this discussion (which spans more
than one hundred messages).  Please let me know if I appear to have
misrepresented anything.  I intend to restart the WG Last Call on
SCRAM (and start one on GS2) this week unless the authors feel that
the current versions are not ready.

There appears to be consensus around option 1a (using Alexey's
labeling): SCRAM will use a single allowed TLS channel binding type,
which is tls-unique, deferring the ability of negotiating channel
binding types.

In addition, some participants, including Nico Williams, Simon
Josefsson, Sam Hartman, and Jeff Hutzelman, worked to come up with a
compromise proposal for GS2 and SCRAM for providing a method for a
client to declare to a server what channel binding it is using, while
not committing to any specific negotiation method for channel binding
types.  There appears to be rough consensus around this proposal.

I will note that there appears to be consensus that SCRAM (and GS2)
should move forward as quickly as reasonably possible.  While there
may continue to be disagreement about the form that the negotiation
method for channel binding types will take, there appears to be rough
consensus that the current proposal for a client to declare a channel
binding does not preclude the existence of some future method for
negotiating channel binding types.  Additionally, there appears to be
consensus to defer any decision about the details of negotiating
channel binding types so that SCRAM may proceed without additional
hindrance.

As a means of realizing the working group consensus that SCRAM proceed
as quickly as reasonably possible, I strongly recommend that until we
conclude our work on the SCRAM document, any future debate about
methods of negotiating channel binding types concentrate on whether
there are specific and concrete reasons, grounded in plausible
implementation or deployment concerns, why the compromise proposal is
harmful.

                         ====================

The original poll as posted by Alexey:

    1). SCRAM should just use a single allowed TLS channel binding and
    don't have any negotiation of other TLS channel bindings (*) (**)
    a). the default is tls-unique
    b). the default is tls-server-end-point
    2). SCRAM should just use tls-server-end-point, fallback to
    tls-unique, no negotiation of other TLS channel bindings (*)
    3). SCRAM should always use channel binding negotiation (*)
    4). SCRAM should have a default TLS channel binding with optional
    negotiation of TLS channel bindings (*)
    a). the default is tls-unique
    b). the default is
    5). I have another opinion [this is for the case when there is some
    valid choice which you think should be considered by the WG]

    Notes:
    (*) - whether such negotiation happens inside or outside of SCRAM
    (**) - channel binding negotiation can be added later on

I have assumed, as have some participants, that the missing phrase in
option 4b is "tls-server-end-point".  The following text is a very
rough and incomplete summary of some individual opinions.

Jeff Hutzelman and others strongly oppose any technique that involves
registrations of N * M composed mechanism and channel binding type
names.

Simon preferred explicit registration of specific combinations,
believing that the subset of N * M with desirable security properties
is limited.

Kurt wants to ensure that any changes to GS2 or SCRAM in the area of
channel bindings do not unreasonably constrain the design of any
future SASL mechanism.  He particularly wants to avoid strategies that
could preclude purely in-mechanism channel binding type negotiation,
or make them difficult to specify or implement.  Kurt appears to
prefer a means of negotiating channel binding type by including the
name of the channel binding type in the mechanism name.

-- 
Tom Yu
IETF SASL WG co-chair