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

From: [email-masked]
Date: Sat, 23 May 2009 07:15: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-00.txt
	Pages           : 33
	Date            : 2009-05-23

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-00.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: Sat, 23 May 2009 15:35:08 +0100

>	Filename        : draft-ietf-sasl-scram-00.txt
This version is essentially the same as draft-newman-auth-scram-13.txt.

I believe it addresses all outstanding issues the WG could agree on, so 
I would like to request WGLC for the document.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 25 May 2009 14:14:16 +0200

> This version is essentially the same as draft-newman-auth-scram-13.txt.

Great!

> I believe it addresses all outstanding issues the WG could agree on,
> so I would like to request WGLC for the document.

Since the SCRAM protocol wire syntax needs to match the GS2 wire syntax
for them to be compatible, I think it would be useful to do WGLC of both
SCRAM and GS2 at the same time.

As far as I recall there are only minor issues with GS2 left, including:

* Is additional language on locale issues required?

* Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
  length string to indicate asserted absence of a registered IANA name?
  See section 3.

Anyway, a WGLC on GS2 will provoke a more complete summary of open
issues, which seems like a good idea at this point.  Chairs?

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 May 2009 13:39:44 +0100

>SCRAM and GS2 at the same time.
Agreed. Or at least send them to IETF LC/IESG at the same time.

>* Is additional language on locale issues required?
I think some text in at least section on C-binding is needed.
Note, that Chris Newman has specified explicit language tag parameter in 
SASL API. IMHO, you don't have to do the same, but you need to know why 
you want to differ.

>  length string to indicate asserted absence of a registered IANA name?
I don't think this is useful. We should reduce the number of branches 
needed to handle a call to this function.

>issues, which seems like a good idea at this point.  Chairs?
Indeed.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 25 May 2009 15:15:19 +0200

> Agreed. Or at least send them to IETF LC/IESG at the same time.

Yup.

> Note, that Chris Newman has specified explicit language tag parameter
> in SASL API. IMHO, you don't have to do the same, but you need to know
> why you want to differ.

Nico?

What do you mean by SASL API?  I think SASL and the GSS-API are
different creatures, one is a wire protocol and the other is a
programming API.

I added these functions to the document, but I don't care strongly about
the feature, so I hope Nico's answer will resolve it.  We could remove
those fields, as they are not needed for GS2.  Or even remove the
functions from the document too: it is possible to implement GS2 against
a GSS-API stack that doesn't have these APIs.

Robust GS2 implementations will probably have to deal with GSS-API
stacks that doesn't have the functions anyway.

> needed to handle a call to this function.

How would you then differentiate the situation where the call fails for
some random reason, or where it fails because there is no registered
IANA name for a particular GSS-API mechanism?

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 May 2009 18:17:59 +0100

Simon Josefsson wrote:

>What do you mean by SASL API?
>
The API used by Cyrus SASL. Chris designed the original version.

One example of the function using language tags is:

/* translate an error number into a string
 * input:
 *  saslerr  -- the error number
 *  langlist -- comma separated list of RFC 1766 languages (may be NULL)
 * results:
 *  outlang  -- the language actually used (may be NULL if don't care)
 * returns:
 *  the error message in UTF-8 (only the US-ASCII subset if langlist is 
NULL)
 */
LIBSASL_API const char *sasl_errstring(int saslerr,
                       const char *langlist,
                       const char **outlang);

>I think SASL and the GSS-API are
>some random reason,
I have hard time imagining such case, but ...

>or where it fails because there is no registered
... can you just use a different error code?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 May 2009 13:28:25 -0500

> > in SASL API. IMHO, you don't have to do the same, but you need to know

The GSS-API does not (yet) expose to apps any such language tag
negotiations that the mechanism might do, and if it ever does it will be
optional, that is, only if the mechanism itself supports it.

Therefore we certainly don't need language tag negotiation in the GS2
headers.

Mechanisms only need to negotiation language tags if there's going to be
human-readable error messages in GSS-API error tokens.  In practice
there's a finite number of errors that can occur in this context (as
opposed to more complex contexts, such as client<->KDC/kadmin
exchanges), so there's no need for localization in GSS-API mechanisms.

However, there is a local localization issue.  If an API can return a
human readable description of a mechanism, say, then that needs to be
localized.  That's an entirely local issue -- no language tag
negotiation is needed!  (I thought we'd settled this already.)

> different creatures, one is a wire protocol and the other is a

I think of them as much the same sort of thing:

 - a protocol _pattern_ (SASL specifies NO bits on the wire, and the
   GSS-API specifies just a very few bits on the initial context token)

 - an abstract API (SASL certainly has one, though it's very subtly
   specified)

 - programming language bindings of that abstract API (only the GSS-API
   has standard bindings)

> a GSS-API stack that doesn't have these APIs.

Which functions?  GSS_Inquire_SASLname_for_mech()?  Please keep the
localized mechanism description output argument (see above); I strongly
object to its removal.

> >>  length string to indicate asserted absence of a registered IANA name?

It should compute and return the GS2 OID hash name.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 May 2009 13:51:06 -0500

> SCRAM and GS2 at the same time.

I agree.

> * Is additional language on locale issues required?

We definitely resolved that.  The localization issue in the
GSS_Inquire_SASLname_for_mech() API is purely local, therefore there's
no need to say anything about language tag negotiation.

>   length string to indicate asserted absence of a registered IANA name?

No, it should generate an OID hash-based name, per-GS2.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 May 2009 22:16:53 +0100

>No, it should generate an OID hash-based name, per-GS2.
This is fine with me.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 May 2009 16:12:14 +0200

> no need to say anything about language tag negotiation.

OK.

> No, it should generate an OID hash-based name, per-GS2.

Ah.  I agree.  I believe this isn't clear in -12, though.  I'll submit
an update that fixes this, and references the new SCRAM document too.

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 26 May 2009 09:26:33 -0700

> so I would like to request WGLC for the document.

I've asked Alexey to revise the I-D slightly before it's WGLC'ed.

The current I-D says that providing proper examples is an open  
issue.   As Alexey does not have the cycles at present to actually  
proper examples (e.g, w/ correct hash values), he's going to close  
this issue by adding notes to the text that the hash values are garbage.

While I personally rather correct the hash values (a comment I'll  
raise at WGLC), I am willing as co-chair to issue a WG LC so long as  
it quite clear that the hash values are garbage.

I hope someone can make moot this issue by computing correct hash  
values.

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 May 2009 18:37:33 +0200

Kurt Zeilenga <[email-masked]> writes:

> The current I-D says that providing proper examples is an open issue.
> As Alexey does not have the cycles at present to actually  proper
> examples (e.g, w/ correct hash values), he's going to close  this
> issue by adding notes to the text that the hash values are garbage.
>

I volunteer to propose examples.  I have been waiting for the WGLC to
start before looking into implementation.

Is anyone interested in interop testing?

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 12:17:55 -0500

> I hope someone can make moot this issue by computing correct hash  

Using a packet capture tool (wireshark) I extracted the first
certificate in an HTTPS connection to https://mail.google.com, I
inspected the signature algorithm (sha1WithRSAEncryption, that is,
1.2.840.113549.1.1.5), selected a hash function according to the
tls-server-end-point specification (SHA-256), and computed the hash of
that certificate as it appeared on the wire[*]:

cb5845b573a767ec92ad033ab2b16997fefbbaabedc6b83b9c163505eb44aff8

The certificate in question has serial #6EDF0D9499FD4533DD1297FC42A93BE1
and was issued by 'Thawte SGC CA'.  The issuer's signature of that cert
is:

      0000 - 00 62 f1 f3 05 0e bc 10-5e 49 7c 7a ed f8 7e 24   .b......^I|z..~$
      0010 - d2 f4 a9 86 bb 3b 83 7b-d1 9b 91 eb ca d9 8b 06   .....;.{........
      0020 - 59 92 f6 bd 2b 49 b7 d6-d3 cb 2e 42 7a 99 d6 06   Y...+I.....Bz...
      0030 - c7 b1 d4 63 52 52 7f ac-39 e6 a8 b6 72 6d e5 bf   ...cRR..9...rm..
      0040 - 70 21 2a 52 cb a0 76 34-a5 e3 32 01 1b d1 86 8e   p!*R..v4..2.....
      0050 - 78 eb 5e 3c 93 cf 03 07-22 76 78 6f 20 74 94 fe   x.^<...."vxo t..
      0060 - aa 0e d9 d5 3b 21 10 a7-65 71 f9 02 09 cd ae 88   ....;!..eq......
      0070 - 43 85 c8 82 58 70 30 ee-15 f3 3d 76 1e 2e 45 a6   C...Xp0...=v..E.
      0080 - bc                                                .

[*] Running openssl asn1parse -inform DER -in path_to_cert -dump fully
    decodes the captured certificate -- no errors nor warnings resulted.

Nico
--