Subject: New SCRAM and GS2 I-Ds

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Mar 2009 11:13:30 -0500

New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
been posted.

These reflect the new GS2 design.

The changes from draft-newman-auth-scram-10 to -11 are fairly small.

To view the diffs side by side go here:

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-10.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-11.txt

or

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-10.txt&url2=http://www.ietf.org/internet-drafts/draft-newman-auth-scram-11.txt

(The former yields "[t]he files are identical" because tools.ietf.org
hasn't updated yet.)

Many of the changes result from switching I-D source from nroff to XML.
The IETF rfcdiff tool nicely renders these changes in the side-by-side
diff.  I've a traditional diff based on a copy of -10 edited to remove
most of these incidental differences -- I can post it if there's
interest.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Mar 2009 08:30:15 +0100

> New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have

A diff for GS2 is available here:

http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-sasl-gs2-11.txt

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Tue, 24 Mar 2009 15:34:57 +0000

> These reflect the new GS2 design.

This looks fine.

However, I'm bewildered by section 6 in the new draft, a bit.

1) Can you explain the difference between the channel binding cases?  
If I say "n", I don't include the "c=" data, because I can't do it.  
Fine. If I say "y", then I *can* include the "c=" data, and the  
server could then take it into account for the hashes, but would be  
unable to verify it. But yet I don't, I have to leave it out. Why?

2) "if the channel was established using a server certificate to  
authenticate the server" - does that mean that if the server  
presented a certificate which I cannot trust, I should use  
tls-unique? Or what? Why would I want to be using  
tls-server-end-point - what does this gain?

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Mar 2009 10:41:34 -0500

> >These reflect the new GS2 design.

Great!

> If I say "n", I don't include the "c=" data, because I can't do it.  

You still include c= because that is used to protect the "n" and
optional authzid from the GS2 header.  But the c= will not include any
channel binding data for an external channel.

> unable to verify it. But yet I don't, I have to leave it out. Why?

"y" means not that the client did include channel binding data for the
external channel, but that it could have -- and that it didn't because
it thought the server did not support channel binding.

If the choice of flag values, "n", "y" and "p" are confusing we can
always pick new ones.

> tls-server-end-point - what does this gain?

Say the server has a self-signed cert, and it's not been pre-shared to
the client.  Then the server is effectively anonymous.  Now, if the
client sees the server cert that server used, then there cannot be an
MITM in at the TLS layer, but if it sees a different cert than the
server used, then the client must be connected to an MITM.  Because
demonstrating that the client saw the same server cert as the server
used is sufficient to rule out an MITM we can use the server's cert as
the channel binding for TLS.  Unique channel bindings could be used too,
but end-point channel bindings play better with TLS concentrators,
therefore we prefer them.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Mar 2009 08:55:25 -0700

> unable to verify it. But yet I don't, I have to leave it out. Why?

No, my understanding is that c= is always included, but it might not 
contain the actual channel binding in some cases.

> tls-server-end-point - what does this gain?

Good question.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 24 Mar 2009 18:13:19 +0000

> New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have

A couple of nits - the ABNF has:

     ;;cbind-type    = value
     ;;cbind-input   = gs2-header [ value ":" cbind-data ]
     channel-binding = "c=" base64
                       ;; base64 encoding of cbind-input

I think the "value" should be "cbind-type", and I think cbind-type =  
"tls-unique" / value would be better to make it clear what kind of  
stuff is expected there.

Also, I wouldn't comment these out.

     client-final-message-without-proof =
                       [channel-binding ","] nonce [","
                       extensions]

Channel binding (c=) is no longer optional, so this needs updating.

Otherwise, i think I'm up to date with these changes, and it really  
didn't take long, so that's great.

Dave.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Mar 2009 14:40:34 -0500

> "tls-unique" / value would be better to make it clear what kind of  

Ah, yes, this is a typo.  I need to define cbind-data (*OCTET) and fix
cbind-input:

     ;;cbind-data    = *OCTET
     ;;cbind-type    = value
     ;;cbind-input   = gs2-header [ cbind-type ":" cbind-data ]

> Channel binding (c=) is no longer optional, so this needs updating.

Good catch, thanks!

> didn't take long, so that's great.

Awesome.

Back to your comments in the room, we can compress the CB flag by
removing one of its possible values since it'd be possible to
unambiguously know what that case would be.  I used that trick to remove
the RFC2743 initial context token header compression flag in the case of
standard GSS mechs (before: "T" or "F"; now: "" or "F").  But I don't
think it's worth it.

Nico
--