Subject: Re: SCRAM and mechanism family

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 07 Dec 2008 20:55:53 -0500

--On Tuesday, November 25, 2008 10:59:25 AM -0500 Tom Yu <[email-masked]> 
wrote:

>
> Nicolas Williams <[email-masked]> writes:
>
>> On Tue, Nov 25, 2008 at 11:05:51AM +0100, Simon Josefsson wrote:
>>> Nicolas Williams <[email-masked]> writes:
>>>
>>> > Incidentally, there is the possibility of SASL/GS2 using names not
>>> > derived from hashing GSS mech OIDs, instead requiring registration
>>> > first.  I don't mind that, but it seems less flexible.
>>>
>>> Good point.  If we, for some reason, want to retain the SCRAM-HMAC-SHA-1
>>> SASL mech name even when SCRAM happens to be implemented as a GSS-API
>>> mechanism, and supported in SASL via GS2, we could add an exception in
>>> the GS2 document such as this:
>>>
>>>   GS2 implementations MUST use the SCRAM-HMAC-SHA-1 mechanism name for
>>>   the GSS-API mechanism with OID 1.3.6.1.4.1.11591.4.2.
>>
>> But we'd have so few exceptions that we might as well:
>>
>> a) list them all now for all known GSS mechs
>> b) create a registry or expand the existing IANA SASL mech name registry
>>
>> I don't think that'd suck, so why not?
>
> Are you suggesting abandoning the OID-hash-based mech names for GS2 SASL
> mechs?

I think this is a bad idea, because it requires a generic GS2 
implementation to know all of the possible mappings, which means that 
before you can use a new GSS-API mechanism as a SASL mechanism, you have to 
choose a name, register it, _and modify your SASL implementation_.  That 
means GS2 no longer has the ability to work with any GSS-API mechanism 
advertised by GSS_Indicate_mechs() and having the desired properties.

To me, this is a step backwards.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 07 Dec 2008 21:00:01 -0500

--On Tuesday, November 25, 2008 03:23:55 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

> Of course, for an operating system vendor/distro the preferred retort to
> that would be that packages delivering GSS mechanism plug-ins should
> update both, the gss mechglue and the sasl mechglue.

Yeah, that's great if you happen to be Sun and everything comes out of one 
giant tree where you can do coordinated commits and releases of changes. 
Out here in the real world, my SASL framework comes from one source, my 
GSS-API framework from another, and individual mechanisms may come from 
some other.  It's just not realistic for a package providing a GSS-API 
mechanism plugin to provide a new version of the SASL GS2 mechanism plugin 
to update the mappings.

But you knew that.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 07 Dec 2008 21:02:09 -0500

--On Tuesday, November 25, 2008 03:23:55 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

> What we could do, however, is assign non-hash-derived SASL/GS2 mech
> names to SCRAM and Kerberos V from the get-go, and use hash-derived
> SASL/GS2 mech names for all other GSS mechs.  Just like SASL/GS1 did,
> effectively.

What 'GSSAPI' did was a wart, designed to interoperate with an existing 
deployed base using code written on the basis of a flawed design which 
assumed that GSS-API was somehow magical and didn't require mechanism 
negotiation for interoperability.

Since we haven't repeated the original mistake, I don't see any particular 
reason to repeat the wart.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Dec 2008 01:59:05 -0500

--On Monday, December 08, 2008 12:27:09 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

> On Sun, Dec 07, 2008 at 09:00:01PM -0500, Jeffrey Hutzelman wrote:
>> > Of course, for an operating system vendor/distro the preferred retort
>> > to that would be that packages delivering GSS mechanism plug-ins should
>> Yeah, that's great if you happen to be Sun and everything comes out of
>> one  giant tree where you can do coordinated commits and releases of
>> changes.  Out here in the real world, my SASL framework comes from one
>> source, my  GSS-API framework from another, and individual mechanisms
>> may come from  some other.  It's just not realistic for a package
>> providing a GSS-API  mechanism plugin to provide a new version of the
>> SASL GS2 mechanism plugin  to update the mappings.
>>
>> But you knew that.
>
> You're being more than a tad unfair.  The rest of that message from
> which you quoted tore that argument down anyways.  Shall I read the rest
> of that message for you?  The very next paragraph said:
>
>> > But that's not enough.  There's no reason that a third party couldn't
>> > develop an application that implements its own SASL client framework,
>> > say, and there exist apps that do just that.  Such apps would have to
>> > be updated manually.  And that's not acceptable.

You appear to be making the argument that the OS/distro can't update 
third-party applications.  I was making the argument that third-party GSS 
mechanism providers can't even update the "official" SASL, and that in many 
systems even the "official" GSS-API mechanism packages may have that 
problem.

I believe that any of these arguments is sufficient to warrant keeping the 
abstraction and not requiring registation of SASL mechanism names for new 
GSS-API plugins.

> And the next and last one said:
>
> Why did you not bother reading that?

I did, and responded to it in a separate message.  I argued that what GS1 
did was a wart which should not be repeated (and yes, I think you _are_ 
proposing we do the same thing, though for completely different reasons). 
However, I don't feel all that strongly about that, and won't push if the 
rest of the WG feels otherwise.  I ask only this:  if we go down this 
route, make it crystal clear that "vanity" names MUST NOT be registered or 
used for new GSS-API mechanisms down the road, because doing so would 
result in two names for the same mechanism and thus create interoperability 
problems.  Clearly we understand this now; I'm more concerned about making 
sure the person who defines a new mech years from now understands it, too.

> Can we start making decisions on SCRAM and GS2 and start moving forward?

Moving forward sounds like a good plan.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Dec 2008 02:06:24 -0500

--On Monday, December 08, 2008 12:27:09 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

> You're being more than a tad unfair.

OK, maybe.  I don't mean to cast you in the role of the myopic OS vendor 
who assumes that because he can change the framework to reflect new 
mechanisms, everyone else can too (or doesn't matter).  And I'm not picking 
on Sun because you happen to work there -- I'm doing it because Solaris was 
about the only example I could think of offhand where doing such an update 
would actually work.  The Linux distros don't count; they tend to have the 
relevant pieces maintained by different people drawing from different 
upstream sources on unrelated release schedules.  There is one other vendor 
that comes to mind, but they don't ship SASL or GSS-API in their OS.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Dec 2008 00:27:09 -0600

You're being more than a tad unfair.  The rest of that message from
which you quoted tore that argument down anyways.  Shall I read the rest
of that message for you?  The very next paragraph said:

> >say, and there exist apps that do just that.  Such apps would have to be
> >updated manually.  And that's not acceptable.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Dec 2008 00:42:00 -0600

> negotiation for interoperability.

I'm not proposing the same thing.  Nor do I actually want what I
proposed.  I wrote the above because I thought there were complaints
from the pure-SASL crowd about the hash-of-OID mechname derivation.
It's called compromise, something we do in consensus-driven standards
setting organizations like this one.

Perhaps my perception was wrong, or if it's right then perhaps the issue
can be made to go away by convincing any holdouts.

> reason to repeat the wart.

I don't mind the wart if it helps resolve an issue of contention for
Chris and others, provided, of course, that the design mistakes of
SASL/GS1 are not repeated (I'm glad to see you agree that those are not
being repeated).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Dec 2008 01:16:15 -0600

> OK, maybe.  I don't mean to cast you in the role of the myopic OS vendor 

Thanks.  That's how I read it.

> that comes to mind, but they don't ship SASL or GSS-API in their OS.

Whereas I think that Linux distro maintainers play (or could, or should)
the same role that Sun does w.r.t. Solaris and could easily have such
updates (also, OpenSolaris is a lot more similar to Linux distros in
this respect that Solaris was, but that's just completely off-topic).
I'm not in favor of that though!  I think that's a mess that I don't
want Sun, nor the OpenSolaris community to have to deal with.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Dec 2008 01:11:58 -0600

> systems even the "official" GSS-API mechanism packages may have that 

Nope.  I was conveying Sam's argument (made in IM to me, and with which
I agreed), which is the same as yours: a registry of SASL/GS2 mechnames
would be quite problematic.

> abstraction and not requiring registation of SASL mechanism names for new 

Indeed.  That says nothing about whether a "wart" w.r.t. the SASL/GS2
mechname for SCRAM is acceptable or not.

> Moving forward sounds like a good plan.

Are the WG chairs keeping a list of open issues?  I'm confused by now as
to where who stands on what.  I bet I'm not the only one.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 08 Dec 2008 09:38:12 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> --On Tuesday, November 25, 2008 10:59:25 AM -0500 Tom Yu
> <[email-masked]> wrote:
>
>>
...
> before you can use a new GSS-API mechanism as a SASL mechanism, you
> have to choose a name, register it, _and modify your SASL
> implementation_.  That means GS2 no longer has the ability to work
> with any GSS-API mechanism advertised by GSS_Indicate_mechs() and
> having the desired properties.
>

Compared to what?  Today we have GSS-API which is Kerberos V5 only.
Being able to use non-krb5 GSS-API mechanisms in SASL would be a step
forward.

I disagree that explicit SASL names for GSS-API mechanisms will require
SASL implementation changes.  It can easily be merely configuration
changes, and the specification could even say so if this is a big
concern.  It seems that today some configuration changes are required to
introduce new GSS-API mechanisms too, so I don't follow the significance
of requiring GS2 to use hashed mech names.

Given the security/interoperability of many non-standard GSS-API
mechanisms, I'm worried about subjecting them to SASL applications
without some manual step.

However, I don't feel strongly about this point.  I hope the WG chairs
will summarize these discussions so it becomes easier for me as document
editor to add text that we'll hopefully be able to reach consensus on.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Dec 2008 17:40:45 +0000

Nicolas Williams wrote:

>On Tue, Nov 25, 2008 at 04:56:58PM +0100, Simon Josefsson wrote:
>  
>
>>Ah.  Good idea, I had either forgotten about it or never heard of it.  I
>>believe GS2 needs to add some text about this naming truncation.  The
>>majority of the text that defines SCRAM as a GSS-API mechanism should
>>likely go into the SCRAM document though.
>>    
>>
>Glad you like it.  At first Sam and I thought it was a fairly radical
>idea, but it grows on me, you don't object, and I doubt any of the
>SCRAM-as-pure-SASL-mech implementors would object (as if!).  It's simple
>enough and not really costly in terms of code for SCRAM-as-SASL/GS2
>implementors, so let's do it.
>  
>
That would be fine with me.

>Yes, much, if not all of the text that describes SCRAM-as-a-GSS-API-mech
>should be in the main SCRAM doc.
>  
>
I would welcome some text for the SCRAM document ;-).

---

From: Chris Newman <[email-masked]>
Date: Wed, 24 Dec 2008 16:10:52 -0800

I would consider this a positive change.

My code will have a table either way as I have no intention of passing 
arbitrary mechanisms through to a GSSAPI library of unknown code quality.

The number of authentication mechanisms that are actually useful to deploy 
for any given application are likely to be less than 5 most of the time and 
less than 10 in the worst case.  So however the table is done (code or 
config) it is trivial and worth the readability and security improvement, 
IMHO.

That said, I can live with the OID gunk in the mechanism name.  It's just 
syntax and the spec can always say "when you see 'GS2-GUNKYBLETCH', just 
read that as 'SCRAM HMAC SHA1'".

		- Chris

--On November 25, 2008 17:03:59 +0100 Simon Josefsson <[email-masked]> 
wrote:

> I think it depends on whether we want to abandon the GS2-* naming scheme
> altogether, and instead make the IANA SASL registry contain three
> columns:
>
> SASL mechanism name     Optional GSS-API mechanism OID    Reference
>
> CRAM-MD5                                                  RFC 2095
> SCRAM-HMAC-SHA-1        1.3.6.1.4.1.11591.4.2             RFC X
> ...
>
> Then you need to register a SASL mechanism name for every GSS-API
> mechanism you want to use in SASL via GS2 explicitly.
>
> GS2 would then be responsible for adding/removing the GSS-API specific
> OID-prefix in the first context token.  If a GS2 implementation does not
> know how to map between a particular OID and a SASL mech name, it gives
> up.
>
> I would prefer this approach.  I think the B32(TRUNC(SHA1(DER(OID))))
> approach is complex and ugly.
>
> /Simon
>
>

---

From: Chris Newman <[email-masked]>
Date: Wed, 24 Dec 2008 16:43:53 -0800

I want the bar for new SCRAM hash algorithms to require standards track 
processing.  It is my hope there will be few of them.  Preferably only 
SCRAM-SHA1 and SCRAM-NIST-HASH-WINNER for the foreseeable future.  The 
fewer code paths, the less opportunity for bugs and security 
vulnerabilities.

		- Chris

--On November 24, 2008 14:16:31 -0600 Nicolas Williams 
<[email-masked]> wrote:

>
> On Thu, Nov 20, 2008 at 08:00:22AM -0600, Alexey Melnikov wrote:
>> Simon Josefsson wrote:
>> > I brought this up on the jabber chat during the WG presentation of
>> > SCRAM, but it may be useful to repeat here to get feedback.
>> >
>> > Why does SCRAM needs to be defined as a mechanism family?
>>
>> It doesn't have to. But the document already defines any SCRAM mechanism
>> as if the hash function is pluggable. I personally like it like that and
>> I don't see a reason to change the document.
>
> I see Simon's issue as one bearing on: a) implementation details of
> pluggable SASL frameworks, b) how easy it is to create variants of SCRAM
> (just an IANA registration?  or a new RFC?).
>
> With regard to (b), for variants of SCRAM differing from the original
> SCRAM only in terms of which cryptographic algorithms are used, sure, an
> IANA registration might be sufficient, while still allowing
> registration-via-RFC- publication for variants that differ more
> significantly.
>
> As to (a), what component should be aware of and implement the
> cryptographic algorithm pluggability of a mechanism family?  The SASL
> mechglue?  Or the mechanism plug-ins to that mechglue?
>
> I believe that question answers itself.  It should be the mechanism.  I
> think it's possible that the SCRAM spec's wording might lead an
> implementor astray, so it's worth discussing this implementation design
> detail.
>
> Think of a framework with a config file, say, /etc/sasl/mechs, which
> lists {<mech-name>, <plug-in-object>}, with one plug-in object that
> implements all variants of SCRAM.  As long as the plug-in interfaces
> allow the plug-in to know the name of the mechanism it is implementing
> at any given time then a signle object can very well implement all
> variants of SCRAM.
>
> An alternative design that makes the framework implement SCRAM's
> pluggability might look like this: a config file, say, /etc/sasl/mech,
> that lists {<mech-name>, <plug-in-object>, <algorithm-options>}, where
> the mechglue passes the plug-in object a set of function/class/whatever
> for the <algorithm-options> references instead of the <mech-name>.  Such
> a design would clearly limit a plug-in implementor's freedom to
> implement variants of SCRAM with a single plug-in object should a future
> variant of SCRAM differ from today's in more ways than just which hash
> function algorithm it uses.
>
> As I said, I think the first implementation design is obviously the
> better one.
>
> The spec should not be written such that a SASL framework implementor
> could be misled into thinking that the second design is the correct one.
> Referring to SCRAM as a "mechanism family" might just do that.  But in
> practice I doubt it.
>
> Nico
> --
>
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 24 Dec 2008 21:06:03 -0500

> fewer code paths, the less opportunity for bugs and security

This is a strong argument for choosing not to implement new SCRAM hash 
algorithms that are not on the standards track.  However, in my opinion, it 
is not a good argument for setting a restrictive registration policy, 
thereby making it artificially hard for people to develop and deploy 
alternatives.

Recent experience with SSH has suggested that perhaps a single mandatory 
"good enough" algorithm is not sufficient in all cases.  I think I'd stop 
short of specifying two standards-track SCRAM variants with post-SHA1 
hashes and recommending that applications make both mandatory-to-implement, 
but I'd rather not end up in a situation where SCRAM-NIST-HASH-WINNER is 
the only viable choice.  Thus, I would prefer for it to be reasonably easy 
for someone to specify SCRAM-NIST-HASH-FINALIST-1, 
SCRAM-NIST-HASH-FINALIST-2, and so on.

Architecturally, I believe it is desirable for the SCRAM mechanism to be 
defined such that creating a variant with a new hash is as easy as dropping 
in a new hash function.  Besides making it easier to specify and implement 
new variants, this abstraction simplifies the analysis of SCRAM even if we 
never define another variant.  It is much easier to be sure we are doing 
something safe if we are clear that SCRAM does not depend on the structure 
of a particular hash, but rather only on the hash having the usual 
cryptographic properties.  Referring to a recent discussion on the SAAG 
list, that analysis would be even easier if we were explicit about which of 
those properties we are relying on.

At the same time, I think it is OK for the bar for defining a new variant 
to be as high as requiring a new document specifying the new variant in 
terms of the base SCRAM document and whatever hash function is used.  But 
it should be sufficient for _anyone_ to write this document; it shouldn't 
have to be an IETF standards-track document.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 27 Dec 2008 14:31:59 +0100

> arbitrary mechanisms through to a GSSAPI library of unknown code

FWIW, my code will have a similar table.  Exposing arbitrary GSS
mechanisms in SASL without some manual per-mechanism admin step seems
dangerous to me.

> The number of authentication mechanisms that are actually useful to
> deploy for any given application are likely to be less than 5 most of
> the time and less than 10 in the worst case.  So however the table is
> done (code or config) it is trivial and worth the readability and
> security improvement, IMHO.

+1.

> That said, I can live with the OID gunk in the mechanism name.  It's
> just syntax and the spec can always say "when you see
> GS2-GUNKYBLETCH', just read that as 'SCRAM HMAC SHA1'".

I agree.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 27 Dec 2008 14:43:26 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> algorithms that are not on the standards track.  However, in my
> opinion, it is not a good argument for setting a restrictive
> registration policy, thereby making it artificially hard for people to
> develop and deploy alternatives.

Well, sure, but I don't see anyone advocating that!  Registering a new
SASL mech is simple.  SCRAM cannot restrict what other mech names you
can register in the SASL framework.  If someone wants SCRAM with another
hash, she can register it as another SASL mechanism.

> Recent experience with SSH has suggested that perhaps a single
> mandatory "good enough" algorithm is not sufficient in all cases.  I
> think I'd stop short of specifying two standards-track SCRAM variants
> with post-SHA1 hashes and recommending that applications make both
> mandatory-to-implement, but I'd rather not end up in a situation where
> SCRAM-NIST-HASH-WINNER is the only viable choice.  Thus, I would
> prefer for it to be reasonably easy for someone to specify
> SCRAM-NIST-HASH-FINALIST-1, SCRAM-NIST-HASH-FINALIST-2, and so on.

I think we discussed which hash version to pick for SCRAM earlier.  The
three currently realistic alternatives are MD5, SHA-1 and SHA-256.
Applications people seemed to prefer MD5 and security people seemed to
prefer SHA-256.  In the earlier discussion it seemed like we could get
consensus on SHA-1.  I'm not sure we'll get a different outcome if we
re-open that discussion now.  Personally, I'd prefer SHA-256.

(I'm surprised that there haven't been a stronger push for non-HMAC
schemes though, since the cryptographic community appears to prefer
OMAC, UMAC or other more modern constructs.  But I don't feel strongly
about it to push the issue.)

> Architecturally, I believe it is desirable for the SCRAM mechanism to
> be defined such that creating a variant with a new hash is as easy as
> dropping in a new hash function.  Besides making it easier to specify
> and implement new variants, this abstraction simplifies the analysis
> of SCRAM even if we never define another variant.  It is much easier
> to be sure we are doing something safe if we are clear that SCRAM does
> not depend on the structure of a particular hash, but rather only on
> the hash having the usual cryptographic properties.  Referring to a
> recent discussion on the SAAG list, that analysis would be even easier
> if we were explicit about which of those properties we are relying on.

I agree, but I don't see how that requires writing SCRAM as a mechanism
family.

> At the same time, I think it is OK for the bar for defining a new
> variant to be as high as requiring a new document specifying the new
> variant in terms of the base SCRAM document and whatever hash function
> is used.  But it should be sufficient for _anyone_ to write this
> document; it shouldn't have to be an IETF standards-track document.

According to RFC 4422, IANA uses a FCFS basis to register mechanism
names.  It is not be possible for anyone to take the SCRAM document and
re-use contents of it due to the IETF copying conditions, but it is
possible for anyone to write a document that says "MYSCRAM is the same
as SCRAM [RFC XXXX] but replace SHA-1 with SHA-3.".  So what you appear
to want will be possible, and I don't see disagreement on that point.

/Simon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 28 Dec 2008 16:38:22 +0100

>>  GS2-GUNKYBLETCH', just read that as 'SCRAM HMAC SHA1'".

Maybe my brain is too small, but I have a real problem distinguishing 
GS2-d41d8cd98f00b204e9800998ecf8427e (yeah, upper case and blah, I 
know) from GS2-f80ba941f3ffee18823ff22724cacf98 and remembering which 
name refers to the mechanism I'm concentrating on, even if I only have 
to remember the names across a paragraph or two.

Show mercy with me ;)

Arnt

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 Dec 2008 10:02:06 +0100

Arnt Gulbrandsen <[email-masked]> writes:

>>>  That said, I can live with the OID gunk in the mechanism
>>> name. It's  just syntax and the spec can always say "when you see

I read Chris' entire mail that his _preference_ is to not to use the OID
gunk, however as a last resort he can live with it.  That is also my
opinion.  (Chris, if I mis-state your opinion, please correct me.)

Thus, I agree with your plea to use simple names for mechanisms.  Maybe
we are approaching rough consensus on this..?  Or at least the point
were we can actually test whether there is consensus.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Dec 2008 14:57:12 +0300

> mechanisms in SASL without some manual per-mechanism admin step seems
I think minimizing the number of configuration options exposed to client 
users would be a plus.
This might even have advantages for sysadmins trying to configure server 
side.

There are other ways of configuring allowed mechanism, for example by 
specifying required properties. Even though this approach doesn't always 
provide necessary granularity and assumes that all installed plugins are 
trusted.
>> security improvement, IMHO.
Adding the configuration table would be easy. But I am horrified at 
possible UI complexity.
>> GS2-GUNKYBLETCH', just read that as 'SCRAM HMAC SHA1'".
I agree with that part.

Despite my comments above I have to agree with Arnt that GS2-<stuff> is 
not easy to remember.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Dec 2008 19:12:34 -0500

--On Saturday, December 27, 2008 02:43:26 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

> Well, sure, but I don't see anyone advocating that!

That's precisely what Chris advocated:

]] I want the bar for new SCRAM hash algorithms to require standards track
]] processing.

> I think we discussed which hash version to pick for SCRAM earlier.

I think you must have rather completely misread what I said.  I'm not 
advocating reopening the question of what hash algorithm to pick for SCRAM. 
I'm arguing against raising the bar for defining new SCRAM variants, 
because I disagree with Chris that the ideal situation is to only ever have 
two SCRAM variants for the foreseeable future.

> I agree, but I don't see how that requires writing SCRAM as a mechanism

I don't recall saying it did.  In fact, I offered no opinion on the 
question of whether SCRAM should be defined as a mechanism family or not. 
That question is really entirely about registration policy; defining it as 
a family simply means reserving all names in the family for mechanisms 
related to this one in particular ways.

What I did say is that it's a good idea for the document to honor the 
abstraction around the hash function (and, for that matter, around HMAC), 
both to make it easier to define variants and to make the analysis easier.

Note that this helps not only the protocol in the abstract but 
implementations as well; if implementations of various protocols all use 
the same API to call hash functions, and implementations of those hash 
functions all export the same API, then analysis and testing of those 
implementations becomes much simpler, allowing applications to support a 
variety of hashes (or other kinds of algorithms) without an explosion in 
testing complexity.  This is important because again, I disagree with Chris 
that the answer to keeping complexity down is artificially keeping the 
number of cryptographic algorithms supported so small that if one of them 
is compromised, operators are forced to choose between seriously 
compromising security or seriously compromising interoperability.

> names.

Modified in any way we choose to modify it in a subsequent standards track 
document.

>  It is not be possible for anyone to take the SCRAM document and
> re-use contents of it due to the IETF copying conditions

It is possible for some people to do so, under some circumstances, and not 
possible for others to do so under other circumstances.  The specific 
question of what is and is not permissible is out of scope for this WG.

However, it's moot, because this is true:

> but it is
> as SCRAM [RFC XXXX] but replace SHA-1 with SHA-3.".

> So what you appear

It's possible today.  I'm not arguing for a change to the document, and I'm 
not arguing the question of whether to register SCRAM as a family or not. 
I'm specifically responding to Nico's comments about how that and the 
architecture of the document affects the architecture of implementations 
and to Chris's rather clearly expressed desire to set a high bar for 
defining new SCRAM variants.

-- Jeff

Date: Tue, 30 Dec 2008 19:12:34 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: Chris Newman <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

--On Saturday, December 27, 2008 02:43:26 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

> Well, sure, but I don't see anyone advocating that!

That's precisely what Chris advocated:

]] I want the bar for new SCRAM hash algorithms to require standards track
]] processing.

> I think we discussed which hash version to pick for SCRAM earlier.

I think you must have rather completely misread what I said.  I'm not 
advocating reopening the question of what hash algorithm to pick for SCRAM. 
I'm arguing against raising the bar for defining new SCRAM variants, 
because I disagree with Chris that the ideal situation is to only ever have 
two SCRAM variants for the foreseeable future.

> I agree, but I don't see how that requires writing SCRAM as a mechanism

I don't recall saying it did.  In fact, I offered no opinion on the 
question of whether SCRAM should be defined as a mechanism family or not. 
That question is really entirely about registration policy; defining it as 
a family simply means reserving all names in the family for mechanisms 
related to this one in particular ways.

What I did say is that it's a good idea for the document to honor the 
abstraction around the hash function (and, for that matter, around HMAC), 
both to make it easier to define variants and to make the analysis easier.

Note that this helps not only the protocol in the abstract but 
implementations as well; if implementations of various protocols all use 
the same API to call hash functions, and implementations of those hash 
functions all export the same API, then analysis and testing of those 
implementations becomes much simpler, allowing applications to support a 
variety of hashes (or other kinds of algorithms) without an explosion in 
testing complexity.  This is important because again, I disagree with Chris 
that the answer to keeping complexity down is artificially keeping the 
number of cryptographic algorithms supported so small that if one of them 
is compromised, operators are forced to choose between seriously 
compromising security or seriously compromising interoperability.

> names.

Modified in any way we choose to modify it in a subsequent standards track 
document.

>  It is not be possible for anyone to take the SCRAM document and
> re-use contents of it due to the IETF copying conditions

It is possible for some people to do so, under some circumstances, and not 
possible for others to do so under other circumstances.  The specific 
question of what is and is not permissible is out of scope for this WG.

However, it's moot, because this is true:

> but it is
> as SCRAM [RFC XXXX] but replace SHA-1 with SHA-3.".

> So what you appear

It's possible today.  I'm not arguing for a change to the document, and I'm 
not arguing the question of whether to register SCRAM as a family or not. 
I'm specifically responding to Nico's comments about how that and the 
architecture of the document affects the architecture of implementations 
and to Chris's rather clearly expressed desire to set a high bar for 
defining new SCRAM variants.

-- Jeff

Date: Tue, 30 Dec 2008 14:57:12 +0300
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Chris Newman <[email-masked]>, Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

I agree with that part.

Date: Mon, 29 Dec 2008 13:37:34 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

Simon Josefsson writes:
> I read Chris' entire mail
> ...

Yes. I read it all as "I'd like to do what Arnt wants, but not so much 
that I want another draft iteration". AFAICT that's almost everyone's 
opinion.

Arnt, a fanatic extremist

From: Simon Josefsson <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 29 Dec 2008 10:02:06 +0100
Sender: [email-masked]

/Simon

Date: Sun, 28 Dec 2008 16:38:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

Show mercy with me ;)

Arnt

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Chris Newman <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 27 Dec 2008 14:43:26 +0100
Sender: [email-masked]

/Simon

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 27 Dec 2008 14:31:59 +0100
Sender: [email-masked]

+1.

I agree.

/Simon

Cc: Hallvard B Furuseth <[email-masked]>, Philip Guenther <[email-masked]>, [email-masked], [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Chris Newman <[email-masked]>
Subject: Re: SCRAM "mandatory extensions"?
Date: Thu, 25 Dec 2008 05:18:33 -0800
Sender: [email-masked]

On Dec 24, 2008, at 4:56 PM, Chris Newman wrote:

>
> --On December 9, 2008 13:49:34 +0100 Hallvard B Furuseth <[email-masked] 
> > wrote:
>> Chris/Alexey, could you say something about all this?
>
> Personally, I don't think extension mechanisms within a SASL  
> mechanism serve much purpose and hope they're not used.

I generally agree.  The double negotiation is problematic, especially  
in protocols which only allow one authentication attempt per session.

It's really annoying when an mechanism is offered but then one  
discovers later that it's not offered with some key feature.

I much rather mechanism name be used to advertise and select variants  
of a mechanism (as separate mechanisms).

> I'd prefer SCRAM was a simpler mechanism without extensibility (a  
> new mechanism can be defined if necessary or we can fix critical  
> omissions when we go from SCRAM-SHA1 to SCRAM-NIST-HASH-WINNER).   
> But some people feel strongly about this issue and I don't.
>
> 		- Chris

Date: Wed, 24 Dec 2008 21:06:03 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Chris Newman <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

-- Jeff

Date: Wed, 24 Dec 2008 16:56:12 -0800
From: Chris Newman <[email-masked]>
Subject: Re: SCRAM "mandatory extensions"?
To: Hallvard B Furuseth <[email-masked]>, Philip Guenther <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

--On December 9, 2008 13:49:34 +0100 Hallvard B Furuseth 
<[email-masked]> wrote:
> Chris/Alexey, could you say something about all this?

Personally, I don't think extension mechanisms within a SASL mechanism 
serve much purpose and hope they're not used.  I'd prefer SCRAM was a 
simpler mechanism without extensibility (a new mechanism can be defined if 
necessary or we can fix critical omissions when we go from SCRAM-SHA1 to 
SCRAM-NIST-HASH-WINNER).  But some people feel strongly about this issue 
and I don't.

		- Chris

Date: Wed, 24 Dec 2008 16:43:53 -0800
From: Chris Newman <[email-masked]>
Subject: Re: SCRAM and mechanism family
To: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

		- Chris

> Referring to SCRAM as a "mechanism family" might just do that.  But in

Date: Wed, 24 Dec 2008 16:10:52 -0800
From: Chris Newman <[email-masked]>
Subject: Re: SCRAM and mechanism family
To: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

		- Chris

> approach is complex and ugly.

Date: Sun, 14 Dec 2008 17:40:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression  (Re: SCRAM and mechanism family)
Sender: [email-masked]

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 10 Dec 2008 07:16:20 +0100
To: [email-masked]
Subject: Re: sasl-gs2-10 notes
Sender: [email-masked]

Another reply to self.  I wrote:
> Section 3.2 seems to say very little.  How about replacing it with
> another paragraph in 3.1:
> 
>     "If the gs2 implementation stores a precomputed GSS-API OID -> SASL
>     name mapping, it will not need to implement Base32, SHA-1 and DER."

No, if it "stores a mapping {GSS-API OID => precomputed SASL name}".

> 3.3.  Example
> (...)
> SHA-1:      82 D2 73 25 76 6B D6 C8 45 AA ... (first 10 bytes hex)
> SHA-1 in binary:  10000010 11010010 01110011 00100101 01110110
>                   01101011 11010110 11001000 01000101 10101010

That left column reads as "the whole SHA-1 hash".  Make that

  SHA-1[0:10]: 82 D2 73 25 76 6B D6 C8 45 AA ... (first 10 bytes hex)
  In binary:        10000010 11010010 01110011 00100101 01110110
                    01101011 11010110 11001000 01000101 10101010

(Doesn't matter what "substring" syntax is used since the text describes
it anyway, just as long as it indicates to people who start at the
example that they need to look closer.)

-- 
Hallvard

Date: Tue, 09 Dec 2008 14:17:00 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

--On Tuesday, December 09, 2008 07:14:59 PM +0100 Hallvard B Furuseth 
<[email-masked]> wrote:

> Jeffrey Hutzelman writes:
>> --On Thursday, November 27, 2008 12:03:04 PM +0100 Hallvard B Furuseth
>> <[email-masked]> wrote:
>>> I don't understand the purpose of the SCRAM "m" (mandatory extensions)
>>> field.  The scram-07 draft says:
>>> (...)
>>> What's the server supposed to use this information for?
>>
>> Nothing.  Since no such extensions are currently described, the server
>> can't possibly support them, and so if the attribute is present,
>> authentication fails.  Period.
>>
>> The purpose of this field is to provide a mechanism to allow extensions
>> to  be defined in the future which cannot be safely ignored by servers
>> that do  not understand them.
>
> Is the idea that such an extension definition will contradict the "auth
> MUST fail" statement in this draft, so that auth with m= can succeed
> after all?  If so I suggest to phrase that differently in the draft.
>
> Also the "m" attribute would need a syntax of its own, so that
> different mandatory extensions can be defined independently of each
> other.  They can't all identify themselves as just "m".

The idea is that the first time we need a critical extension, we publish a 
specification which defines the syntax of "m" and how it works and replaces 
the "MUST fail" rule with a newer one.  That specification would be an 
update to SCRAM, and would become a normative reference for any critical 
extension.  We could, of course, just include that in the base SASL spec, 
but the idea was to avoid spending time specifying it until we need it.

-- Jeff

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2008 19:44:36 +0100
To: [email-masked]
Subject: Re: sasl-gs2-10 notes
Sender: [email-masked]

I wrote:
> Base32-encode [RFC4648] the SHA-1 hash's first 10 bytes:
> (...)
> * Output as base-32 numbers using ASCII digits uppercase
>   "A"-"Z", "2"-"7" (0-25, 26-31).

That was confusing.  Trying again:
  * Output as base-32 numbers using digits A-Z 2-7 (%x41-%x5A %x32-%x37)
    for values 0-25 26-31.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2008 19:37:11 +0100
To: Philip Guenther <[email-masked]>
cc: [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

I wrote:
>Philip Guenther writes:
>> I see these as directly parallel to the LDAP concept of 'criticality' on 
>> controls.  A manadatory extension is like a critical control;
> 
> No.  An LDAP critical control only causes failure if it cannot be
> applied.

Sorry, I had not seen Jeffrey's message yet.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2008 19:14:59 +0100
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

Jeffrey Hutzelman writes:
>--On Thursday, November 27, 2008 12:03:04 PM +0100 Hallvard B Furuseth 
><[email-masked]> wrote:
>> I don't understand the purpose of the SCRAM "m" (mandatory extensions)
>> field.  The scram-07 draft says:
>> (...)
>> What's the server supposed to use this information for?
> 
> Nothing.  Since no such extensions are currently described, the server 
> can't possibly support them, and so if the attribute is present, 
> authentication fails.  Period.
> 
> The purpose of this field is to provide a mechanism to allow extensions to 
> be defined in the future which cannot be safely ignored by servers that do 
> not understand them.

Is the idea that such an extension definition will contradict the "auth
MUST fail" statement in this draft, so that auth with m= can succeed
after all?  If so I suggest to phrase that differently in the draft.

Also the "m" attribute would need a syntax of its own, so that
different mandatory extensions can be defined independently of each
other.  They can't all identify themselves as just "m".

> To do that, there must be a field which all servers _do_ (MUST)
> understand, at least enough to know it means there is something going
> on they do not understand.

True, but the placement of an unknown extension in front of
client-first-message / server-first-message in the syntax is suffixient
to force a syntax error.  An "m=" attribute is not necessary for that.

Well, I guess the draft should explicitly say that syntax error should
cause auth failure.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2008 18:14:45 +0100
To: [email-masked]
Subject: sasl-gs2-10 notes
Sender: [email-masked]

Some notes about draft-ietf-sasl-gs2-10.txt.
I've only glanced at RFC 2743 (GSS-API), so some notes probably
translate to "please clarify/insert a reference to a GSS-API concept".

> 3.  Mechanism name
> 3.1.  Generating SASL mechanism names from GSS-API OIDs

Please split this up a bit.  At least:

>    The SASL mechanism name for a GSS-API mechanism is

     derived from the GSS-API mechanism's Object Identifier (OID).
     <p>
     It is

>    the concatenation
>    of the string "GS2-" and the Base32 encoding [RFC4648] (with an upper
>    case alphabet) of the first ten bytes of the binary SHA-1 hash
>    [FIPS.180-1.1995] string computed over the ASN.1 DER encoding
>    [ITU.X690.1994], including the tag and length octets, of the GSS-API
>    mechanism's Object Identifier. 

     <p>

>    The Base32 rules on padding
>    characters and characters outside of the base32 alphabet are not
>    relevant to this use of Base32.

Please add a few words with the rationale for GS2 names.  I'm guessing:

     GSS-API represents OIDs in DER format.  The reason it is hashed is
     to make the name short enough for SASL's 20-character name limit.

>    If any padding or non-alphabet
>    characters are encountered, the name is not a GS2 family mechanism
>    name.

nor if the name is not 20 characters long.  Also
s/non-alphabet/non-alphanumeric/.  However I suggest to drop this
sentence since it follows from the definition.

> 3.2.  Computing mechanism names manually
>
>    The SASL mechanism name may be computed manually.

I'd rather not compute SHA-1 manually:-)  You mean it can be precomputed.

>    This is useful
>    when the set of supported GSS-API mechanisms is known in advance.  It
>    also obliterate the need to implement Base32, SHA-1 and DER in the
>    SASL mechanism.  The computed mechanism name can be used directly in
>    the implementation,

Section 3.2 seems to say very little.  How about replacing it with
another paragraph in 3.1:

    "If the gs2 implementation stores a precomputed GSS-API OID -> SASL
    name mapping, it will not need to implement Base32, SHA-1 and DER."

(Update the exact text to match the outcome of the "GSS init tok header
compression" discussion, which I'm not quite following yet.)

Though is "...and DER" true, or will the GSS-API implementation include
that anyway?

>    and the implementation need not concern itself
>    with that the mechanism is part of a mechanism family.

I dropped this from my suggested text since it's implicit in SASL:
A mechanism family is just a collection of names with a common prefix.
It has no other semantics to be concerned with.

> 3.3.  Examples

This is very verbose.  With so much text, there should be room for a
step-by-step description so one doesn't need to refer to the DER and
Base32 documents.  Delete example #1 instead, since that is least
complex.  (It doesn't include OID components >= 128.)

Suggestion:

3.2.  Algorithm to compute SASL name from GSS-API OID

Here is a step-by-step guide to compute the SASL mechanism name as
defined above.

Take the OID (Object Identifier) of the GSS-API mechanism.

DER-encode [ITU.X690.1994] the OID if you have it in textual form
(e.g. "1.2.3456.789.0") instead of binary DER form:
* Replace the two first OID components with (40*1st component + 2nd
  component).
* Convert each resulting OID component to base 128 (digits %x00-%x7F),
  but add 128 to all but the last base-128 digit of each component.
* Concatenate the results, one byte per base-128 digit.
* Prepend a byte with the length of the above encoding if smaller than
  128.  Otherwise prepend 128 + number of length bytes, followed by
  the minimum possible number of base-256 length bytes, big-endian.
* Prepend %x06.  (DER tag for ASN.1's OBJECT IDENTIFIER type).

SHA-1 hash [FIPS.180-1.1995] the DER encoding.

Base32-encode [RFC4648] the SHA-1 hash's first 10 bytes:
* Consider them a stream of 80 bits.  (10 bytes*8 bits/byte.)
* Group these as 16 5-bit numbers.
* Output as base-32 numbers using ASCII digits uppercase
  "A"-"Z", "2"-"7" (0-25, 26-31).

Finally, prepend uppercase "GS2-".

3.3.  Example

The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
1.2.840.113554.1.2.2.  To derive the SASL mechanism name as in Section
3.2:

GSS-API mech OID:  1.2.840.113554.1.2.2
40*1st + 2nd:      42, 840,      113554,           1, 2, 2
Base 128:          42, 6+128 72, 6+128 119+128 18, 1, 2, 2
Tag,length: 06 09  2A  86    48  86    F7      12  01 02 02 (hex)
SHA-1:      82 D2 73 25 76 6B D6 C8 45 AA ... (first 10 bytes hex)
SHA-1 in binary:  10000010 11010010 01110011 00100101 01110110
                  01101011 11010110 11001000 01000101 10101010
As 5-bit numbers: 10000 01011 01001 00111 00110 01001 01011 10110
                  01101 01111 01011 01100 10000 10001 01101 01010
In decimal:       16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10
In base-32:       Q  L  J H G J L  W  N  P  L  M  Q  R  N  K
SASL mechanism name: "GS2-QLJHGJLWNPLMQRNK"

> 4.1.  SASL Messages
>    Messages shorter than or equal to 8 octets are invalid.  (The only
>    exception is the initial empty challenge sent by the server which may
>    be 0 octets.)

Remove the parenthesis since the information in them cannot be omitted.

> 4.2.2.  Server side
>    (**) - Use of server's principal names having
>    GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
>    where "service" is the service name specified in the protocol's
>    profile, and "hostname" is the fully qualified host name of the
>    server, is RECOMMENDED.

Please move the verb near the beginning of the sentence, so one can find
out earlier what's going on.  Something like this, though I should have
read GSS-API before suggesting a text.  Should it be e.g. "... to use
one of the server's ..."?

     It is RECOMMENDED to use server's principal names having
     GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format.
     "service" is the service name specified in the protocol's
     profile, and "hostname" is the fully qualified host name of the
     server.

>    Upon successful establishment of the security context (i.e.
>    GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
>    verify that the negotiated GSS-API mechanism is indeed the registered
>    one.  This is done by examining the value of the mech_type parameter
>    returned from the GSS_Accept_sec_context call.  If the value differ,
>    the SASL authentication MUST be aborted.

Make up your mind - SHOULD or MUST auth be aborted if values differ?
The current text implies that the server MUST NOT verify the mechanism
ID (e.g. to log any differences) unless it also aborts if they differ.

There is a similar MUST-MUST-MAY here:

> 4.3.2.  Client first GS2_Wrap input
>    The "client_maxbuf" field indicate the maximum protected buffer size
>    the client can receive in network byte order.  It MUST be 0 if the
>    client doesn't advertise support for any security layer, the server
>    MUST verify this.  Small values can make it impossible for the server
>    to send any protected message to the client, due to the overhead
>    added by GSS_Wrap, and the server MAY reject the authentication if it
>    detects this situation.

Since it MUST verify this, what MUST it do with a verification failure
if it does not follow the MAY and reject the authentication?

Also the "server_maxbuf" field in 4.3.3 (Server last GS2_Wrap input).

However, which security layer and advertised how?  I see no reference to
that in RFC 2743 (GSS-API) or this draft.  SASL has no feature to
advertise its security layers, though it says protocols should advertise
mechanisms.  Or are we talking about another security layer, like TLS?
Is this related to Section 9, Security Layer Bits?

> 4.3.2.  Client first GS2_Wrap input
>    The
>    authorization identity is not terminated with the NUL (U+0000)
>    character.

Why would it be?  If this is a reference to strings in the C language,
drop it.  These data are binary anyway, not text strings.

> 6.  Protocol Overview
>          S: After PROT_READY is set,
>             send [GSS_Accept_sec_context,
>                   GS2_Wrap(server_qops | server_maxbuf]

Missing ")".

> 7.  Authentication Conditions
>
>    Authentication MUST NOT succeed if any one of the following
>    conditions are true:

Please indicate which conditions are introduced in this section, and
which ones are duplicates of conditions elsewhere (and where they are
introduced).

Finally, the draft refers to the "protocol('s) profile".  Should that be
"SASL protocol requirements" referring to [SASL] Section 4?  That was
called "protocol profile" in the [SASL] drafts I remember, don't know
when it was changed.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2008 13:49:34 +0100
To: Philip Guenther <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

Philip Guenther writes:
>On Mon, 8 Dec 2008, Hallvard B Furuseth wrote:
>...
>> Sorry, I seem to have invited a bit confusion here.  SCRAM has two
>> extension fields: "mandatory-exts" (m=) which always return failure,
>> and "extensions" which are ignored if not recognized.
>> 
>> I don't know the reason why either was introduced in the draft.
> 
> I see these as directly parallel to the LDAP concept of 'criticality' on 
> controls.  A manadatory extension is like a critical control;

No.  An LDAP critical control only causes failure if it cannot be
applied.

A SCRAM manadatory extension always causes auth failure.  Looks like a
cheat to insert a "non-authentication operation" in SASL, which is why
I'm suggesting to make it a separate SASL mechanism.

Chris/Alexey, could you say something about all this?

> a plain extension is like a non-critical control.  So, how well has
> the concept of criticality worked out in LDAP?

LDAP criticality - "this LDAP operation MUST fail if the control is
unknown or fails" - is a necessary feature for some LDAP controls.  For
example the "assertion" control, which says that the LDAP request shall
not be run unless assertion about the related LDAP entry is verified.

> (I seem to recall some recent discussion on an LDAP mailing list about 
> issues in how criticality was actually specified.  Perhaps there's some 
> lesson that could be carried over into this document.)

LDAP criticality was originally poorly defined and too flexible, which
left quite a mess in some control specs.  It's been cleaned up in the
latest LDAP standard, but that doesn't fix those old control specs.

-- 
Hallvard

Date: Mon, 08 Dec 2008 15:41:39 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Philip Guenther <[email-masked]>, Hallvard B Furuseth <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

--On Monday, December 08, 2008 10:06:56 AM -0800 Philip Guenther 
<[email-masked]> wrote:

> It
> seems to me  that the question is whether the likelihood of an extension
> needing this  capability balances the cost of defining it

I think it does.  For critical extensions to work, there has to be a 
mechanism for signalling their presence to implementations which do _not_ 
support them.  You can't define the mechanism for labelling extensions as 
critical the first time you actually have one, because an implementation 
which does not support the new extension will then also not support the 
criticality mechanism.  Thus, the benefit of defining it up front, and more 
directly the cost of not doing so, is very high.

IIRC, we originally discussed the question of critical extensions and the 
need to define a criticality mechanism up front during the Dublin meeting. 
During that discussion, we made some compromises to keep down the cost of 
defining such a mechanism.  For example, we agreed to avoid specifying the 
syntax of the m= attribute, or its semantics beyond the requirement that 
authentication fail if it is present.  This gives us enough to insure that 
criticality works, while putting off as much as possible of the work of 
defining it until we actually need it.

> and whether
> there are  alternative ways of obtaining the same result.

Certainly there are.  For example, one could simply declare that all 
extensions are critical.  However, that doesn't really reduce the amount of 
work needed, because then if you ever want non-critical extensions you have 
to define a way of signalling that an extension is non-critical, and that 
signalling mechanism has to be in the base spec, or else things that don't 
understand a new extension also won't understand that it is non-critical.

I think we came to the conclusion that non-critical extensions are more 
likely than critical ones, and that specifying that a single specific 
attribute is critical without specifying its semantics was less work than 
making all extensions critical and then having to specify how the 
non-critical-extension atrtibute works (which I think you'd have to do up 
front).

-- Jeff

Date: Mon, 8 Dec 2008 10:06:56 -0800
From: Philip Guenther <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
cc: [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

On Mon, 8 Dec 2008, Hallvard B Furuseth wrote:
...
> Sorry, I seem to have invited a bit confusion here.  SCRAM has two
> extension fields: "mandatory-exts" (m=) which always return failure,
> and "extensions" which are ignored if not recognized.
> 
> I don't know the reason why either was introduced in the draft.

I see these as directly parallel to the LDAP concept of 'criticality' on 
controls.  A manadatory extension is like a critical control; a plain 
extension is like a non-critical control.  So, how well has the concept of 
criticality worked out in LDAP?  I see extensions RFCs that say that the 
client MUST set the criticality value to TRUE, so it appears it has been a 
necessary capability for extending LDAP in certain ways.  It seems to me 
that the question is whether the likelihood of an extension needing this 
capability balances the cost of defining it and whether there are 
alternative ways of obtaining the same result.

(I seem to recall some recent discussion on an LDAP mailing list about 
issues in how criticality was actually specified.  Perhaps there's some 
lesson that could be carried over into this document.)

Philip Guenther

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Dec 2008 14:07:59 +0100
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

Simon Josefsson writes:
>Hallvard B Furuseth <[email-masked]> writes:
>>> I'd prefer to avoid it, the SASL framework (and GSS-API
>>> too, for that matter) is extensible, no need to reproduce
>>> that in each mechanism too.
>>
>> Well, SASL limitations have come up, like my desire for a server
>> to be able to respond "for this user, try this mecanism/SCRAM
>> hash instead".  But that's not a mechanism-specific problem.
>> I think I'm gonna sit on the fence for that one.
>
> I thought more about a potential QUERY mechanism, and I see three
> problems with it.  I think the problems can be solved, but they reduce
> the neatness of the idea:

Sorry, I seem to have invited a bit confusion here.  SCRAM has two
extension fields: "mandatory-exts" (m=) which always return failure,
and "extensions" which are ignored if not recognized.

I don't know the reason why either was introduced in the draft.

I can see why the (non-mandatory) extensions can be useful, such
as a "try this mechanism instead" response which takes no extra
round trips.  Whether it's worth the extra complexity I don't know.

OTOH as far as I can tell, mandatory extensions which always fail
can be replaced with a separate QUERY mechanism which always fails.
E.g. both initial response and result could look something like this:

  <protocol-specific field - e.g. return status value> ":" <query type>
  ":" <mechanism> ":" <mechanism-independent> ":" <mechanism-specific>

Let all fields be optional - an absent mechanism might ask about SASL
status in general, and an invalid mechanism like "*" could ask about all
mechanisms.

Or the syntax could be more complex, e.g. allowing multiple queries, but
never mind for now.  I don't even know.  Since I didn't know why "m="
was introduced in the first place it seemed premature to go into much
detail about their replacement.

Anyway,

> 1) Authentication identities is a mechanism-specific concept.  However,
> this could be solved by simply saying that a server is responsible for
> querying all supported mechanisms whether the associated username is
> known or not, and then potentially list a number of SASL mechanisms that
> may support that particular username.

Depends on what the server is being queried about.
Remember that "m=" and thus "QUERY" is for as-yet unspecified
extensions, not just a single extension.

> 2) The list of mechanisms to return is not integrity protected.  This
> can be solved by saying that QUERY is only useful with TLS and when the
> eventually used SASL mechanism checks channel bindings.

More generally, QUERY could return any info at all which the SASL
implementation feels like chatting about, so for each extension/QUERY
type one needs to consider server policy for access/integrity
protection.

> 3) Should the QUERY mechanism pseudo-authentication step fail or
> succeed?

Fail.  The draft makes the right call here.  Consider access control
based on whether the user successfully authenticated, in a server which
does not now about QUERY in particular.  Instead the server has a policy
to only accept mechanisms of a configured strength.

If QUERY could succeeded, anyone could gain access.  Thus QUERY which
can succeed, like ANONYMOUS, must have strength zero - and would be
rejected by this server.

> What happens on SASL mechanism failures is somewhat
> implementation specific, and may be application protocol specific, so it
> needs to be discussed and tested how it works in practice.

My protocol-specific field in the message format above:-)

> I would be interested in helping documenting and implementing a QUERY
> mechanism though, if others are interested in it...

Note that I originally brought this up because I thought the feature was
misplaced in this draft, not because I have any particular need for it
at the moment.  The same goes for the extensions below, but just to have
mentioned it:

While the mandatory extensions seem like they can be moved to a separate
draft, the "optional" extensions (which are ignored if unrecognized)
cannot.  Yet I imagine the need for that is the same in SCRAM as in
other mechanisms.

To move them out of the draft so other mechanisms could use it, SASL
itself would have to be extended: Add a new set of optional messages
which can be passed along with the challenges and responses.

Also failed authentication can have an effect - resetting the connection
to anonymous in LDAP, or closing the connection in some applications.
The latter may make QUERY useless for per-connection info.  To fix that,
SASL would have to be extended to include non-authentication
response/challenge messages, which would not need to fail like QUERY.

-- 
Hallvard

To: [email-masked]
From:  Simon Josefsson <[email-masked]>
Subject:  Re: SCRAM and mechanism family
Date:  Mon, 08 Dec 2008 09:38:12 +0100
Lines: 50
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:sIGiM9NEyXOvBDAQpnlmD1DHjNM=
Sender: [email-masked]

...

/Simon

Date: Mon, 8 Dec 2008 01:16:15 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

Nico
-- 

Date: Mon, 8 Dec 2008 01:11:58 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

Nico
-- 

Date: Mon, 08 Dec 2008 02:06:24 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

-- Jeff

Date: Mon, 08 Dec 2008 01:59:05 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

-- Jeff

Date: Mon, 8 Dec 2008 00:42:00 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

Nico
-- 

Date: Mon, 8 Dec 2008 00:27:09 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

Nico
-- 

Date: Sun, 07 Dec 2008 21:21:08 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

--On Friday, November 28, 2008 02:23:43 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

>
> Nicolas Williams writes:
>> That was Sam's point -- the OS can provide SASL and GSS frameworks,
>> but there's no way to force third parties to use them.
>>
>> Now, one possible answer is: not our problem. But I don't like that
>> answer.
>
> I don't understand.
>
> What's the point of the hashed OIDs as names? I thought you were saying
> that their advantage is that they permit such applications to use new GS2
> mechanisms.
>
> In my experience that's pointless. Those applications explicitly don't
> want to use new mechanisms, so making it easy is pointless. You seem to
> agree, or am I misreading? But what's the point of the hashing then?

You seem to be saying that your experience is that every SASL application 
implementation throws modularity out the window and implements everything 
itself.  If that were true, then abstractions and modularity would be 
pointless, but it is _not_ true.  I use applications every day which depend 
on SASL framework libraries, which depend on GSS-API libraries, which 
depend on Kerberos libraries.  No one implements everything themselves.

The point of modularity in a SASL mechansim framework is to allow me to 
drop in new mechanisms.

The point of modularity in a GSS-API mechanism framework is to allow me to 
drop in new GSS-API mechanisms.  If you think no one does this, go ask 
Martin Rex to tell you about all the different GSS-API mechanisms his 
customers have come up with.  Make sure you have some time; it's a long 
list.

The point of OID-derived mechanism names is to allow me to drop in new 
GSS-API mechanisms and start using them with my SASL framework and 
applications, without having to write code or internet-drafts or know who 
IANA is or why I should care what they think about whether I can use my 
company's site-specific authentication mechanism to access my email server.

The argument you're making seems to be "abstractions are hard, modularity 
is hard, I want full control over what mechanisms users of my application 
use.  Therefore,  lets insure that no one can possibly produce a 
well-designed modular framework that respects abstraction boundaries, by 
deliberately breaking those boundaries in the specification."

I must say that I do not find that argument even slightly compelling.

-- Jeff

Date: Sun, 07 Dec 2008 21:13:13 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

--On Thursday, November 27, 2008 12:03:04 PM +0100 Hallvard B Furuseth 
<[email-masked]> wrote:

>
> I don't understand the purpose of the SCRAM "m" (mandatory extensions)
> field.  The scram-07 draft says:
>
>   - 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.
>
> What's the server supposed to use this information for?

Nothing.  Since no such extensions are currently described, the server 
can't possibly support them, and so if the attribute is present, 
authentication fails.  Period.

The purpose of this field is to provide a mechanism to allow extensions to 
be defined in the future which cannot be safely ignored by servers that do 
not understand them.  To do that, there must be a field which all servers 
_do_ (MUST) understand, at least enough to know it means there is something 
going on they do not understand.

The semantics of this attribute are quite simple and clearly described in 
the text you quoted:  Presence of this attribute... MUST cause 
authentication failure.  Period.

At some point in the future, we might publish a new version of the spec 
which defines new semantics for this field such that sometimes it can be 
present and not cause authentication failure.  But that's the future.

-- Jeff

Date: Sun, 07 Dec 2008 21:02:09 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

Date: Sun, 07 Dec 2008 21:00:01 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

But you knew that.

Date: Sun, 07 Dec 2008 20:55:53 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Tom Yu <[email-masked]>, Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

-- Jeff