Subject: Re: ABNF for the three cases of SCRAM as GS2

From: Alexey Melnikov <[email-masked]>
Date: Sat, 24 Jan 2009 22:35:14 +0000

Chris Newman wrote:

> I was unaware this was stalled waiting for my response until I was 
> told yesterday; apologies for not responding sooner.

I just reviewed what two of you were talking about, so I think I am on 
the same page now.
My reply is a bit long, as I try to explain how I came to various 
conclusions. I hope other readers of this message will find my 
explanation useful.

> I'm finding it very difficult to get my head around this at the moment 
> due to the nested ABNF.  To attempt to better understand it, I'm going 
> to unfold the nested references with some simplifications.

I've done the same thing.

>   First, "gunk" is something I believe to be constant when sent by 
> SASL-SCRAM implementations and ignored when received by SASL-SCRAM 
> implementations (albeit included in a hash if necessary) -- that 
> includes all the security layer stuff since I assume SASL-SCRAM 
> implementations will always negotiate off security layers.  Second, 
> I'm dropping hash-list (we agreed to move that to the mech name), the 
> non-relevant syntax and extensibility for now.  Third, I'm only 
> showing a data item the first time it is transferred (it's sometimes 
> helpful to transfer an item more than once to simplify the code, but 
> that's an optimization we need not consider at the moment).

Right, I saw you dropping repeated nonce in the second client response.

> So I think we end up with (please correct me if this is wrong):

A think you got it more or less correct.

A general comment on what Sam done (which helped me to understand his 
proposals): I think he basically looked at draft-ietf-sasl-gs2 and made 
alternative encodings of the data presented there. He then took ABNF 
draft-newman-auth-scram and tried to modify it, so that GS2 and the 
modified-SCRAM ABNFs agree.

> Case 1:
>
> C1: b64(gunk,c-nonce,username) ":" %x00
> S1: b64(s-nonce,salt,iter-count) ":"
> C2: b64(b64(channel-bind),b64(ClientProof))
>      ":" b64(b64(<MIC-of-something?>),authzid,gunk)
> S2: b64(b64(ServerSignature)) ":" b64(b64(<MIC-of-something?>),gunk)

I dislike this choice in the same way you do, so let's ignore it.
However I will give answers/comments on your questions below, as they 
apply to all 3 cases.

> I'm don't understand how a SASL-SCRAM implementation is supposed to 
> generate the <MIC-of-something> that GSS wrap does.

I am not sure either.

> Does SASL-SCRAM just set this to 0?  I know how the ClientProof is 
> computed (which implicitly includes a MIC), I don't understand the MIC 
> although it doesn't matter if I can set it to 0 and ignore it.

I don't think so, but I hope that calculating a MIC in order to protect 
from replays is fairly easy.

> I don't understand why two sets of channel bindings appear to be present,

One channel binding is as used in SASL. The other is 
GSS-CHANNEL-BINDINGS from 
draft-ietf-kitten-gssapi-channel-bindings-05.txt, i.e. a parameter 
passed to GSS_Init_sec_context() and GSS_Accept_sec_context() calls.

> but I'm assuming that SASL-SCRAM treats the GSS-channel-binding as 
> gunk (send constant / ignore on receipt) for simplicity.  If 
> SASL-SCRAM implementation has to do something else I need to 
> understand what it's expected to do to understand the proposal.

If you look at draft-ietf-sasl-gs2-10.txt, section 5, you will find that 
the GSS-API channel binding parameter must be NULL for GS2. So it would 
always be encoded as an empty string, or would be missing entirely (I am 
not sure exactly how this would look in GSS framing).

> I'm confused about the placement of authzid, since it needs to be 
> included in the SCRAM computations.  The current SCRAM spec includes 
> it in the first client message (optionally).  It's harmless moving it 
> to the second client message but I don't really understand why it ends 
> up in the second b64 blob.

My current understanding of this is that:
If you look at section 4.3 of draft-ietf-sasl-gs2-10.txt, you will find 
there the following (section 4.3.2):

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  client_qops  |               client_maxbuf                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   channel_binding_length                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |[client_cbqops]|          [channel_binding_data]               /
      /                                                               /
      /                         /      [authzid]                      /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

which Sam represented in the textual form as:

gs2-to-be-protected = qop ["," maxbuf] ["," cbqop "," channelbinding]
    ["," authzid] ["," 1*extension]

I.e. the authorization identity is going to be transported by the GS2 
layer itself.

> I'm not fond of this approach due to the three levels of 
> base64-encoding that will occur in many SASL profiles (e.g. IMAP) that 
> use base64 as a wrapper for SASL exchanges.  That extra middle layer 
> makes the interesting content unreadable to any debug/logging 
> mechanism provided in the protocol or SASL layer -- 
> debugging/diagnostics have to be put directly in the SCRAM layer after 
> that middle layer is unwrapped.
>
> Case 2:
>
> C1: gunk,c-nonce,username delim
> S1: s-nonce,salt,iter-count delim
> C2: b64(channel-bind),b64(ClientProof) delim 
> b64(<MIC-of-something?>),authzid,gunk
> S2: b64(ServerSignature) delim b64(<MIC-of-something?>),gunk

After substitution I got:

C1: oidgunk username "," c-nonce delim
S1: s-nonce "," salt "," iteration-count delim
C2: s-nonce "," gss-channel-binding "," proof delim "mic=" base64() ["," 
1*extension] ",d=" c-qop ["," c-maxbuf ] ["," c-cbqop "," 
channelbinding] ["," authzid] ["," 1*extension]
S2: verifier delim "mic=" base64() ["," 1*extension] ",d=" s-qop ["," 
s-maxbuf] ["," 1*extension]

Here channelbinding is the channel binding as used by SASL.
I am not sure why Sam has put gss-channel-binding in the middle of SCRAM 
C2 step though. However it would expand to nothing, as per my earlier 
comment.

If SCRAM never negotiates a security layer, then c-qop, c-maxbuf, 
c-cbqop, s-qop and s-maxbuf become constants.

> Escaping is used where necessary to avoid delim.  Other than not 
> wanting a NUL delim due to the negative impact it has on debugging

Agreed.

> (I'd consider ^A), this seems workable assuming MIC-of-something isn't 
> needed by SASL-SCRAM.
>
> Case 3:
>
> C1: "ctx=" gunk,c-nonce,username
> S1: "ctx=" s-nonce,salt,iter-count
> C2: "mic=" b64(<MIC-of-something?>),gunk,authzid ",ctx=" 
> b64(channel-bind),b64(ClientProof)
> S2: "mic=" b64(<MIC-of-something?>),gunk ",ctx=" b64(ServerSignature)

I got:

C1: "ctx"= oidgunk username "," c-nonce
S1: "ctx"= s-nonce "," salt "," iteration-count
C2: "mic=" base64() "," c-qop ["," c-maxbuf ] ["," c-cbqop "," 
channelbinding] ["," authzid] ["," 1*extension] ",ctx=" s-nonce "," 
gss-channel-binding "," proof
S2: "mic=" base64()  "," s-qop ["," s-maxbuf] ["," 1*extension] ",ctx=" 
verifier

=========
Currently SCRAM is defined as follows:

C1: [mandatory-exts ","] [authzid ","] username "," c-nonce ["," extensions]
S1: [mandatory-exts ","] s-nonce "," salt "," iteration-count ["," 
extensions]
C2: s-nonce "," channel-binding ["," extensions] "," proof
S2: verifier ["," extensions]

> I'm not sure I understand how this is different from case 2.  It seems 
> there's just a different delimiter (specifically, ",ctx=") and the GSS 
> stuff is moved to the beginning.

Agreed. Cases 2 and 3 seem to mostly differ in ordering.

> Regardless, it seems fine to me.

[Sam's message deleted]

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jan 2009 10:19:10 -0500

mic-of-something basically results to hmac(something) for some hmac
key that the SCRAm GS2 mechanism needs to define.  I'd be much happier
if it was derived from the scram key, not identical to it.  So,
hmac(hmac(scram_key,micderivation_constant),stuff)

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Jan 2009 17:10:04 +0000

>hmac(hmac(scram_key,micderivation_constant),stuff)
Sam clarified to me that "stuff" is gs2-to-be-protected, defined by Sam as:
   gs2-to-be-protected = qop ["," maxbuf] ["," cbqop "," channelbinding] 
["," authzid] ["," 1*extension]

I think I have enough information to produce a version of SCRAM that 
would look like Sam's proposal 2 or 3.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Jan 2009 21:30:27 +0000

> would look like Sam's proposal 2 or 3.

To clarify: I will produce both the updated (hopefully final) version of 
SCRAM without GS2-related changes, plus another version which contains 
GS2 related ABNF and examples. Then people can compare the two and make 
a choice. Once the choice is done, I will post the version that should 
be ready for WGLC.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 15:37:41 +0100

Alexey Melnikov writes:
> To clarify: I will produce both the updated (hopefully final) version
> of SCRAM without GS2-related changes, plus another version which
> contains GS2 related ABNF and examples.

Likely not final.  Then your first versions of the "To be written"
appendixes woudl have to pass through with almost no discussion.

I've been waiting for a more finalized draft (by now, in particular
Appendix B) before doing a careful review, and reposting some concerns
of mine in case the authors just hadn't gotten to them yet.  Appendix B
to possibly short-circuit discussion of some other details.  But I can
look through the archives and my notes and (re-)post, if you want.

Some old and new points I remember off-hand:

- Regarding GS2, let me just make a general protest againt the verbose
  way the derivation of GS2 names are spelled out in... I don't remember
  which mechanism draft(s) at the moment.  Just say it has

   "GSS-API mechanism OID: <whatever>
    SASL mechanism name: GS2-<whatever> due to [GS2] section 3)"

- The "m" (Mandatory extensions) field still seems poorly defined to me.

  For one thing the wording is unfortunate - an extension will have to
  break the spec which says "m" must cause failure.

  Next, it'll need further syntax to disambiguate between extensions.
  Why not define that syntax in SCRAM?  E.g. lowercase letters for
  mandatory-to-implement fields and uppercase for optional fields
  ("extensions" in the syntax).

  Or two-letter extension fields: "m" starting a mandatory extension
  and "o" starting an optional one.

> 1.1. Terminology
>    Some clarifications and additional definitions follow:

What's a server-authorized proxy?

> 1.2. Notation
>    U0   := HMAC(str, salt || INT(1))

Make that HMAC(str, (salt || INT(1))) or HMAC((str, salt) || INT(1)).

> 2. Introduction
> - The server does not gain the ability to impersonate the client to
>   other servers (with an exception for server-authorized proxies).

Another exception: An authentication exchange provides enough info to
authenticate as the same user on another server which stores the same
authentication info for that user.  Mentioned as a security
consideration, but I think it belongs with this statement: it's
trivially inherent in the algorithm, and servers with the same data
(mirrors/slaves) is a common scenario.

> 5. SCRAM Authentication Exchange
>    Servers SHOULD announce a hash iteration-count of at least 128.

Why?  Different hash algorithms have different strengths and different
costs to compute, thus I'd think this depends on the hash algorithm.
And, for that matter, on the strength of expected attacks.

Also, how does an iteration count of more than 1 help on a site where
passwords are stored in several forms anyway, maybe including salted MD5
for Unix crypt()?  (Maybe that's for Appendix B or C, I don't know.)

If I remember correctly (and I may not), one problem with the proposed
competing SRP mechanism was the computation cost.  How does that compare
with a high SCRAM iteration count?

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Jan 2009 11:49:42 -0500

>   break the spec which says "m" must cause failure.

It's deliberately not very specified.  The idea is that the first time we 
need this functionality, it will be necessary for a standards-track 
document to amend the specification to describe the syntax of this field 
and the circumstances under which its presence does not cause failure.

>   Why not define that syntax in SCRAM?

I'd be happy to see that happen, but some participants felt that that was 
more complexity than was needed.  We could have just left it out entirely, 
but then it would be impossible to ever add a critical field, because 
implementations of the earlier spec wouldn't be required to fail.  So, we 
were able to convince those people to compromise by making the minimum 
possible provision for future critical fields, which is to define a 
specific field whose contents are currently unspecified and whose presence 
currently triggers failure.

> Make that HMAC(str, (salt || INT(1))) or HMAC((str, salt) || INT(1)).

Uh, why?  It's pretty clear than an HMAC requires two arguments (key and 
message); in fact, that's about three paragraphs above the text you quote. 
I'm not sure what you think "(str,salt) || INT(1)" would even mean.

> authenticate as the same user on another server

... only if the two servers used the same salt, which we specifically warn 
against.  Implemented _correctly_ the protocol does not have this weakness. 
I think the current approach of warning against doing this wrong in 
security considerations is sufficient.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Jan 2009 17:16:08 +0000

Jeffrey Hutzelman wrote:

> It's deliberately not very specified.  The idea is that the first time 
> we need this functionality, it will be necessary for a standards-track 
> document to amend the specification to describe the syntax of this 
> field and the circumstances under which its presence does not cause 
> failure.

I think this explains "m=" handling very well.

> I'd be happy to see that happen, but some participants felt that that 
> was more complexity than was needed.  We could have just left it out 
> entirely, but then it would be impossible to ever add a critical 
> field, because implementations of the earlier spec wouldn't be 
> required to fail.  So, we were able to convince those people to 
> compromise by making the minimum possible provision for future 
> critical fields, which is to define a specific field whose contents 
> are currently unspecified and whose presence currently triggers failure.

+1.

> Uh, why?  It's pretty clear than an HMAC requires two arguments (key 
> and message); in fact, that's about three paragraphs above the text 
> you quote. I'm not sure what you think "(str,salt) || INT(1)" would 
> even mean.

Agreed.

> ... only if the two servers used the same salt, which we specifically 
> warn against.  Implemented _correctly_ the protocol does not have this 
> weakness. I think the current approach of warning against doing this 
> wrong in security considerations is sufficient.

I agree, but I will check to make sure that the document is consistent 
with this advice.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 19:00:55 +0100

[I should have changed the subject.  Better late than nenver...]

Jeffrey Hutzelman writes:
> It's deliberately not very specified.

Yes, but so far we are talking about how the intended (vague) spec is
_worded_.  Which led me to completely misunderstand what was meant, see
the discussion in December.

    "m: Presence of this attribute in a client or a server message MUST
    cause authentication failure when the attribute is parsed by the
    other end."

Just add something amounting to "...except when it correctly matches an
extension the implementation implements", and maybe some words from your
description.  Then extension documents will no longer need to contradict
the original description which says it MUST fail.

As for it's (intended) definition:

> implementations of the earlier spec wouldn't be required to fail.

Hold on.  I think that's a bug anyway.  The draft should say that auth
MUST be aborted if a message doesn't match the grammar in Section 6.

That will automatically support the 'm=' definition as it is described
now, since an initial unknown field does not match the grammar..
So the draft could support mandatory extensions just by saying extension
documents should place them at the beginning.  And optional ones can
stay at the end, where they are ignored when unrecognized.

Anyway, these extensions are new to the -07 draft and I don't remember
any discussion about them on this list prior to the draft, so I think it
must all come from some IETF meeting discussions.  (Which is one reason
I've been waiting for a more finalized draft, like I said:-)

> message); in fact, that's about three paragraphs above the text you quote. 

Nothing important.  Just a bit easier to read.  Or rather, to glance at
without needing to read as far as three paragraphs away.

> I'm not sure what you think "(str,salt) || INT(1)" would even mean.

The meaning would be "I'm sure I'll find out when I've read a bit more".
Which is a fairly common thought for me when browsing specifications:-)

> warn against.

Yes, I said that.  But actually I don't see a warning against it.

  "For this reason, it is important to use randomly-generated salt values."

doesn't say "different ... for different servers".

Also that paragraph only mentions attackers, not untrusted servers.

> Implemented _correctly_ the protocol does not have this

It's a security concern to be aware of.  What to do about it is up
to the admin.

Define "correctly".  Generate some unneeded SCRAM hashes for each
password and store them somewhere safe, in anticipation of the day
when we'll decide to add some extra servers?  Or ask all users to
change passwords because we've added another LDAP server or whatever?

Also such correct behavior would need to override mirroring
functionality between servers.

I agree that by itself, the point belongs in Security Considerations.
My objection is that this point in the Introduction, standing alone, is
simply false:

This explicitly appears to refer to an untrusted server.  One shouldn't
need to go to the The Security Considerations to see that "well, that's
sort of true, as long as the server does <this>".  The intro section
gives the wrong message to a user, and the wrong message to an admin
since having different salts on different server may amount to a major
job.

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Jan 2009 13:31:43 -0500

> the original description which says it MUST fail.

No no.  The idea is that it MUST fail unless you are implementing a newer 
version of the spec which defines different behavior.  This is not (yet) an 
extensibility mechanism; it's a field reserved for use by a later version 
of the spec.

> MUST be aborted if a message doesn't match the grammar in Section 6.

No, we've been over this, and the consensus was that extension fields 
should be non-critical; that is, unrecognized extensions are ignored.  This 
is reflected by the grammar in section 6, which allows arbitrary 
unrecognized name=value pairs in several places.

> stay at the end, where they are ignored when unrecognized.

Hrm.  That's an interesting approach, and it might even work.  But I'm not 
really thrilled with the idea of making the order matter more than it 
already does.  The grammar currently describes fields in a particular 
order, but I would expect implementations to accept them in any order in 
practice, and depending on implementations _not_ to do so seems brittle. 
I'm much happier with an field whose criticality is indicated by its name 
rather than by its position.

> I've been waiting for a more finalized draft, like I said:-)

They are the result of resolving one of the open questions in -06, which is 
whether unrecognized attribute-value-pairs should be ignored.  The answer 
turned out to be "yes, except for this special one, which we reserve for 
future use in defining a critical extension mechanism".

> change passwords because we've added another LDAP server or whatever?

if you have a bunch of mirror servers providing the same service, there's 
really no reason _not_ to use the same salt on all of them.  There's no 
reason for one LDAP server to impersonate a user to another in the same 
pool.  Put another way, you may have multiple machines, but they are 
providing the same _service_.

SCRAM is suited to small environments where it's reasonable to maintain 
separate authentication databases for every service, usually because there 
is no central infrastructure.  If you're trying to set up enterprise-grade 
distributed infrastructure, you should start with an enterprise-grade 
authentication service.

>       other servers (with an exception for server-authorized proxies).

Hm.  Maybe.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 20:30:36 +0100

Jeffrey Hutzelman writes:
> version of the spec which defines different behavior.

But isn't that what I just said?  Except if we are talking of *a* newer
version of the spec, I think calling it "extensions" is a misnomer.
Should be something about "reserved" instead.  

> This is not (yet) an extensibility mechanism; it's a field reserved
> for use by a later version of the spec.

That sounds unproblematic if you are talking about a newer version of
the spec which "obsoletes" this one rather than one of several
extensions which "updates" it.  But now you need to specify that this
is how the field is expected to be updated.  Not necessarily in that
seciont, could go in an appendix.

> should be non-critical; that is, unrecognized extensions are ignored.

Not _mandatory_ extensions, since an older SASL implementation will
abort the authentication when it sees "m=".

> This is reflected by the grammar in section 6, which allows arbitrary

Only the optional extensions ("extensions" grammar symbol), which is at
a fixed place in each message.

> rather than by its position.

I'm quite happy with a required order.  Easier to parse, and no need to
catch and hopefully fail on multiple occurrences of the same field name.

Admittedly order-dependent meaning of extension fields does make me
nervous, but I can't quite come up with a reason.  E.g. a client
typo/bug makes the optional 'a' (authzid) field be sent as 'A', so...
it doesn't match the grammar authentication fails.  Well, good.
Kudos to whoever wrote that grammar.

> future use in defining a critical extension mechanism".

That's not what the grammar does.  It only allows optional extensions
at the end, except for the wart that "p=" comes after it in the final
client message.

Maybe it'd be cleaner to put "p=" at the _front_ of that message?
Then the client immediately knows where to find it, and it can happily
ignore all fields from optional extensions to the end of the message.

>> Define "correctly".  (...)
> 
> if you have a bunch of mirror servers providing the same service,

Mirrors need not provide the same service, in several ways:

> there's really no reason _not_ to use the same salt on all of them.
> There's no reason for one LDAP server to impersonate a user to another
> in the same pool.

Sure there is.  A central well-protected server mirroring to servers
physically present elsewhere, maybe in less protected places (so a
break-in is easier), and/or run by different admins with different
privileges and trust.  Or the servers only mirror a subset of the
directory, or allow access to different people/networks, so they do not
in fact provide the same service.

>>       other servers (with an exception for server-authorized proxies).

Note that we are now talking about exceptions to the exception (the
security considerations) to the rule (the intro statement).

Also you are talking from the administrator point of view.  The
statement looks quite different from a user (or client author) point of
view, if he sends/stores his password through the protocol.
Also to someone browsing various specs to see what claims they make, in
order to _later_ look more carefully at the promising ones.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 21:01:00 +0100

Sorry, I lost my answer to this.

Hallvard B Furuseth writes:
>> is no central infrastructure. 

I don't remember this coming up as a limitation for when to use SCRAM
before, beyond the problem with using passwords in the first place.
Does the draft say this somehow?

>> If you're trying to set up enterprise-grade 

*I'm* not trying to set up anything in particular at the moment.  Though
I'm thinking of various things we've discussed to do in the future, or
of other services I've used myself.

I'm not sure what "enterprise-grade" is except a nice buzzword.  My
reason to choose SASL for something would likely be that it'd be the
best available and widely enough supported alternative for whatever I'm
doing.

>(...)

The point being, the discussion around this point is bringing up a whole
host of unstated assumptions.  Some of which I've just quoted from you
above.  Maybe the point should be restated completely, after looking a
bit closer at just what it is trying to say.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Jan 2009 22:38:34 +0000

>Should be something about "reserved" instead.
In my copy I have the following text:

- m: Presence of this attribute in a client or a server message MUST cause
authentication failure when the attribute is parsed by the other end.
The purpose of this attribute is to describe list of mandatory extensions
to SCRAM that the other end must support. This attribute is reserved for
future extensibility.

I think this is quite clear.

>extensions which "updates" it.
>
What is the practical difference?

>But now you need to specify that this
Can you please recommend specific text for consideration?

>abort the authentication when it sees "m=".
I don't understand this comment. Any optional extension goes at the end. 
Any mandatory extension would result in m= being present and can put 
something at the end.

+1.

>Maybe it'd be cleaner to put "p=" at the _front_ of that message?
Not really. p= is constructed from:

AuthMessage     := client-first-message + "," +
                   server-first-message + "," +
                   final-client-message-without-proof

so it covers everything, including extensions.
One can just strcat() 3 pieces together and calculate hash from them.
Arguably if p= moves to the front of the 
final-client-message-without-proof, then the has would still be easy to 
extract, but it would require extra memcopy, or some other thing.

>ignore all fields from optional extensions to the end of the message.
I am not sure it buys that much. Other opinions?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Jan 2009 18:03:35 -0500

> to SCRAM that the other end must support. This attribute is reserved for

I'm not sure if I like the second sentence.  That's actually how I expect 
this attribute to work, if/when we ever define it, but it would be a 
mistake for any implementor to assume any particular syntax or semantics, 
or for an extension to assume that it can include a mandatory attribute 
under the current spec.

> What is the practical difference?

Process-wise, the difference between "obsoletes" and "updates" is that if 
one document "obsoletes" another, then it is no longer necessary to refer 
to the older document, as the new one completely specifies the new 
protocol.  If one document "updates" another, then it makes changes which 
must be read together with the original document to be meaningful.

That's not the distinction we're actually talking about here.  We're 
talking about the distinction between a document which revises the base 
spec, by either updating or obsoleting the document we're currently 
discussing, and a document which adds an extension using some mechanism 
already provided for that purpose, such as by adding new attributes in the 
places reserved in the protocol for that purpose.

An updated version of the spec can make pretty much any change it wants, 
though it is usually preferred to avoid making backward-incompatible 
changes.  An extension adds to the spec only in previously-defined ways.

I believe we envisioned the m= field as something to be redefined by a 
future revision to SCRAM.  In its present form, it cannot be used by an 
extension which does not revise SCRAM.

> Can you please recommend specific text for consideration?

I don't think any text is required.  It's generally accepted that something 
which is unspecified or reserved is, well, unspecified or reserved, and 
also that a new document which revises an existing one can make more or 
less any change.  We're doing this the way we are specifically to _avoid_ 
having to specify anything about the m= field or how it will work.

>> catch and hopefully fail on multiple occurrences of the same field name.

Recall the golden rule.  It's a well-understood principle that, when 
possible, we should be liberal in what we accept.  Anyone is free to 
produce an implementation that is strict about this, but as protocol 
designers, we would be foolish to assume that everyone will do so and to 
require it for correct operation of the protocol.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Jan 2009 23:46:28 +0000

Jeffrey Hutzelman wrote:

> I'm not sure if I like the second sentence.  That's actually how I 
> expect this attribute to work, if/when we ever define it, but it would 
> be a mistake for any implementor to assume any particular syntax or 
> semantics, or for an extension to assume that it can include a 
> mandatory attribute under the current spec.

Ok, do you want it removed?

> Process-wise, the difference between "obsoletes" and "updates" is that 
> if one document "obsoletes" another, then it is no longer necessary to 
> refer to the older document, as the new one completely specifies the 
> new protocol.  If one document "updates" another, then it makes 
> changes which must be read together with the original document to be 
> meaningful.

I know the IETF meaning of these words. I was talking about 
implementors. In either case an implementor can find the original 
document using www.rfc-editor.org website.

> talking about the distinction between a document which revises the 
> base spec, by either updating or obsoleting the document we're 
> currently discussing, and a document which adds an extension using 
> some mechanism already provided for that purpose, such as by adding 
> new attributes in the places reserved in the protocol for that purpose.
>
> An updated version of the spec can make pretty much any change it 
> wants, though it is usually preferred to avoid making 
> backward-incompatible changes.  An extension adds to the spec only in 
> previously-defined ways.
>
> future revision to SCRAM.  In its present form, it cannot be used by 
> an extension which does not revise SCRAM.

I think you are talking about mechanics of how such hypothetical change 
can be made. I don't think we should care at the moment.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 28 Jan 2009 15:01:58 +0100

> I think this is quite clear.

I thought so too, but apparently I've gotten it wrong several times now
- even after Jeffrey's explanations...

> What is the practical difference?

As Jeffrey pointed out, I've been conflating the RFC process with the
the meaning of what a new RFC does to an old one.  However, about
mandatory extensions (as opposed to the optional ones at the end):

The second is a set of RCFs which an implementation may pick and
choose from.  This is what I understand with the word "extension".
An implementation of the 4rd RFC need not even know about the 2nd
and 3rd, except it must know from the 2nd what to do about "m=".

The first is an ordered sequence of RFCs, each adding to/replacing the
previous one.  An implementation of the 4rd RFC will known about the 2nd
and 3rd, though it might just know enough to recognize and reject any
real use of them if that should be necessary.  If this is what you are
talking about, then don't call it "extensions" at all.

> Can you please recommend specific text for consideration?

But I just did, roughly, and Jeffrey said "no no".  That was my second
attemt too.  My first was the SCRAM "mandatory extensions"? thread,
wich was a total misunderstanding of what was meant.

But I can make another attempt, stealing a bit from later messages in
this thread:

* Rename the field and grammar symbol from "mandatory extensions" and
  "mandatory-exts" to "reserved".

* description:
    - m: This attribute is reserved for future extensibility.
      In this version of SCRAM, its presence in a client or a server
      message MUST cause authentication failure when the attribute is
      parsed by the other end.

> I don't understand this comment.

Nor do I understand Jeffrey's.  We were discussing mandatory extensions,
"m=" or a replacement for it.  This cannot be ignored, it'll cause a
failure in the current implementation.  So how does that square with
"unrecognized extensions are ignored"?  That's the optional extensions
field in the draft.  Unless the draft is saying something quite else
than people agreed off-line that it should say - and I'm talking about
the draft while he's talking about that off-line agreement.

> Any optional extension goes at the end. 

Yes.  Or, I assumed, it could have m=something present and not put
something at the end.  Or it could have an optional extensions without
"m=" at the front.

But this was an approach I had not thought of.  You mean something like,
an RFC puts the actual extension data ",x=foo" at the end, and "m=x," at
the front to tell SCRAM that this particular "x=foo" extension cannot be
ignored?

But again, that's just another way to spell out a critical x= extension,
so I don't see how it squares with "consensus was that extension fields
should be non-critical" as an objection to another way to spell out
mandatory extensions.

Could you describe a practical example of how you imagine this field
being defined and used, presumably with one RFC defining it and two
others using it?  Even if you don't want this in the spec, it'd be nice
to be sure we are somewhere on the same page in this discussion.  So far
we apparently haven't been.

> One can just strcat() 3 pieces together and calculate hash from them.

Yes...

> extract, but it would require extra memcopy, or some other thing.

Yes, the trade-off is whether it should be easy to parse or easy to
construct.  Generally parsing is the less trivial and thus most
bug-prone task, which is why I suggested putting it at the front.

BTW, this is also why I like the grammar with fixed placement of
fields.  Even if it seems simple enough, IIRC the opposite approach
was one of the sources of bugs people mentioned for DIGEST-MD5.

> I am not sure it buys that much. Other opinions?

I just came up with one myself: One could not compute ClientSignature
and ServerSignature while sending the message, so one must construct the
entire message in memory before sending.  Not sure how much of an
objection that is though.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 28 Jan 2009 15:24:12 +0100

> mandatory extensions (as opposed to the optional ones at the end):

Argh...  no, not mandatory vs. optional extensions.
 
> The second

that is, what I called "updating" SCRAM

> is a set of RCFs which an implementation may pick and
> The first

I.e. "obsoleting" SCRAM

> is an ordered sequence of RFCs, each adding to/replacing the

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Jan 2009 09:31:19 -0500

> talking about, then don't call it "extensions" at all.

Yes, that's a pretty good description of the distinction I was going for. 
The m= field is intended to be a reserved field whose semantics will be 
defined by a future protocol update.  The _expectation_ is that said update 
will define semantics which make it possible for "extensions" to have 
critical/mandatory fields.  Likely the value of m= will turn out to be a 
list of names of other extension fields which are also mandatory, but we 
haven't actually said that, and a large part of the point is to avoid 
having to nail that down and say it right now.

FWIW, I think it's likely that the first time we have an extension which 
needs a mandatory field, we'll do it in a single document which both 
revises the spec to define how the m= field works _and_ adds an extension, 
which I think you allude to above.

If you think it's confusing to use the name "mandatory-exts" for the 
nonterminal describing the "m=" field, it could be changed.  I think the 
name is intended to be interpreted in the same vein as the others around 
it; "m=" isn't itself a mandatory extension any more than "n=" is a 
username.  Rather, "m=" contains the list of mandatory extensions just as 
"n=" contains the username.

> attemt too.

I think we're converging.

>  My first was the SCRAM "mandatory extensions"? thread,

Sounds reasonable to me.

>>>> should be non-critical; that is, unrecognized extensions are ignored.

Nevermind this.  I misinterpreted you; I thought you were suggesting that 
all unrecognized fields should be rejected, right after we updated the 
document to make it clear that they are allowed.

Read strictly, the grammar only admits unrecognized fields at the end of 
each of several messages, and unrecognized fields elsewhere are invalid.

I think we need to be much more clear on this point.  If we want to require 
attributes to be in a particular order, then we need to say that the sender 
MUST put them in that order.  If we are going to make use of this fact to 
put critical extensions at the front, then we also need to say that the 
recipient MUST reject messages where they are not in order.  I'd much 
rather stick with m= as the indicator for critical extensions, and allow 
receivers to accept messages with the attributes in any order. 
Interoperability is better served by "be strict in what you send, and 
liberal in what you accept" than by "be strict in what you send and in what 
you accept".

> objection that is though.

I don't think it's a significant one, given the sizes of the messages 
involved.  That said, it seems somehow more aesthetically pleasing to me to 
keep it at the end.  Whatever.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Jan 2009 16:10:01 +0000

Jeffrey Hutzelman wrote:

> Yes, that's a pretty good description of the distinction I was going 
> for. The m= field is intended to be a reserved field whose semantics 
> will be defined by a future protocol update.  The _expectation_ is 
> that said update will define semantics which make it possible for 
> "extensions" to have critical/mandatory fields.  Likely the value of 
> m= will turn out to be a list of names of other extension fields which 
> are also mandatory, but we haven't actually said that, and a large 
> part of the point is to avoid having to nail that down and say it 
> right now.
>
> FWIW, I think it's likely that the first time we have an extension 
> which needs a mandatory field, we'll do it in a single document which 
> both revises the spec to define how the m= field works _and_ adds an 
> extension, which I think you allude to above.

Agreed.

> nonterminal describing the "m=" field, it could be changed.  I think 
> the name is intended to be interpreted in the same vein as the others 
> around it; "m=" isn't itself a mandatory extension any more than "n=" 
> is a username.  Rather, "m=" contains the list of mandatory extensions 
> just as "n=" contains the username.
>

It finally looks like that to me too :-).

>>       message MUST cause authentication failure when the attribute is

That is fine with me as well.

> Nevermind this.  I misinterpreted you; I thought you were suggesting 
> that all unrecognized fields should be rejected, right after we 
> updated the document to make it clear that they are allowed.
>
> Read strictly, the grammar only admits unrecognized fields at the end 
> of each of several messages, and unrecognized fields elsewhere are 
> invalid.

Right.

> I think we need to be much more clear on this point.  If we want to 
> require attributes to be in a particular order, then we need to say 
> that the sender MUST put them in that order.  If we are going to make 
> use of this fact to put critical extensions at the front, then we also 
> need to say that the recipient MUST reject messages where they are not 
> in order.

Ok, this sound reasonable.
But let me think a bit more about ordering.

> I'd much rather stick with m= as the indicator for critical 
> extensions, and allow receivers to accept messages with the attributes 
> in any order. Interoperability is better served by "be strict in what 
> you send, and liberal in what you accept" than by "be strict in what 
> you send and in what you accept".

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Jan 2009 11:57:51 +0000

>Jeffrey Hutzelman writes:
 [...]

>without needing to read as far as three paragraphs away.
I actually disagree that adding extra () would add clarity in this case. 
Besides, I was reusing a concention defined in another RFC.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Jan 2009 11:53:46 +0000

Hallvard B Furuseth wrote:

>Likely not final.
I meant in the sense that it would be good enough for the WGLC.

>Then your first versions of the "To be written"
Yes please.
Please don't mention the description of m= again, I will take care of 
that. Actually, you might hold off till I posted an updated version.

>    SASL mechanism name: GS2-<whatever> due to [GS2] section 3)"
Yes, absolutely.

 [...]

>What's a server-authorized proxy?
An entity authorized by the server to act on its behalf. I am not sure 
this needs to be spelled out?
 [...]

>costs to compute, thus I'd think this depends on the hash algorithm.
Yes, I agree with that.
So I've moved this sentence to the section talking about various SCRAM 
attributes and reworded it as:
    For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash 
iteration-count
    of at least 128.

>And, for that matter, on the strength of expected attacks.
This is just a minimal requirement, deployments can choose bigger 
values, or, if there is a good reason, smaller values.
I would be happy with having any value that the Security Directorate 
would recommend for HMAC-SHA-1.

>for Unix crypt()?  (Maybe that's for Appendix B or C, I don't know.)
My understanding is that one can read values from hashed password files 
and use them to implement server side SCRAM.
There is no requirement that SCRAM specific hash be stored in such files.

>with a high SCRAM iteration count?
I think some tests need to be performed before I can answer this question.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Jan 2009 12:00:49 +0000

[...]

> in the same pool.  Put another way, you may have multiple machines, 
> but they are providing the same _service_.

Agreed.

> SCRAM is suited to small environments where it's reasonable to 
> maintain separate authentication databases for every service, usually 
> because there is no central infrastructure.  If you're trying to set 
> up enterprise-grade distributed infrastructure, you should start with 
> an enterprise-grade authentication service.
>

Hallvard, can you please recommend specific changes to the document?

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Jan 2009 12:41:10 +0000

[...]

>  "mandatory-exts" to "reserved".
I've used "reserved-mext", because "reserved" is an overloaded ABNF 
non-terminal name.

>      message MUST cause authentication failure when the attribute is
Done.

>failure in the current implementation.
>
Correct.

>So how does that square with
>"unrecognized extensions are ignored"?
>
"Unrecognized extension attributes", i.e. attributes not defined in the 
draft (the inside of <extensions> ABNF production), MUST be ignored.
The m= attribute is not unrecognized, as it is defined (even though 
without a syntax ;-)).

>That's the optional extensions
That is another possibility, yes.

>Or it could have an optional extensions without
>"m=" at the front.
>  
>
We can always do that too, assuming the draft is updated to say that 
unrecognized attributes in unexpected places (such as at the front) MUST 
be ignored.
(Please note that I don't think we have consensus on this change just yet)

>the front to tell SCRAM that this particular "x=foo" extension cannot be
Yes!

>we apparently haven't been.
Well, if this help you understand: one possibility is to define "m" as 
containing a list of other attribute that are mandatory.
I.e. if m=xy, then understanding of x=foo and y=bar by the other end 
would be required to succeed.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Jan 2009 12:44:43 +0000

> would be required to succeed.

To continue this example: m=xy would be the same as m=yx and I also 
think we should say that the order of extension attributes can be arbitrary.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Jan 2009 12:48:41 +0000

[...]

>was one of the sources of bugs people mentioned for DIGEST-MD5.
Yes, this is a good point.
(Note, that despite that I haven't made my own decision yet)

>objection that is though.
I don't think this matters even for small devices, as SCRAM messages are 
not going to be big.
What is more important is to allow for easy/fast implementations, for 
example to allow a single buffer to be used.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 31 Jan 2009 22:12:21 +0100

> this needs to be spelled out?

To clarify my request for clarification, I'm not sure what these points
in the intro are saying, even with your explanation:

    - The mechanism permits the use of a server-authorized proxy without
      requiring that proxy to have super-user rights with the back-end
      server.

Where does this proxy sit, and how does this proxy auth work?  If both
server and proxy needs to see the scram-auth the user, I assume that
would break if the channel binding field is present.  If they don't,
then one trusts the other to tell it the user's identity, which I
suppose is what you mean by super-user privileges.  Or can one of them
watch the auth performed by the other, and verify that it is valid?

Unless the draft is just saying that SCRAM supports the SASL
authorization identity field and servers must do some internal auth
magic to make use of that.

> There is no requirement that SCRAM specific hash be stored in such files.

That sounds strange, unless you are talking about a weakness which can
be attacked.

The password-file secret would be
  salt, Hash(salt || password)
while even with iteration count 0, SCRAM SaltedPassword is
  Hash((password XOR opad) || Hash((password XOR ipad) || salt || INT(1)))

In any case, if there is a mapping MD5 crypt -> SCRAM crypt, that just
makes the iteration count less useful as far as I can see.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 31 Jan 2009 22:12:21 +0100
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

> this needs to be spelled out?

To clarify my request for clarification, I'm not sure what these points
in the intro are saying, even with your explanation:

    - The mechanism permits the use of a server-authorized proxy without
      requiring that proxy to have super-user rights with the back-end
      server.

Where does this proxy sit, and how does this proxy auth work?  If both
server and proxy needs to see the scram-auth the user, I assume that
would break if the channel binding field is present.  If they don't,
then one trusts the other to tell it the user's identity, which I
suppose is what you mean by super-user privileges.  Or can one of them
watch the auth performed by the other, and verify that it is valid?

Unless the draft is just saying that SCRAM supports the SASL
authorization identity field and servers must do some internal auth
magic to make use of that.

> There is no requirement that SCRAM specific hash be stored in such files.

That sounds strange, unless you are talking about a weakness which can
be attacked.

The password-file secret would be
  salt, Hash(salt || password)
while even with iteration count 0, SCRAM SaltedPassword is
  Hash((password XOR opad) || Hash((password XOR ipad) || salt || INT(1)))

In any case, if there is a mapping MD5 crypt -> SCRAM crypt, that just
makes the iteration count less useful as far as I can see.

-- 
Hallvard

Date: Sat, 31 Jan 2009 12:48:41 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

 [...]

Date: Sat, 31 Jan 2009 12:44:43 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

Date: Sat, 31 Jan 2009 12:41:10 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

 [...]

Done.

Correct.

Yes!

Date: Sat, 31 Jan 2009 12:00:49 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

 [...]

Agreed.

Date: Sat, 31 Jan 2009 11:57:51 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

 [...]

Date: Sat, 31 Jan 2009 11:53:46 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

Yes please.

Yes, absolutely.

 [...]

Yes, I agree with that.

Date: Wed, 28 Jan 2009 16:10:01 +0000
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

Agreed.

Right.

> you send and in what you accept".

Date: Wed, 28 Jan 2009 09:31:19 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

Sounds reasonable to me.

-- Jeff

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 28 Jan 2009 15:24:12 +0100
To: Alexey Melnikov <[email-masked]>
cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

 

I.e. "obsoleting" SCRAM

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 28 Jan 2009 15:01:58 +0100
To: Alexey Melnikov <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

* description:

Yes...

-- 
Hallvard

Date: Tue, 27 Jan 2009 23:46:28 +0000
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

Date: Tue, 27 Jan 2009 18:03:35 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

-- Jeff

Date: Tue, 27 Jan 2009 22:38:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes
Sender: [email-masked]

+1.

Date: Tue, 27 Jan 2009 21:08:27 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: IANA Hash Function Textual Names vs. SCRAM mechanism names
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Now that I'm looking at SCRAM again (draft-newman-auth-scram-07.txt):
>  
>
>>4. SCRAM mechanism names
>>
>>   A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
>>   uppercased name of the underlying hashed function taken from the
>>   IANA "Hash Function Textual Names" registry.
>>    
>>
>Thus SCRAM can only use hash functions with case-insensitive names
>of max 9 of the characters [-_0-9A-Z].  See RFC 4422 section 3.1.
>  
>
Yes, I've raised this issue myself.

>Is there anything to prevent "LongCaseSensitiveName/paramName(value)"
>from being registered as a hash function?  I don't see anything in RFC
>3279 or <http://www.iana.org/assignments/hash-function-text-names/>.
>   
>Should we obsolete RFC 3279 for one which requires somewhat friendlier
>names?
>  
>
I agree with Jeff that we shouldn't obsolete this RFC. But we can try to 
put extra restrictions on the registry.

>Or do we defer any worry until it happens,
>
That too.

>and register aliases for new
>SCRAM-unfriendly names if they arrive?  We'd need to keep that option
>open anyway: I expect a 9-character limit on IANA hash function names
>could be too restrictive, in particular if someone invents and registers
>hash function family names.
>  
>

Jeffrey Hutzelman wrote:
 [...]

> In practice, I don't think we need to worry about it.  New names can 
> be added to that registry only by standards-track RFC's which update 
> or replace RFC3279, which is a pretty narrow category requiring fairly 
> wide review.  I don't expect anyone will ever try to define a hash 
> function name which is deliberately long, invalid, or ambiguous.

Agreed.

> Note, BTW, that there is no such thing as a "case-insensitive name"; 
> only case-insensitive treatment of names.  Regardless of what case 
> might be used in registering a hash function name, we can still use it 
> in a SASL mechanism name, unless/until there are two hash functions 
> whose registered names differ only in case, which I somehow doubt 
> would pass the review required for standards-track RFC's.

Date: Tue, 27 Jan 2009 15:17:17 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: IANA Hash Function Textual Names vs. SCRAM mechanism names
Sender: [email-masked]

--On Tuesday, January 27, 2009 08:47:29 PM +0100 Hallvard B Furuseth 
<[email-masked]> wrote:

> Hopefully so.  I guess it's GS2 which has me worried.  It'd never have
> occurred to me to worry that a SASL mechanism name might someday be
> named something unreadable like "GS2-DT4PIK22T6APV2PY" either.
> A similar idea but base64 instead of base32 and SASL would be in
> trouble.  Or lowercase(base64()), since I too would expect required
> case-sensitive treatment to raise loud protests.

Well, GS2 is a SASL mechanism family, and so was designed specifically with 
the requirements of SASL in mind.  Compare to RFC4462, which defines a 
family of GSS-API-based SSH key exchange algorithms using a similar 
technique, but based on the requirements of SSH.

-- Jeff

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 21:01:00 +0100
To: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes (was: ABNF for the three cases of SCRAM as GS2)
Sender: [email-masked]

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 20:47:29 +0100
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked]
Subject: Re: IANA Hash Function Textual Names vs. SCRAM mechanism names
Sender: [email-masked]

Jeffrey Hutzelman writes:
> Well, we certainly shouldn't obsolete RFC3279, which doesn't create that 
> registry or specify its rules, but does specify names and OID's for a 
> number of hash functions in wide use today.  Besides, it's not ours.
> 
> We also shouldn't obsolete RFC4572, which does create the registry and set 
> its rules, but is mostly about specifying SDP over TLS.  Besides, it also 
> is not ours.

Argh, I took the RFC name from the wrong browser window...  Anyway, I
didn't mean "we" would do it as in SASL taking it over, more like
someone doing whatever was required.  However,

> In practice, I don't think we need to worry about it.
>
> New names can be 
> added to that registry only by standards-track RFC's which update or 
> replace RFC3279, which is a pretty narrow category requiring fairly wide 
> review.  I don't expect anyone will ever try to define a hash function name 
> which is deliberately long, invalid, or ambiguous.

Fine by me.  As long as _someone_ who knows SASL keeps track.

> Note, BTW, that there is no such thing as a "case-insensitive name"; only 
> case-insensitive treatment of names.

Right, that was sloppy.

> Regardless of what case might be used in registering a hash function
> name, we can still use it in a SASL mechanism name, unless/until there
> are two hash functions whose registered names differ only in case,
> which I somehow doubt would pass the review required for
> standards-track RFC's.

Hopefully so.  I guess it's GS2 which has me worried.  It'd never have
occurred to me to worry that a SASL mechanism name might someday be
named something unreadable like "GS2-DT4PIK22T6APV2PY" either.
A similar idea but base64 instead of base32 and SASL would be in
trouble.  Or lowercase(base64()), since I too would expect required
case-sensitive treatment to raise loud protests.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 20:30:36 +0100
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes (was: ABNF for the three cases of SCRAM as GS2)
Sender: [email-masked]

-- 
Hallvard

Date: Tue, 27 Jan 2009 14:10:58 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: IANA Hash Function Textual Names vs. SCRAM mechanism names
Sender: [email-masked]

--On Tuesday, January 27, 2009 07:31:25 PM +0100 Hallvard B Furuseth 
<[email-masked]> wrote:

>
> Is there anything to prevent "LongCaseSensitiveName/paramName(value)"
> from being registered as a hash function?  I don't see anything in RFC
> 3279 or <http://www.iana.org/assignments/hash-function-text-names/>.
>
> Should we obsolete RFC 3279 for one which requires somewhat friendlier
> names?

Well, we certainly shouldn't obsolete RFC3279, which doesn't create that 
registry or specify its rules, but does specify names and OID's for a 
number of hash functions in wide use today.  Besides, it's not ours.

We also shouldn't obsolete RFC4572, which does create the registry and set 
its rules, but is mostly about specifying SDP over TLS.  Besides, it also 
is not ours.

In practice, I don't think we need to worry about it.  New names can be 
added to that registry only by standards-track RFC's which update or 
replace RFC3279, which is a pretty narrow category requiring fairly wide 
review.  I don't expect anyone will ever try to define a hash function name 
which is deliberately long, invalid, or ambiguous.

Note, BTW, that there is no such thing as a "case-insensitive name"; only 
case-insensitive treatment of names.  Regardless of what case might be used 
in registering a hash function name, we can still use it in a SASL 
mechanism name, unless/until there are two hash functions whose registered 
names differ only in case, which I somehow doubt would pass the review 
required for standards-track RFC's.

-- Jeff

Date: Tue, 27 Jan 2009 13:31:43 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SCRAM notes (was: ABNF for the three cases of SCRAM as GS2)
Sender: [email-masked]

Hm.  Maybe.

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: IANA Hash Function Textual Names vs. SCRAM mechanism names
Date: Tue, 27 Jan 2009 19:31:25 +0100
Sender: [email-masked]

Now that I'm looking at SCRAM again (draft-newman-auth-scram-07.txt):

> 4. SCRAM mechanism names
>
>    A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
>    uppercased name of the underlying hashed function taken from the
>    IANA "Hash Function Textual Names" registry.

Thus SCRAM can only use hash functions with case-insensitive names
of max 9 of the characters [-_0-9A-Z].  See RFC 4422 section 3.1.

Is there anything to prevent "LongCaseSensitiveName/paramName(value)"
from being registered as a hash function?  I don't see anything in RFC
3279 or <http://www.iana.org/assignments/hash-function-text-names/>.
   
Should we obsolete RFC 3279 for one which requires somewhat friendlier
names?

Or do we defer any worry until it happens, and register aliases for new
SCRAM-unfriendly names if they arrive?  We'd need to keep that option
open anyway: I expect a 9-character limit on IANA hash function names
could be too restrictive, in particular if someone invents and registers
hash function family names.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 19:00:55 +0100
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM notes (was: ABNF for the three cases of SCRAM as GS2)
Sender: [email-masked]

-- 
Hallvard

Date: Tue, 27 Jan 2009 17:16:08 +0000
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>, Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

+1.

Agreed.

Date: Tue, 27 Jan 2009 11:49:42 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

-- Jeff

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 15:37:41 +0100
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

-- 
Hallvard

Date: Mon, 26 Jan 2009 21:30:27 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

Date: Mon, 26 Jan 2009 17:10:04 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

From: Sam Hartman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Date: Mon, 26 Jan 2009 10:19:10 -0500
Sender: [email-masked]

Date: Sat, 24 Jan 2009 22:35:14 +0000
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Sender: [email-masked]

I am not sure either.

Agreed.

I got:

=========

[Sam's message deleted]

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: gs2 hashed oids
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 23 Jan 2009 13:02:04 +0100
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> I have review this thread and the history.
>
> The WG previously made a design choice to use "hashed" GS2- mechanism
> names instead of individually "registered" SASL names.  This design
> choice was reviewed as part of the previous WG Last Call(s) and
> believed to be supported by WG consensus.
>
> In reviewing the recent discussions, I find that while there is a camp
> who prefers "registered" SASL names, most in this came can live with
> "hashed" names.  However, those in the "hashed" camp cannot live with
> "registered" SASL names because with "registered" SASL names GSS-API
> mechanisms could not automatically be SASL mechanisms within an
> implementation.  It seems the latter camp has a stronger technical
> argument.
>
> Hence, I find that there is insufficient consensus to change to
> "registered" SASL names.

Thanks for making this call.  Once the SCRAM wire syntax question is
decided, I can resume work on GS2 and will then keep the current hash
approach to mech names.

/Simon

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Re: gs2 hashed oids
Date: Thu, 22 Jan 2009 22:46:36 -0800
Sender: [email-masked]

I have review this thread and the history.

The WG previously made a design choice to use "hashed" GS2- mechanism  
names instead of individually "registered" SASL names.  This design  
choice was reviewed as part of the previous WG Last Call(s) and  
believed to be supported by WG consensus.

In reviewing the recent discussions, I find that while there is a camp  
who prefers "registered" SASL names, most in this came can live with  
"hashed" names.  However, those in the "hashed" camp cannot live with  
"registered" SASL names because with "registered" SASL names GSS-API  
mechanisms could not automatically be SASL mechanisms within an  
implementation.  It seems the latter camp has a stronger technical  
argument.

Hence, I find that there is insufficient consensus to change to  
"registered" SASL names.

-- Kurt, as SASL co-chair

Date: Tue, 20 Jan 2009 10:52:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: [IETF Meeting Session Request Tool] sasl - New Meeting Session Request for IETF 74
Sender: [email-masked]

Tom Yu wrote:

>Please let me know if I should revise the conflict list.
>  
>
 [...]

>Conflicts to Avoid:
>  First Priority: apparea saag sieve krb-wg kitten vcarddav
>  
>
Hi Tom,
Can you please add "morg" and "xmpp BOF" to the first priority list?

>  Second Priority: dkim emu eai pkix
>  Third Priority: httpbis idnabis lemonade smime tls
>  
>

Date: Tue, 20 Jan 2009 10:52:05 +0000
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: [IETF Meeting Session Request Tool] sasl - New Meeting Session Request for IETF 74
Sender: [email-masked]

Tom Yu wrote:

>Please let me know if I should revise the conflict list.
>  
>
 [...]

>Conflicts to Avoid:
>  First Priority: apparea saag sieve krb-wg kitten vcarddav
>  
>
Hi Tom,
Can you please add "morg" to the first priority list?

>  Second Priority: dkim emu eai pkix
>  Third Priority: httpbis idnabis lemonade smime tls
>  
>

Date: Tue, 20 Jan 2009 06:47:42 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
Sender: [email-masked]

At 2009-01-18 21:48:07 +0000, [email-masked] wrote:
>
> So, any objections of changing "value-safe-char" to be any UTF-8
> encoded Unicode character except for NUL (which is universally
> disallowed), "=" and ","?

Fine with me.

-- ams

To: [email-masked]
Subject: [IETF Meeting Session Request Tool] sasl - New Meeting Session Request for IETF 74
From: Tom Yu <[email-masked]>
Date: Mon, 19 Jan 2009 19:54:52 -0500
Lines: 52
Sender: [email-masked]

--=-=-=

Please let me know if I should revise the conflict list.

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

From: IETF Meeting Session Request Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
        [email-masked]
Subject: sasl - New Meeting Session Request for IETF 74 
Date: Mon, 19 Jan 2009 16:50:36 -0800 (PST)
Lines: 23

A new meeting session request has just been submitted
by Tom Yu, a working group chair of sasl.

---------------------------------------------------------
Working Group Name: sasl
Area Name: Security Area
Session Requester: Tom Yu

Number of Sessions: 1
Length of Session(s):  2 hours

Number of Attendees: 30
Conflicts to Avoid:
  First Priority: apparea saag sieve krb-wg kitten vcarddav
  Second Priority: dkim emu eai pkix
  Third Priority: httpbis idnabis lemonade smime tls

Special Requests:
  second video projector and screen, and additional microphones, as we and kitten and krb-wg have done in the past
---------------------------------------------------------

--=-=-=--

Date: Mon, 19 Jan 2009 11:53:45 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Abhijit Menon-Sen <[email-masked]>, Chris Newman <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
Sender: [email-masked]

--On Sunday, January 18, 2009 09:48:07 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>
> Hi,
> This is a minor issue with existing SCRAM ABNF:
>
>> saslname        = 1*(value-safe-char / "=2C" / "=3D")
>>                            ;; Conforms to <value>
>>
>> value-safe-char = %20-2B / %2D-3C / %3E-7E /
>>                               UTF8-2 / UTF-3 / UTF8-4
>> ;; UTF8-char except CTL, "=", and ",".
>>
>> authzid         = "a=" saslname
>
> Authorization identity is protocol specific, so I don't think the
> document should disallow US-ASCII CTLs in it.
> So, any objections of changing "value-safe-char" to be any UTF-8 encoded
> Unicode character except for NUL (which is universally disallowed), "="
> and ","?

Sounds good to me.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Abhijit Menon-Sen <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 19 Jan 2009 12:52:05 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>
>>Alexey Melnikov <[email-masked]> writes:
>>  
>>
>>>Hi,
>>>This is a minor issue with existing SCRAM ABNF:
>>>    
>>>
>>>>saslname        = 1*(value-safe-char / "=2C" / "=3D")
>>>>                           ;; Conforms to <value>
>>>>
>>>>value-safe-char = %20-2B / %2D-3C / %3E-7E /
>>>>                              UTF8-2 / UTF-3 / UTF8-4
>>>>;; UTF8-char except CTL, "=", and ",".
>>>>
>>>>authzid         = "a=" saslname
>>>>      
>>>>
>>>Authorization identity is protocol specific, so I don't think the
>>>document should disallow US-ASCII CTLs in it.
>>>So, any objections of changing "value-safe-char" to be any UTF-8
>>>encoded Unicode character except for NUL (which is universally
>>>disallowed), "=" and ","?
>>>    
>>>
>>I think per RFC 4422 you should only exclude NUL.
>>  
>>
> Yes.
> But "=" and "," are special characters in SCRAM, so they are encoded
> as "=2C" and "=3D".

Ok, if all non-NUL characters are escaped, I don't see a problem.  +1
from me.

/Simon

Date: Mon, 19 Jan 2009 11:27:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Abhijit Menon-Sen <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>Hi,
>>This is a minor issue with existing SCRAM ABNF:
>>    
>>
>>>saslname        = 1*(value-safe-char / "=2C" / "=3D")
>>>                           ;; Conforms to <value>
>>>
>>>value-safe-char = %20-2B / %2D-3C / %3E-7E /
>>>                              UTF8-2 / UTF-3 / UTF8-4
>>>;; UTF8-char except CTL, "=", and ",".
>>>
>>>authzid         = "a=" saslname
>>>      
>>>
>>Authorization identity is protocol specific, so I don't think the
>>document should disallow US-ASCII CTLs in it.
>>So, any objections of changing "value-safe-char" to be any UTF-8
>>encoded Unicode character except for NUL (which is universally
>>disallowed), "=" and ","?
>>    
>>
>I think per RFC 4422 you should only exclude NUL.
>  
>
Yes.
But "=" and "," are special characters in SCRAM, so they are encoded as 
"=2C" and "=3D".

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Abhijit Menon-Sen <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 19 Jan 2009 12:23:55 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Hi,
> This is a minor issue with existing SCRAM ABNF:
>
>> saslname        = 1*(value-safe-char / "=2C" / "=3D")
>>                            ;; Conforms to <value>
>>
>> value-safe-char = %20-2B / %2D-3C / %3E-7E /
>>                               UTF8-2 / UTF-3 / UTF8-4
>> ;; UTF8-char except CTL, "=", and ",".
>>
>> authzid         = "a=" saslname
>
> Authorization identity is protocol specific, so I don't think the
> document should disallow US-ASCII CTLs in it.
> So, any objections of changing "value-safe-char" to be any UTF-8
> encoded Unicode character except for NUL (which is universally
> disallowed), "=" and ","?

I think per RFC 4422 you should only exclude NUL.

3.4.1.  Authorization Identity String

   The authorization identity string is a sequence of zero or more
   Unicode [Unicode] characters, excluding the NUL (U+0000) character,
   representing the identity to act as.
...

   While the character encoding schema used to transfer the
   authorization identity string in the authentication exchange is
   mechanism specific, mechanisms are expected to be capable of carrying
   the entire Unicode repertoire (with the exception of the NUL
   character).

/Simon

Date: Sun, 18 Jan 2009 21:48:07 +0000
From: Alexey Melnikov <[email-masked]>
To: Abhijit Menon-Sen <[email-masked]>, Chris Newman <[email-masked]>
CC: [email-masked]
Subject: Allowed characters in SCRAM authentication/authorization identities
Sender: [email-masked]

Hi,
This is a minor issue with existing SCRAM ABNF:

> saslname        = 1*(value-safe-char / "=2C" / "=3D")
>                            ;; Conforms to <value>
>
> value-safe-char = %20-2B / %2D-3C / %3E-7E /
>                               UTF8-2 / UTF-3 / UTF8-4
> ;; UTF8-char except CTL, "=", and ",".
>
> authzid         = "a=" saslname

Authorization identity is protocol specific, so I don't think the 
document should disallow US-ASCII CTLs in it.
So, any objections of changing "value-safe-char" to be any UTF-8 encoded 
Unicode character except for NUL (which is universally disallowed), "=" 
and ","?

Date: Thu, 8 Jan 2009 16:01:21 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: gs2 hashed oids
Sender: [email-masked]

Jeffrey Hutzelman writes:
> Yes, but the SASL and GS2 implementation need not worry about this; 
> all they should need to do is call GSS_Indicate_mechs(), whose result 
> will include any composite mechanisms which are part of the default 
> set.  Or, it may use GSS_Indicate_mechs_by_mech_attrs() to list 
> mechanisms (including composite mechanisms) which have the attributes 
> GS2 requires.

I see. But then a different problem appears. It sounds as if the list 
may be long.

IMAP servers are required to return a list of available SASL mechanism 
on a single line, and that line shouldn't be too long. The relevant RFC 
cautions against lines longer than 8k, which gives space for about 350 
GS2 names after subtracting syntax and some other stuff, so I assume 
that problems will appear somewhere between 100 and 1000 GS2 mechanism 
stacks.

Other protocols (or common deployed implementations) may have limits, 
but I don't care to research that now, so I'll just take 100-1000.

How likely are 100-1000 OIDs? Unthinktable, possible, unusual or common?

Arnt

Date: Thu, 08 Jan 2009 09:43:30 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: gs2 hashed oids
Sender: [email-masked]

--On Thursday, January 08, 2009 02:39:34 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> Stackable pseudo-mechanisms are not the same as multi-level negotiation.
>> Multi-level negotiation is a problem because you end up having to
>> agree on one level before knowing if there's a mutually-acceptable
>> mechanism at the next.  But stackable mechanisms don't work that way;
>> every possible stack has an OID, composed from the OID's of the
>> stacked mechanisms (see section 4.1 of
>> draft-ietf-kitten-stackable-pseudo-mechs-02.txt).  Then the entire
>> _stack_ is negotiated at once, as if it were a single mechanism.
>> This leads to an explosion of possible mechanism OID's, where it's
>> not entirely possible to predict what they all are, but is entirely
>> unreasonable to expect every combination to be named and registered.
>
> It sounds as though a server asked to use GS2-GQGFDSAGDSAF would have to
> recurse through all possible mechanism stack

Yes, but the SASL and GS2 implementation need not worry about this; all 
they should need to do is call GSS_Indicate_mechs(), whose result will 
include any composite mechanisms which are part of the default set.  Or, it 
may use GSS_Indicate_mechs_by_mech_attrs() to list mechanisms (including 
composite mechanisms) which have the attributes GS2 requires.

-- Jeff

Date: Thu, 8 Jan 2009 14:39:34 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: gs2 hashed oids
Sender: [email-masked]

Jeffrey Hutzelman writes:
> Stackable pseudo-mechanisms are not the same as multi-level negotiation.
> Multi-level negotiation is a problem because you end up having to 
> agree on one level before knowing if there's a mutually-acceptable 
> mechanism at the next.  But stackable mechanisms don't work that way; 
> every possible stack has an OID, composed from the OID's of the 
> stacked mechanisms (see section 4.1 of 
> draft-ietf-kitten-stackable-pseudo-mechs-02.txt).  Then the entire 
> _stack_ is negotiated at once, as if it were a single mechanism.  
> This leads to an explosion of possible mechanism OID's, where it's 
> not entirely possible to predict what they all are, but is entirely 
> unreasonable to expect every combination to be named and registered.

It sounds as though a server asked to use GS2-GQGFDSAGDSAF would have to 
recurse through all possible mechanism stack, encoding its OID as 
described in the kitten draft, hashing the resulting OID and comparing 
it against the desired name. Have I understood it correctly? (If not, 
then maybe it's nonobvious and should be explained in the GS2 
document.) If I have, then is that practical to recurse through the 
tree to find the mechanism?

Arnt

Date: Wed, 07 Jan 2009 18:16:25 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: gs2 hashed oids
Sender: [email-masked]

--On Tuesday, January 06, 2009 11:45:47 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

> I have two relatively mild concerns.
>
> The first concern is that the quality of non-standard GSS-API mechanisms
> are sometimes low, so it may open up for security problems in SASL if
> such mechanisms become available automatically.

This is a classic conceit.  Our concern that a particular non-standard 
mechanism might be insecure and make "our protocol" insecure is really 
completely irrelevant to the operator who uses that mechanism as his 
enterprise authentication mechanism.  Choice of mechanisms is a policy 
decision, and our role as protocol designers and implementors is not to set 
policy(*).

> I believe GS2 would
> need a security consideration that explains this.

I certainly think we need to say that the security of GS2 depends on the 
security properties of the particular underlying GSS-API mechanism used, 
and in what ways.  I don't think we need to or should say "WARNING: don't 
use non-standard mechanisms, because they are low quality" or similar FUD.

> Another concern is that the hashed OID makes the mechanism names harder
> to read for humans.  Ordinary users do chose between CRAM-MD5 and
> DIGEST-MD5 in mail applications today.  I would fear a usability review
> of a user interface that asks the users to chose between
> GS2-DT4PIK22T6EPV2PY and GS2-QLJHGJLWNPLNQRNK.

I would, too, if I had designed that user interface.  But given the choice 
between an implementation which showed a user-friendly mechanism name like 
"GSS-API with Kerberos" or "GSS-API with public keys" for mechanisms it 
knows about  and a hashed named for others, and one which showed names like 
"GS2-KERBEROS" or "GS2-SPKM" for mechanisms it knows about and doesn't let 
me use other mechanisms at all, I'd pick the former every time.

> There is a relatively easy solution to both these concerns: require that
> a name is registered with IANA for every GSS-API mechanism that is
> intended for use in SASL.  This is not too onerous IMHO, since the
> registration approach is First-Come-First-Serve.

It is, because random enterprises don't know or care about the IETF or IANA 
or want to have to register their private mechanisms with someone before 
they can use them.  It's also unnecessary to impose such a requirement.

\>> I think it is also important that we support dynamic stackable
>> pseudo-mechanisms, which means we need to have some solution for
>> mechanisms that cannot be registered.
>
> This seems like a separate issue, and potentially a problematic one: how
> do we avoid interop problems if mechanism X is negotiated under
> pseudo-mechanism Y or pseudo-mechanism Z or directly as X?  GS2 contains
> text about GSS-API mechanisms that negotiates other mechanisms now, but
> it seems the same concern also applies to pseudo-mechanisms.

Stackable pseudo-mechanisms are not the same as multi-level negotiation.
Multi-level negotiation is a problem because you end up having to agree on 
one level before knowing if there's a mutually-acceptable mechanism at the 
next.  But stackable mechanisms don't work that way; every possible stack 
has an OID, composed from the OID's of the stacked mechanisms (see section 
4.1 of draft-ietf-kitten-stackable-pseudo-mechs-02.txt).  Then the entire 
_stack_ is negotiated at once, as if it were a single mechanism.  This 
leads to an explosion of possible mechanism OID's, where it's not entirely 
possible to predict what they all are, but is entirely unreasonable to 
expect every combination to be named and registered.

-- Jeff

Date: Wed, 7 Jan 2009 12:45:46 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: gs2 hashed oids
Sender: [email-masked]

Simon Josefsson writes:
> Arnt Gulbrandsen <[email-masked]> writes:
>> Side note: Would it be permissible at all to use GSS-API 
>> experimenta/non-standard mechanisms in SASL without an X- prefix?
>
> The registration model described in RFC 4422 -- first come first 
> serve, with no technical review -- appears to permit almost any 
> mechanism in SASL, not just standardized mechanisms. I don't see a 
> difference between a GSS-API mechanism and a SASL mechanism in this 
> context.

OK

Arnt

From: Simon Josefsson <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: gs2 hashed oids
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 07 Jan 2009 12:19:11 +0100
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Simon Josefsson writes:
>> There is a relatively easy solution to both these concerns: require
>> that a name is registered with IANA for every GSS-API mechanism that
>> is intended for use in SASL. This is not too onerous IMHO, since the
>> registration approach is First-Come-First-Serve. There are X-* 
>> mechanism names for those who only wants to experiment.
>
> Side note: Would it be permissible at all to use GSS-API
> experimenta/non-standard mechanisms in SASL without an X- prefix?

The registration model described in RFC 4422 -- first come first serve,
with no technical review -- appears to permit almost any mechanism in
SASL, not just standardized mechanisms.  I don't see a difference
between a GSS-API mechanism and a SASL mechanism in this context.

/Simon

Date: Wed, 7 Jan 2009 12:06:36 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: gs2 hashed oids
Sender: [email-masked]

Simon Josefsson writes:
> There is a relatively easy solution to both these concerns: require 
> that a name is registered with IANA for every GSS-API mechanism that 
> is intended for use in SASL. This is not too onerous IMHO, since the 
> registration approach is First-Come-First-Serve. There are X-* 
> mechanism names for those who only wants to experiment.

Side note: Would it be permissible at all to use GSS-API 
experimenta/non-standard mechanisms in SASL without an X- prefix?

Arnt

Date: Wed, 7 Jan 2009 12:04:53 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: gs2 hashed oids
Sender: [email-masked]

Sam Hartman:
>>  Like Jeff Hutzelman I believe that it is important to be able to use=20
>>  a GSS-API mechanism in an application that has never heard of that=20
>>  mechanism.

(Why is this important?)

>>  We have significant evidence from SAP R3 this can be made to work=20
>>  and evidence from other applications that it is valuable in those=20
>>  contexts.

(Do tell?)

>>  I don't understand why people think this would be a bad idea, and=20
>>  would be happy to discuss.

1. Some application developers (quite a few in my experience =E2=80=94 I =
was a=20
library person in a past life) really don't want customers to use=20
something they haven't tested, and do not want to have unknown plugins=20
loaded at the customer or unknown mechanisms used there. Do you know=20
the old saying "fly what you test and test what you fly"?

2. Some application developers (mostly the same set as above, but not=20
quite) want the ability to reproduce what the customers are seeing.=20
Using something unknown to the application is problematic. (There are=20
also other problems, of course.)

Arnt

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: gs2 hashed oids
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 06 Jan 2009 23:45:47 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> Like Jeff Hutzelman I believe that it is important to be able to use a
> GSS-API mechanism in an application that has never heard of that
> mechanism.  We have significant evidence from SAP R3 this can be made
> to work and evidence from other applications that it is valuable in
> those contexts.  I don't understand why people think this would be a
> bad idea, and would be happy to discuss.

I have two relatively mild concerns.

The first concern is that the quality of non-standard GSS-API mechanisms
are sometimes low, so it may open up for security problems in SASL if
such mechanisms become available automatically.  I believe GS2 would
need a security consideration that explains this.

Another concern is that the hashed OID makes the mechanism names harder
to read for humans.  Ordinary users do chose between CRAM-MD5 and
DIGEST-MD5 in mail applications today.  I would fear a usability review
of a user interface that asks the users to chose between
GS2-DT4PIK22T6EPV2PY and GS2-QLJHGJLWNPLNQRNK.

There is a relatively easy solution to both these concerns: require that
a name is registered with IANA for every GSS-API mechanism that is
intended for use in SASL.  This is not too onerous IMHO, since the
registration approach is First-Come-First-Serve.  There are X-*
mechanism names for those who only wants to experiment.

However, this is merely my preference, and I don't feel strongly about
it.  I can live with hashed OIDs too, and will propose text for the
security considerations about this point.

> I think it is also important that we support dynamic stackable
> pseudo-mechanisms, which means we need to have some solution for
> mechanisms that cannot be registered.

This seems like a separate issue, and potentially a problematic one: how
do we avoid interop problems if mechanism X is negotiated under
pseudo-mechanism Y or pseudo-mechanism Z or directly as X?  GS2 contains
text about GSS-API mechanisms that negotiates other mechanisms now, but
it seems the same concern also applies to pseudo-mechanisms.

/Simon

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: gs2 hashed oids
Date: Tue, 06 Jan 2009 08:18:22 -0500
Sender: [email-masked]

Hi.  Nico, thanks for conveying my concern.  I'm really sorry that I
was so busy, but my consulting practice and the nomcom have taken up
all my time lately.

Like Jeff Hutzelman I believe that it is important to be able to use a
GSS-API mechanism in an application that has never heard of that
mechanism.  We have significant evidence from SAP R3 this can be made
to work and evidence from other applications that it is valuable in
those contexts.  I don't understand why people think this would be a
bad idea, and would be happy to discuss.  If I'm not sufficiently
responsive here please IM or send me personal mail.

I believe the same arguments apply to SASL and I definitely want to
use SASL mechanisms with applications that have not been intended to
use the mechanisms I've using.  I've done this with many applications
that use the Cyrus framework at least on the client and it has been
incredibly valuable in several deployments.

I think it is critical we avoid situations where a SASL mechanism has
multiple names.

I think the OS distributor arguments that Jeff brings up are quite
valid.

My strong preference is to keep hashed oid names.

If we cannot get a consensus to do that, we should fall back to
something.  I think it would be a very bad idea to give scram and
Kerberos names but not have a plan for how we can do the same in the
future.  If there are sufficient pressures that we cannot get
consensus behind hashed oid names, then we should get something that
will work long-term, not adopt a solution for scram and kerberos only
to have the fight again later with deployed code blocking our options.

So, my preference is to get consensus that hashed oid names are
acceptable.  If that fails, we should design a mechanism that will
allow us to assign names to mechanisms but that will handle the OS
distribution problems.

I think it is also important that we support dynamic stackable
pseudo-mechanisms, which means we need to have some solution for
mechanisms that cannot be registered.