Subject: "Last call" on draft-altman-tls-channel-bindings-05.txt

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Aug 2009 16:34:28 -0500

Per RFC5056, three channel binding types for TLS have been registered in
the IANA channel binding type registry.  Recently we've decided that we
actually need a Standards-Track RFC to define these channel binding
types so as to make it easier to make normative reference to them.

Therefore we've revived and updated draft-altman-tls-channel-bindings to
include the text of those three channel binding type registrations, as
well as to update introductory and security considerations text.

We seek comments on draft-altman-tls-channel-bindings-05.  In two weeks
we'll request that an AD shepherd this individual submission.  We seek
Proposed Standard status for the resulting RFC.

Consider this a pseudo-WGLC.  Please review and comment.

Thanks,

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Aug 2009 00:45:17 +0200

Quoting:

   Description: The hash of the TLS server's end entity certificate
   [RFC5280] as it appears, octet for octet, in the server's Certificate
   message (note that the Certificate message contains a
   certificate_list, the first element of which is the server's end
   entity certificate.)

I suggest replacing "server's end entity certificate" with "server's
certificate".  As far as I understand, it is possibly to use non-EE
certs, e.g. proxy certs, as a server certificate.  The RFC 5246
terminology is to say "sender's certificate" and there is no requirement
to use a EE cert.

Quoting:

   agility.  The algorithm to be used, however, is derived from the
   certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
   else use whatever hash function the certificate uses.  This

Please say "is signed with" instead of "uses".  Hash values may be
present for other purposes in a certificate, but signature fields will
typically only use one hash function.

For completeness, I would add:

   This algorithm agility resolution mechanism assumes that there is a
   mapping from every Public-key signature algorithm to one hash
   function algorithm.  This is the case for all practically used public
   key signature algorithms today, but if future public-key signature
   algorithms would employ multiple hash functions (or none at all) this
   specification needs to be updated to resolve which hash function
   should be used.

Nits:

   note (that is, the first such note in the descritption is a new
                                                   ^
/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Aug 2009 17:59:34 -0500

> terminology is to say "sender's certificate" and there is no requirement

OK.  The thing to emphasize is that we're talking about the first cert
in the certificate_list that would be sent by the server.

(I say "would be" just to be mindful of the TLS client caching
extensions, but I don't think the I-D has to say "would" since the
certificate_list will always have been sent at one point or another.)

So how about:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)  The hash function ...

> typically only use one hash function.

The text you quote is security considerations text; the normative text
already says exactly what you ask for.  But OK:

        ...  The algorithm to be used, however, is derived from the
   certificate's signature as described in Section 4.1; to recap: use
   SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
   else use whatever hash function the certificate uses.

Now, section 4.1 says "if the certificate's signature hash algorithm is
...".  But perhaps it should say "if the hash algorithm used in the
certificate's signatureAlgorithm is ...", just to be really accurate and
avoid any possible confusion (with, say, the algorithm field of
SubjectPublicKeyInfo).  Yes?

>    specification needs to be updated to resolve which hash function

Good point.

Thanks!

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Aug 2009 02:14:38 +0200

>    element of which is the server's certificate.)  The hash function ...

Looks fine to me.

>    else use whatever hash function the certificate uses.

There were two uses of "uses" in the sentence, and the second is still
present, but at least this is better than before.

> SubjectPublicKeyInfo).  Yes?

The more precise the better, although SubjectPublicKeyInfo generally do
not imply any particular hash function.  But for new implementers, it is
easy to go wrong if the text is not specific.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 11:17:28 -0500

On Wed, Aug 19, 2009 at 02:14:38AM +0200, Simon Josefsson wrote:
> >    Description: ...

Ah yes:

        ...  The algorithm to be used, however, is derived from the
   certificate's signature as described in Section 4.1; to recap: use
   SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
   else use whatever hash function the certificate signature algorithm
   uses.

> easy to go wrong if the text is not specific.

So let's add that precision and address signature algs that don't use
hash functions:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)  The hash function is
   to be selected as follows: if the hash algorithm used in the
   certificate's signatureAlgorithm is either MD5 [RFC1321] or SHA-1
   [RFC3174] or if the certificate's signatureAlgorithm does not use any
   hash functions, then use SHA-256 [FIPS-180-2], otherwise use whatever
   hash algorithm is used by the certificate's signatureAlgorithm.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 16:22:24 -0500

>    specification needs to be updated to resolve which hash function

This brings up a question: what to do in the case of randomized digital
signatures?  In the case of NIST-SP-800-106 there's still a hash
function, so that's OK.  But one can imagine a digital signature
algorithm where a MAC and random key are used instead of a hash.

Traditionally a digital signature

	S'(Kp, M) = S(Kp, H(M))

while in NIST-SP-800-106

	S'(Kp, M) = {rv = rng(rv_len),
		     S(Kp, H(rv ||
			     (pad(M, rv_len) XOR xor_pad_gen(rv) ||
			     rv_length_indicator(rv_len))))
		    }

One could imagine this, however:

	S'(Kp, M) = {mk = rng(),
		     S(Kp, MAC(k, M))}

in which case there'd be no hash function.  Of course, we could define a
pseudo-hash function in that case: H(x) = MAC(mk, x), where mk is the mk
that would appear in the signature.

But I don't want to guess at what might happen in the future
of digital signatures.  Instead I'd rather either say either
that tls-server-end-point CB is undefined if the cert's
signature alg does not use a signature, or pick a hash
function (e.g., SHA-512) to use in such cases.

Comments?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Aug 2009 00:25:38 +0200

Nicolas Williams <[email-masked]> writes:

> of digital signatures.

I agree, we could decide to not resolve this concern.

> Instead I'd rather either say either that tls-server-end-point CB is
> undefined if the cert's signature alg does not use a signature, or
> pick a hash function (e.g., SHA-512) to use in such cases.

If use of SHA-512 is hard-coded, we run into problem when it is phased
out.  Negotiation any other hash function will be tricky.  Alas, I'm not
sure leaving it undefined is any better: negotiating what hash function
to use in that situation seems equally tricky.

This is one reason where deriving channel binding data from the TLS
channel using tls-extractor appears more robust: it leaves negotiation
of the hash function to the TLS protocol.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 17:22:29 -0500

On Wed, Aug 19, 2009 at 04:22:24PM -0500, Nicolas Williams wrote:
> ...

After asking others I propose the former solution:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)

   The hash function is to be selected as follows:

    - if the certificate's signatureAlgorithm uses a single hash
      function, and that hash function is either MD5 [RFC1321] or SHA-1
      [RFC3174] then use SHA-256 [FIPS-180-2];

    - if the certificate's signatureAlgorithm uses a single hash
      function and that hash function neither MD5 nor SHA-1, then use
      the hash function associated with the certificate's
      signatureAlgorithm;

    - if the certificate's signatureAlgorithm uses no hash functions, or
      multiple hash functions, then this channel binding type's channel
      bindings are undefined at this time (updates to is channel binding
      type may occur to address this issue if it ever arises).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 17:26:58 -0500

> to use in that situation seems equally tricky.

I chatted with Jeff Hutzelman about this, and we both concluded that
leaving tls-server-end-point undefined in this case is acceptable
because we could change the spec to define tls-server-end-point for such
signature algorithms when they arise.

> of the hash function to the TLS protocol.

tls-unique does that already (though not using the extractor).  We're
talking about end-point channel binding types here, which are
independent of actual channels, therefore we couldn't use the extractor.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Aug 2009 10:07:20 -0400

>       type may occur to address this issue if it ever arises).

+1

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Aug 2009 10:20:59 -0600

> types so as to make it easier to make normative reference to them.

Thanks, this is helpful.

> Proposed Standard status for the resulting RFC.

The TLS list seems more appropriate than [email-masked] as the location
for expert review.

Nit: cryptographycally => cryptographically

Peter

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Aug 2009 12:49:16 -0500

> The TLS list seems more appropriate than [email-masked] as the location
                   ^ of changes to these channel binding types.

Good point.  I'll make the change.  (But perhaps the TLS WG doesn't
agree?  If so, pipe up!)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 31 Aug 2009 14:56:52 -0500

I've just posted version -06, incorporating all changes agreed so far.

This pseudo-WGLC started on August 18th.  Tomorrow I'll ask Pasi to take
the next step in the publication process.

Thanks,

Nico
-- 

Date: Wed, 19 Aug 2009 17:26:58 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
Sender: [email-masked]

Nico
-- 

Date: Wed, 19 Aug 2009 17:22:29 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
Sender: [email-masked]

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 20 Aug 2009 00:25:38 +0200
Sender: [email-masked]

/Simon

Date: Wed, 19 Aug 2009 16:22:24 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
Sender: [email-masked]

	S'(Kp, M) = S(Kp, H(M))

while in NIST-SP-800-106

	S'(Kp, M) = {mk = rng(),
		     S(Kp, MAC(k, M))}

Comments?

Nico
-- 

Date: Wed, 19 Aug 2009 11:17:28 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
Sender: [email-masked]

Ah yes:

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 19 Aug 2009 02:14:38 +0200
Sender: [email-masked]

Looks fine to me.

/Simon

Date: Tue, 18 Aug 2009 17:59:34 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
Sender: [email-masked]

So how about:

Good point.

Thanks!

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 19 Aug 2009 00:45:17 +0200
Sender: [email-masked]

Quoting:

Quoting:

Nits:

Date: Tue, 18 Aug 2009 16:34:28 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked], [email-masked]
Subject: "Last call" on draft-altman-tls-channel-bindings-05.txt
Sender: [email-masked]

Thanks,

Nico
-- 

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 17 Aug 2009 13:24:11 +0200
Subject: RE: [Editorial Errata Reported] RFC4013 (1812)
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Hmm.. it looks like there are Unicode characters that are in the
"prohibited output" list, but will get changed to another, allowed
characters during the "Map" or "Normalize" steps.=20

Since "Prohibit" step is done after Map and Normalize, these
characters can actually appear in the input, right? (and this would=20
not be an error)

(For example, it looks like U+0340 is prohibited by Table C.8, but
will get normalized to U+0300, which is allowed.)

So actually should the errata be something like this?

  OLD:
     This profile specifies the following characters as prohibited input:  =
  =20
  NEW:
     This profile specifies the following characters as prohibited output:

 Discussion: Per RFC 3454, the check for prohibited characters
 is done after the "Map" and "Normalize" steps. Characters listed
 here are actually allowed as inputs if they get removed by the=20
 "Map" or "Normalize" steps.

Best regards,
Pasi

> -----Original Message-----
> From: ext Kurt Zeilenga [mailto:[email-masked]]
> Sent: 23 July, 2009 04:32
> To: Jeffrey Hutzelman
> Cc: Simon Josefsson; RFC Errata System; [email-masked]; Eronen Pasi
> (Nokia-NRC/Helsinki); [email-masked]; [email-masked]; ietf-
> [email-masked]
> Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
>=20
>=20
> On Jul 22, 2009, at 1:44 PM, Jeffrey Hutzelman wrote:
>=20
> > 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.
>=20
>=20
> I support the following errata:
>=20
> OLD:
> 	prohibited input:
>=20
> NEW
> 	prohibited:
>=20
>=20
> Discussion:
> Per RFC 3454, if a prohibited character appears in the input, an error
> must result.  That is, the prohibited characters cannot appear in the
> output.

From: Simon Josefsson <[email-masked]>
To: <[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: Mon, 17 Aug 2009 14:50:45 +0200
Sender: [email-masked]

I think your fix is better.  RFC 3454 talks about prohibiting code
points in the output.  It doesn't say anything about prohibiting code
points in inputs, since the algorithm doesn't work like that.  I don't
think the intention of RFC 4013 was to change the ordering of RFC 3454
algorithm steps, so treating it as a typo in RFC 4013 appears
appropriate to me.

/Simon

<[email-masked]> writes:

> Hmm.. it looks like there are Unicode characters that are in the
> "prohibited output" list, but will get changed to another, allowed
> characters during the "Map" or "Normalize" steps. 
>
> Since "Prohibit" step is done after Map and Normalize, these
> characters can actually appear in the input, right? (and this would 
> not be an error)
>
> (For example, it looks like U+0340 is prohibited by Table C.8, but
> will get normalized to U+0300, which is allowed.)
>
> So actually should the errata be something like this?
>
>   OLD:
>      This profile specifies the following characters as prohibited input:     
>   NEW:
>      This profile specifies the following characters as prohibited output:
>
>  Discussion: Per RFC 3454, the check for prohibited characters
>  is done after the "Map" and "Normalize" steps. Characters listed
>  here are actually allowed as inputs if they get removed by the 
>  "Map" or "Normalize" steps.
>
> Best regards,
> Pasi
>
>> -----Original Message-----
>> From: ext Kurt Zeilenga [mailto:[email-masked]]
>> Sent: 23 July, 2009 04:32
>> To: Jeffrey Hutzelman
>> Cc: Simon Josefsson; RFC Errata System; [email-masked]; Eronen Pasi
>> (Nokia-NRC/Helsinki); [email-masked]; [email-masked]; ietf-
>> [email-masked]
>> Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
>> 
>> 
>> On Jul 22, 2009, at 1:44 PM, Jeffrey Hutzelman wrote:
>> 
>> > 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.
>> 
>> 
>> I support the following errata:
>> 
>> OLD:
>> 	prohibited input:
>> 
>> NEW
>> 	prohibited:
>> 
>> 
>> Discussion:
>> Per RFC 3454, if a prohibited character appears in the input, an error
>> must result.  That is, the prohibited characters cannot appear in the
>> output.

Date: Wed, 12 Aug 2009 15:08:11 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Peter Saint-Andre <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Sender: [email-masked]

Dave Cridland wrote:

> On Mon Aug 10 21:01:13 2009, Peter Saint-Andre wrote:
>
>> Instead of requiring the application of SASLprep, I would prefer  
>> wording
>> such as this:
>>
>>    Before sending the username to the server, the client MUST
>>    ensure that the username is formatted such that the "SASLPrep"
>>    profile [RFC4013] of the "stringprep" algorithm [RFC3454] can be
>>    applied to it without failing.
>
> Although initially, my thought was this wasn't needed, I wondered  
> about the consequences.
>
> It seems to me that, unless we assume that both client and server  
> will always have precisely the same concept of "SASLprep", then one  
> would assume the server would always have to apply SASLprep anyway.
>
> SASLprep is, also bound to change - either gradual changes in Unicode  
> will cause problems sufficient to case a rewrite, or we'll change  
> SASLprep itself to be a property-based, instead of table-based,  
> mechanism, and the gradual changes will filter through to  
> implementations.
>
> I'm inclined, therefore, to suggest that not only is this text  
> reasonable, but the "MUST" can probably be reduced to a SHOULD.

I can live with the SHOULD.

Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Date: Mon, 10 Aug 2009 21:20:09 +0100
From: Dave Cridland <[email-masked]>
To: Peter Saint-Andre <[email-masked]>, <[email-masked]>, Tom Yu <[email-masked]>
Sender: [email-masked]

On Mon Aug 10 21:01:13 2009, Peter Saint-Andre wrote:
> Instead of requiring the application of SASLprep, I would prefer  
> wording
> such as this:
> 
>    Before sending the username to the server, the client MUST
>    ensure that the username is formatted such that the "SASLPrep"
>    profile [RFC4013] of the "stringprep" algorithm [RFC3454] can be
>    applied to it without failing.
> 
> 
Although initially, my thought was this wasn't needed, I wondered  
about the consequences.

It seems to me that, unless we assume that both client and server  
will always have precisely the same concept of "SASLprep", then one  
would assume the server would always have to apply SASLprep anyway.

SASLprep is, also bound to change - either gradual changes in Unicode  
will cause problems sufficient to case a rewrite, or we'll change  
SASLprep itself to be a property-based, instead of table-based,  
mechanism, and the gradual changes will filter through to  
implementations.

I'm inclined, therefore, to suggest that not only is this text  
reasonable, but the "MUST" can probably be reduced to a SHOULD.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Mon, 10 Aug 2009 14:01:13 -0600
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]

On 7/13/09 8:17 PM, Tom Yu wrote:
> This message commences a WG Last Call on the following Internet-Draft:
> 
> 	Title           : Salted Challenge Response (SCRAM) SASL Mechanism

Although the WGLC is officially over, I have a question about the use of
SASLprep.

The SCRAM I-D (draft-ietf-sasl-scram-04) says the following:

   Before sending the username to the server, the client MUST
   prepare the username using the "SASLPrep" profile [RFC4013]
   of the "stringprep" algorithm [RFC3454].

In XMPP, we have traditionally used a different stringprep profile
("nodeprep") to prepare usernames. As far as I can see, nodeprep is more
strict than SASLprep. Therefore, any username which is prepared
according to nodeprep would be safe according to SASLprep.

Instead of requiring the application of SASLprep, I would prefer wording
such as this:

   Before sending the username to the server, the client MUST
   ensure that the username is formatted such that the "SASLPrep"
   profile [RFC4013] of the "stringprep" algorithm [RFC3454] can be
   applied to it without failing.

(We have similar wording in RFC 3920 and in rfc3920bis.)

Peter

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-gs2-16.txt 
Date: Tue,  4 Aug 2009 08:30:02 -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-16.txt
	Pages           : 24
	Date            : 2009-08-04

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-16.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-16.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: Simon Josefsson <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: Alexey Melnikov <[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, 03 Aug 2009 10:09:07 +0200
Sender: [email-masked]

Peter Saint-Andre <[email-masked]> writes:

> On 7/30/09 2:37 PM, Simon Josefsson wrote:
>> Alexey Melnikov <[email-masked]> writes:
>> 
>>> Peter Saint-Andre wrote:
>>>
>>>>> 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).
>>>>>    
>>>>>
>>>> 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.
>>>>  
>>>>
>>> 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.
>
> Do you think that the former text was not ambiguous?

No, I think your version is definitely better, but I couldn't find
matching text in GS2 to change.  I _think_ your clarification is already
covered by what's in GS2 today, including for example this text:

	      <t>Servers SHOULD advertise both non-PLUS and the
		PLUS-variant of each GS2 mechanism name.  If the
		server cannot support channel binding, it MAY
		advertise only the non-PLUS variant.  If the server
		would never succeed authentication of the non-PLUS
		variant due to policy reasons, it MAY advertise only
		the PLUS-variant.</t>

It doesn't use the same words although I believe the intention is the
same.

/Simon