Subject: I-D Action:draft-ietf-sasl-scram-01.txt

From: [email-masked]
Date: Tue, 26 May 2009 13:00:01 -0700 (PDT)

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-01.txt
	Pages           : 33
	Date            : 2009-05-26

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 26 May 2009 21:59:32 +0100

>	Filename        : draft-ietf-sasl-scram-01.txt
This version clearly states that hashes are fake. I believe channel 
binding data to be correct now.

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 27 May 2009 11:40:16 -0700

> 	Filename        : draft-ietf-sasl-scram-01.txt

The purpose of this WG Last Call is to ensure that the Working Group  
has achieved consensus that the document is suitable for publication  
on the Standards Track.
Please review the document for both technical and editorial problems.  
Technical issues should be discussed on this list. Editorial issues  
may be sent to the document editor.
The Last Call period will close on Friday, 12 June 2008.
Upon completion of the last call, the WG chair(s) will take action  
based upon the consensus of the WG. Possible actions include:
1) recommending to the IETF Applications Area Directors that the  
document, after possible editorial or other minor changes, be  
considered by the IESG for publication as a Standard Track RFC (which  
generally involves an IETF-wide Last Call); or
2) requiring that outstanding issues be adequately addressed prior to  
further action (including, possibly, another WG Last Call).
Remember that it is our responsibility as Working Group members to  
ensure the quality of our documents and of the Internet Standards  
process.  So, please read and comment!
Kurt Zeilenga, SASL WG co-chair

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 May 2009 19:48:51 +0100

> has achieved consensus that the document is suitable for publication  

Thanks!

> 1) recommending to the IETF Applications Area Directors

We like that :-).

> that the  document, after possible editorial or other minor changes, 
> be  considered by the IESG for publication as a Standard Track RFC 
> (which  generally involves an IETF-wide Last Call); or

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 27 May 2009 11:58:58 -0700

On May 27, 2009, at 11:48 AM, Alexey Melnikov wrote:

>> The purpose of this WG Last Call is to ensure that the Working  
>> Group  has achieved consensus that the document is suitable for  
>> publication  on the Standards Track.
>
> Thanks!
>
>> Please review the document for both technical and editorial  
>> problems.  Technical issues should be discussed on this list.  
>> Editorial issues  may be sent to the document editor.

s/Applications/Security/  (missed an edit after cut-n-pasting from a  
prior (LDAPBIS) WGLC message)

>
>
>> that the  document, after possible editorial or other minor  
>> changes, be  considered by the IESG for publication as a Standard  
>> Track RFC (which  generally involves an IETF-wide Last Call); or
>> 2) requiring that outstanding issues be adequately addressed prior  
>> to  further action (including, possibly, another WG Last Call).

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 28 May 2009 08:41:32 -0700

The I-D needs normative references to the 'tls-server-end-point' and  
'tls-unique' channel binding type technical specifications.

OLD:
    If an external TLS channel is to be bound into the authentication,
    and if the channel supports channel bindings of type
    'tls-server-end-point', then those MUST be used, else if the
    channel supports channel bindings of type 'tls-unique' type,
    then those MUST be used.

NEW:
    If an external TLS channel is to be bound into the authentication,
    and if the channel supports channel bindings of type
    'tls-server-end-point' [CBT-TLS-EP], then those MUST be used, else  
if the
    channel supports channel bindings of type 'tls-unique' [CBT-TLS-U],
    then those MUST be used.

and add to both sets of normative references:

    [CBT-TLS-EP] Larry Zhu, "Registration of TLS server end-point  
channel bindings",
      http://www.iana.org/assignments/channel-binding-types/tls-server-end-point 
,
      June 26, 2008.

    [CBT-TLS-U] Larry Zhu, "Registration of TLS unique channel  
bindings (generic)",
      http://www.iana.org/assignments/channel-binding-types/tls-unique,
      June 26, 2008.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 May 2009 13:31:45 -0400

--On Thursday, May 28, 2009 08:41:32 AM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

>     'tls-server-end-point' [CBT-TLS-EP], then those MUST be used, else if
> the
>     [CBT-TLS-EP] Larry Zhu, "Registration of TLS server end-point channel
> bindings",
>
> http://www.iana.org/assignments/channel-binding-types/tls-server-end-poin
> t,
>       June 26, 2008.
>
>     [CBT-TLS-U] Larry Zhu, "Registration of TLS unique channel bindings
> (generic)",

Oh, ugh; those really should have been done as RFC's so we could have 
proper references.  In any case, let's not worry about it too much just 
yet, since this will likely be changing anyway.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 28 May 2009 14:08:58 -0500

> yet, since this will likely be changing anyway.

Several I-Ds that I've edited recently have such references.  I asked on
the xml2rfc list just what would be the best way to make normative
references to IANA registry entries.  This is the stanza I use:

            <reference anchor='tls-server-end-point'>
                <front>
                    <title>Registration of TLS server end-point channel
                        bindings</title>
                    <author initials='L.' surname='Zhu' fullname='Larry Zhu'>
                        <organization abbrev='MSFT'>Microsoft</organization>
                    </author>
                    <date month='July' year='2008'/>
                </front>
                <format type='TXT'
                    target='http://www.iana.org/assignments/channel-binding-types/tls-server-end-point'/>
            </reference>
            <reference anchor='tls-unique'>
                <front>
                    <title>Registration of TLS unique channel binding
                        (generic)</title>
                    <author initials='L.' surname='Zhu' fullname='Larry Zhu'>
                        <organization abbrev='MSFT'>Microsoft</organization>
                    </author>
                    <date month='July' year='2008'/>
                </front>
                <format type='TXT'
                    target='http://www.iana.org/assignments/channel-binding-types/tls-unique'/>
            </reference>

But I agree, the moment I had to go ask I felt sorry we'd not sought to
publish these as RFCs instead of just expert-reviewed IANA
reigstrations.

Simon has submitted an I-D for the purpose of publishing these as RFCs:
draft-josefsson-sasl-tls-cb-01 (which I've not yet reviewed).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 May 2009 22:39:00 +0200

> draft-josefsson-sasl-tls-cb-01 (which I've not yet reviewed).

The goal with that document was to offer another channel binding
construct, based on the TLS PRF.  My document does not describe
Microsoft's channel binding types, which are based on the TLS Finished
message.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 28 May 2009 15:38:20 -0500

> Microsoft's channel binding types, which are based on the TLS Finished

We don't need alternatives.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 28 May 2009 16:46:09 -0500

> >	Filename        : draft-ietf-sasl-scram-01.txt

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 28 May 2009 19:49:45 -0700

> We don't need alternatives.

But aren't alternatives just something we have to live with given the  
RFC 5056 IANA Considerations?

I think we need to be careful of specifications that assume that there  
will be one and only one unique channel binding type or one and only  
one server, client, or dual end-point channel binding type for a  
particular kind of channel.  We already have two unique bindings for  
TLS registered (though one claims to be specific to TELNET, nothing  
seems to precludes it use outside of TELNET), and then Simon's.  And  
you have noted the one could define TLS server end-point channel  
binding types that only identified the server's name.

-- Kurt

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 28 May 2009 22:08:26 -0500

> RFC 5056 IANA Considerations?

Just because they are possible doesn't mean that we need them.

Before we consider any alternative to three registered TLS channel
binding types I'd like to know why we couldn't use those.

Nico
--