Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 28 Nov 2008 14:23:43 +0100

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?

Maybe I'm dense. Sorry if so.

Arnt

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Nov 2008 15:06:42 +0100

Arnt Gulbrandsen <[email-masked]> writes:

> 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.
>
> 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?

I don't see it either.

I think there can even be security consequences in making it "too easy"
for GSS-API mechanisms to show up automatically as SASL mechanisms.

By requiring IANA registration, there is at least some minimal checks in
that some set of people have wanted to use a particular GSS-API
mechanism in SASL and went through the (hopefully simple) process to
register a SASL name.

Automatic export of GSS-API mechanisms into the SASL namespace seems
useful in theory, but I fail to see practical situations where it is
worthwhile.  There are not many GSS-API mechanisms out there, even fewer
are publicly standardized.

Proprietary GSS-API mechanisms can use a X-FOOBAR SASL mechanism name in
their own internal deployments too.  So if someone doesn't want to go
through the problem of IANA registration, they don't need too.  It is
only when interoperability is needed that you need a standardized SASL
mechname.

I don't object strongly to the hashed-mech-name idea.  But I would not
implement it -- instead I will hardcode the pre-computed GS2 SASL names
of known GSS-API mechanisms.

It would be interesting to hear from implementers that wants this
feature.

/Simon

To: [email-masked]
From:  Simon Josefsson <[email-masked]>
Subject:  Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Date:  Fri, 28 Nov 2008 15:06:42 +0100
Lines: 48
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:tJ2Tajt1AcPEeSLQnkRWPaNKduA=
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> 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.
>
> 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?

I don't see it either.

I think there can even be security consequences in making it "too easy"
for GSS-API mechanisms to show up automatically as SASL mechanisms.

By requiring IANA registration, there is at least some minimal checks in
that some set of people have wanted to use a particular GSS-API
mechanism in SASL and went through the (hopefully simple) process to
register a SASL name.

Automatic export of GSS-API mechanisms into the SASL namespace seems
useful in theory, but I fail to see practical situations where it is
worthwhile.  There are not many GSS-API mechanisms out there, even fewer
are publicly standardized.

Proprietary GSS-API mechanisms can use a X-FOOBAR SASL mechanism name in
their own internal deployments too.  So if someone doesn't want to go
through the problem of IANA registration, they don't need too.  It is
only when interoperability is needed that you need a standardized SASL
mechname.

I don't object strongly to the hashed-mech-name idea.  But I would not
implement it -- instead I will hardcode the pre-computed GS2 SASL names
of known GSS-API mechanisms.

It would be interesting to hear from implementers that wants this
feature.

/Simon

To: [email-masked]
From:  Simon Josefsson <[email-masked]>
Subject:  Re: SCRAM "mandatory extensions"?
Date:  Fri, 28 Nov 2008 14:24:17 +0100
Lines: 34
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:BS0NQIpur3iNYY1kZvj5Bs/tCGc=
Sender: [email-masked]

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:

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.

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.

3) Should the QUERY mechanism pseudo-authentication step fail or
succeed?  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.

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

/Simon

Date: Fri, 28 Nov 2008 14:23:43 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Cc: [email-masked]
Sender: [email-masked]

I don't understand.

Arnt

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 27 Nov 2008 14:03:14 +0100
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM "mandatory extensions"?
Sender: [email-masked]

Simon Josefsson writes:
> It looks like future extensibility to me.

Yes.  I should have said, I don't see what good the m= field does.
The draft has a field with optional extensions too.

> 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.

-- 
Hallvard

To: [email-masked]
From:  Simon Josefsson <[email-masked]>
Subject:  Re: SCRAM "mandatory extensions"?
Date:  Thu, 27 Nov 2008 13:04:29 +0100
Lines: 31
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:EI2OPiOj9TMFOXZRM1jtrDPF5uY=
Sender: [email-masked]

Hallvard B Furuseth <[email-masked]> writes:

> 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?  Return a "m="
> message to the client about what extensions it does support?  If so that
> could be useful, but for other mechanisms too.  So I think a new SASL
> mechanism QUERY would be better.  The parameters could include an
> optional mechanism name if one wants to ask about a specific mechanism.
>
> As for "m=" sent to the client - if it's in response to an "m=" from the
> client, that's covered by QUERY above.  If it's not - then it seems to
> me the server will have announced that it supports SCRAM, only to reply
> "no, not ordinary SCRAM" when the client tries to use it.  Seems to me
> that could be more cleanly achieved by defining another mechanism
> consisting of SCRAM + the extension.
>
> Am I missing something?

It looks like future extensibility to me.  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.

/Simon

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: SCRAM "mandatory extensions"?
Date: Thu, 27 Nov 2008 12:03:04 +0100
Sender: [email-masked]

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?  Return a "m="
message to the client about what extensions it does support?  If so that
could be useful, but for other mechanisms too.  So I think a new SASL
mechanism QUERY would be better.  The parameters could include an
optional mechanism name if one wants to ask about a specific mechanism.

As for "m=" sent to the client - if it's in response to an "m=" from the
client, that's covered by QUERY above.  If it's not - then it seems to
me the server will have announced that it supports SCRAM, only to reply
"no, not ordinary SCRAM" when the client tries to use it.  Seems to me
that could be more cleanly achieved by defining another mechanism
consisting of SCRAM + the extension.

Am I missing something?

-- 
Hallvard

Date: Wed, 26 Nov 2008 12:35:45 -0500
From: John C Klensin <[email-masked]>
To: Simon Josefsson <[email-masked]>, Paul Smith <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
Sender: [email-masked]

--On Wednesday, 26 November, 2008 17:52 +0100 Simon Josefsson
<[email-masked]> wrote:

> Paul Smith <[email-masked]> writes:
> 
>> CRAM-MD5 makes it a lot harder for MITM attacks than plain
>> text over an unverified TLS link does. While plain text over
>> TLS does stop attacks from 'eavesdroppers' it does nothing
>> for MITM attacks in most cases.
> 
> I hesitated to correct John about this, but if similar claims
> are repeated, I think we need to establish that CRAM-MD5 does
> not help against an MITM.

You can correct me any time you like, especially when I use
imprecise language.

To oversimplify somewhat, there are several possible attacks
that some people might describe in MITM terms.   One involves
impersonating the client and its credentials.   Without getting
into a debate about which Challenge-Response (CR) mechanism is
better than others, CR provides some protection against that
type of attach.  Another involves impersonating the server to
the client.  CR provides some protection there too.  And, in
both cases, it provides that protection even without
cryptography in general and session privacy protection in
particular.

Because session or link encryption (or the equivalent) are not
intrinsic to any CR method, they provide no protection against
session interception, especially of the passive data recording
(e.g., wiretapping) variety.  If the MITM attacker intends to do
anything more active, periodically reissuing the challenge can
make her life considerably more difficult although certainly not
impossible.

> CRAM-MD5 does not provide session security.  Thus an MITM can
> simply wait after the correct user has authenticated, and then
> hijack the session.  The attacker then has full access to the
> users' account.

As long as the MITM has the ability to do that, certainly yes.
To the extent to which the tools available to an MITM involve
hijacking by diversion of sessions at setup time, no.  And,
again depending on repeated challenge patterns and the nature of
the underlying application protocol, the MITM may be able to
monitor the transaction stream but may have only limited ability
to issue its own commands to the server and account.     Let's
remember that CR mechanisms, especially when used alone, have
never been legitimately considered as complete security
solutions, only as possibly-decent authentication ones when the
alternative is "nothing".  Conversely, let's not trick ourselves
into believing that all MITM attackers have access to seize any
connection, control the network, and fully operate any link they
can gain access to.

> The conclusion is that CRAM-MD5 needs TLS to protect against
> MITM's.

It needs properly authenticated TLS or some other session or
link encryption mechanism.   Without the "properly
authenticated" part, the MITM is free to divert the connection
and simply simulate the server.   And, of course, DNS attacks to
arrange such diversions are the easiest of MITM attacks to
arrange.  

> I believe TLS + CRAM-MD5 is better than TLS + PLAIN.  With TLS
> + CRAM-MD5, the MITM at least does not learn the long-term
> secret to set up new sessions.

And, with properly authenticated TLS (or
equally-well-authenticated IPSEC), the risks are further reduced
because one then has host-to-host protection of the data stream
and user-to-account authentication to use as the basis for
authorization.   Of course, a symmetric CR model would be even
better, if one could get it deployed.

Once again, I'm not trying to defend CRAM-MD5, or any other CR
mechanism, as either session security or as a really strong
authentication method.  I do contend that, as an authentication
mechanism, it is significantly better than nothing.  I also
believe that the evidence so far about the security differences
among CR mechanisms is that we need a lot more analysis of
operational risks  --not just analysis of how one technique
might be slightly better than another-- to justify trying to
discard (or recommend that people stop using) one method that is
widely deployed in favor of one that is still untested in
practice.

I also recommend against getting two hung up on CR+TLS as a
requirement, not because it isn't a good idea, but because we
have a bunch of other link and session encryption methods
available to us that may provide effective session security at
least as good as TLS (especially weakly-authenticated TLS), and
because, as far as I know, we have never demonstrated that
double encryption is desirable in the general case.  Telling
folks that CR doesn't really offer string protection without
pre-established session encryption is one thing; insisting on
TLS is something else entirely.

    john

From: Simon Josefsson <[email-masked]>
To: Paul Smith <[email-masked]>
Cc: John C Klensin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 26 Nov 2008 17:52:44 +0100
Sender: [email-masked]

Paul Smith <[email-masked]> writes:

> CRAM-MD5 makes it a lot harder for MITM attacks than plain text over an
> unverified TLS link does. While plain text over TLS does stop attacks
> from 'eavesdroppers' it does nothing for MITM attacks in most cases.

I hesitated to correct John about this, but if similar claims are
repeated, I think we need to establish that CRAM-MD5 does not help
against an MITM.

CRAM-MD5 does not provide session security.  Thus an MITM can simply
wait after the correct user has authenticated, and then hijack the
session.  The attacker then has full access to the users' account.

The conclusion is that CRAM-MD5 needs TLS to protect against MITM's.

I believe TLS + CRAM-MD5 is better than TLS + PLAIN.  With TLS +
CRAM-MD5, the MITM at least does not learn the long-term secret to set
up new sessions.

/Simon

Date: Wed, 26 Nov 2008 10:42:23 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

On Wed, Nov 26, 2008 at 11:05:18AM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >Now, you can expect GSS mechanisms packaged and delivered by that 
> >operating system's maintainers to update the GSS-API library's 
> >mechanism registration and the SASL library's, but you can't expect 
> >them to update your application's gsasl mechanism registration.
> 
> If my experience is anything to go by (FWIW I was a library person in a 
> past life), then you also can't expect such application vendors to want 
> to use new mechanisms.
> 
> Many of our customers who shipped private copies of libraries, and they 
> generally wanted to use only what was in them, not anything more. For 
> good reason.

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.

> >That was the example Sam gave me. I think it's quite likely to happen. 
> >I think it will be best to avoid it (i.e., Sam convinced me that at 
> >least all future GSS-API mechanisms should have SASL/GS2 names 
> >derived from their OIDs). Sam did propose an alternative: extend the 
> >GSS-API to provide a function for looking up a GSS mechanism's 
> >registered SASL/GS2 name, but I don't think anyone will be 
> >enthustiastic about that.
> 
> I don't see a lot of enthusiasm for the hashed names either.

Ah, see, I knew that.  But a choice still has to be made.

Date: Wed, 26 Nov 2008 16:30:12 +0000
From: Paul Smith <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
Sender: [email-masked]

John C Klensin wrote:
> I would certainly agree with that conclusion about clear-text
> over TLS if it were substantiated.  However, in a world in which
> typical certs for mail servers seem to be either self-signed (or
> certified on the basis of email address dialogues or domain name
> ownership), in which attacks on the DNS are well-known and the
> proper response to "Bind 8 is dead" may be "before or after Bind
> 4?", methods based on challenge-response may have one advantage
> that the I-D does not discuss, namely being independent of the
> certificate and DNS situation and relationships.  
>   
I think this is an important issue. So, I agree with John's 'plan of
attack' here.

CRAM-MD5 makes it a lot harder for MITM attacks than plain text over an
unverified TLS link does. While plain text over TLS does stop attacks
from 'eavesdroppers' it does nothing for MITM attacks in most cases.

I think one thing that some people seem to forget is that most people
who use email have no clue what TLS is, or how certificates work. For
plain text over TLS to be more secure (IMV) than CRAM-MD5, average users
would have to check mail server certificates, which they won't do.

- I can see the point in the draft about an a priori agreement about
character set, but is that really a big deal? 'sequence of ASCII
printable characters encoded in an octet with zero parity, with no
normalization' pretty much covers every case of passwords I've ever seen
anyone use - even in non-latin character set countries.

- No, CRAM-MD5 doesn't protect the user ID from eavesdroppers, but plain
text over TLS protects neither the user ID nor the password from a MITM
attack if the certificate isn't verified. CRAM-MD5 does protect the
password from both eavesdroppers and MITM attacks. Given that a large
number of mail providers use easily guessable user IDs (for ease of use
by users), I'm not sure how significant this 'weakness' in CRAM-MD5 is
*in real life*.

Now, in *some cases* I can see that plain text/TLS is better than
CRAM-MD5 - where the mail system is managed by competent techies, and
where email software is installed for users by those techies (so
certificates can be configured properly), but in the vast majority of
cases out there, I think the choice would be CRAM-MD5, plain text over
an unencrypted session, or plain text over a dubiously encrypted session
- which is better?

CRAM-MD5 has a large deployed server base out there. I don't think PLAIN
over TLS is a secure alternative, and SCRAM is still 'work in progress'
(and I remember the issues that we STILL have because we deployed SMTP
'AUTH' support before that was finalised ('AUTH=CRAM-MD5' vs 'AUTH
CRAM-MD5' anyone?)).

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

Date: Wed, 26 Nov 2008 11:05:18 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Cc: [email-masked]
Sender: [email-masked]

Nicolas Williams writes:
> On Tue, Nov 25, 2008 at 11:09:17PM +0100, Arnt Gulbrandsen wrote:
>>  What are some applications that implement their own SASL framework, 
>>  would need updates to support new SASL mechanisms, and would NOT 
>>  need updates to support new SASL/GS2 mechanisms?
>
> Today: none.
>
> However, suppose you've written some application using GNU SASL 
> (libgsasl) and you want to build and run it on some operating system 
> where the system-provided SASL library is, say, Cyrus SASL 
> (libsasl2). You may not want to port to libsasl2. You may want to 
> just ship your app linked with a private copy of libgsasl (which 
> you'd also ship along with your app).
>
> Now, you can expect GSS mechanisms packaged and delivered by that 
> operating system's maintainers to update the GSS-API library's 
> mechanism registration and the SASL library's, but you can't expect 
> them to update your application's gsasl mechanism registration.

If my experience is anything to go by (FWIW I was a library person in a 
past life), then you also can't expect such application vendors to want 
to use new mechanisms.

Many of our customers who shipped private copies of libraries, and they 
generally wanted to use only what was in them, not anything more. For 
good reason.

> That was the example Sam gave me. I think it's quite likely to happen. 
> I think it will be best to avoid it (i.e., Sam convinced me that at 
> least all future GSS-API mechanisms should have SASL/GS2 names 
> derived from their OIDs). Sam did propose an alternative: extend the 
> GSS-API to provide a function for looking up a GSS mechanism's 
> registered SASL/GS2 name, but I don't think anyone will be 
> enthustiastic about that.

I don't see a lot of enthusiasm for the hashed names either.

Arnt

Date: Tue, 25 Nov 2008 17:30:52 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

On Wed, Nov 26, 2008 at 12:16:16AM +0100, Simon Josefsson wrote:
> What kind of application would be able to take advantage of the new
> GSS-API mechanism?

CLient apps.

> Most SASL applications are rather tightly coupled with the SASL
> mechanism in order to do auditing (logging), authorization,
> leap-of-faith trust, and possibly other mechanism-specific operations.

Yes, but that's all server side.  Not that anything stops you from
writing a server app that uses GNU SASL on a system that ships with
Cyrus SASL, yet still use the system's GSS-API framework -- you'd just
not benefit from whatever integrated auditing, ... the system's SASL
framework provides.

> If an application or SASL library notices that an unknown GSS-API
> mechanism is available, I don't see how applications or SASL libraries
> could use that mechanism without additional APIs that doesn't exist
> today -- APIs such as "does this mechanism use X.509?" which would allow
> the application to do something reasonable with the X.509 credentials.

I think client apps would just work.  Much the same is true for simple
GSS apps.  E.g., I didn't have to add any mech-specific code to SunSSH to
make it use any GSS mech shipped with Solaris, though I did have to
hard-code SPNEGO's OID because SSHv2 w/ GSS is not allowed to use
SPNEGO and I had no better way to detect if a mechanism was SPNEGO.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 26 Nov 2008 00:16:16 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Nov 25, 2008 at 11:09:17PM +0100, Arnt Gulbrandsen wrote:
>> What are some applications that implement their own SASL framework, 
>> would need updates to support new SASL mechanisms, and would NOT need 
>> updates to support new SASL/GS2 mechanisms?
>
> Today: none.
>
> However, suppose you've written some application using GNU SASL
> (libgsasl) and you want to build and run it on some operating system
> where the system-provided SASL library is, say, Cyrus SASL (libsasl2).
> You may not want to port to libsasl2.  You may want to just ship your
> app linked with a private copy of libgsasl (which you'd also ship along
> with your app).
>
> Now, you can expect GSS mechanisms packaged and delivered by that
> operating system's maintainers to update the GSS-API library's mechanism
> registration and the SASL library's, but you can't expect them to update
> your application's gsasl mechanism registration.

What kind of application would be able to take advantage of the new
GSS-API mechanism?

Most SASL applications are rather tightly coupled with the SASL
mechanism in order to do auditing (logging), authorization,
leap-of-faith trust, and possibly other mechanism-specific operations.

If an application or SASL library notices that an unknown GSS-API
mechanism is available, I don't see how applications or SASL libraries
could use that mechanism without additional APIs that doesn't exist
today -- APIs such as "does this mechanism use X.509?" which would allow
the application to do something reasonable with the X.509 credentials.
Another API would be "does the mechanism uses passwords?", which would
allow the application and SASL library to treat it similar to existing
password mechanisms.

While nice in theory, I'm yet to be convinced that automatic support for
unknown GSS-API mechanisms in applications is something that is even
close to becoming a reality.

/Simon

Date: Tue, 25 Nov 2008 16:38:18 -0600
From: Nicolas Williams <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

On Tue, Nov 25, 2008 at 11:09:17PM +0100, Arnt Gulbrandsen wrote:
> What are some applications that implement their own SASL framework, 
> would need updates to support new SASL mechanisms, and would NOT need 
> updates to support new SASL/GS2 mechanisms?

Today: none.

However, suppose you've written some application using GNU SASL
(libgsasl) and you want to build and run it on some operating system
where the system-provided SASL library is, say, Cyrus SASL (libsasl2).
You may not want to port to libsasl2.  You may want to just ship your
app linked with a private copy of libgsasl (which you'd also ship along
with your app).

Now, you can expect GSS mechanisms packaged and delivered by that
operating system's maintainers to update the GSS-API library's mechanism
registration and the SASL library's, but you can't expect them to update
your application's gsasl mechanism registration.

That was the example Sam gave me.  I think it's quite likely to happen.
I think it will be best to avoid it (i.e., Sam convinced me that at
least all future GSS-API mechanisms should have SASL/GS2 names derived
from their OIDs).  Sam did propose an alternative: extend the GSS-API to
provide a function for looking up a GSS mechanism's registered SASL/GS2
name, but I don't think anyone will be enthustiastic about that.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 25 Nov 2008 23:43:19 +0100
Sender: [email-masked]

John C Klensin <[email-masked]> writes:

> Folks,
>
> While I have no particular attachment to CRAM-MD5 -- Paul,
> Randy, and I created it as a service to the community -- I
> suggest that you consider this active _very_ carefully.

The WG has discussed this particular issue for several IETF meetings
now.  It seems difficult to come to consensus around the issue.

> Given all of that, I wonder if denouncing CRAM-MD5 as strongly
> as this document seems to is really appropriate.  Would it not
> be a lot more sensible and realistic to:
>
> 	(i) Publish an updated version of 2195 that reflects at
> 	more length on the security issues and warnings about
> 	them?  I note that, given the requirement for two
> 	interoperable implementations, this document could be
> 	published at Draft Standard and that there is _no_ bar
> 	to doing so under the procedures specified in RFC 2026.

I would support this path, and given the deployment believe it makes
some sense to do this, but others (Sam?) have said they would not
support a backwards compatible CRAM-MD5 on the standards track.

> 	(ii) Publish SCRAM and see if it gets any traction in
> 	practice.

+1.

/Simon

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 25 Nov 2008 23:37:23 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Nov 25, 2008 at 10:46:19PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> > 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.
>> 
>> Ok.  Then I don't think an IANA registry will work: how will you handle
>> negotiation of a future GSS-API mechanism X?  It won't be mentioned in
>
> You misunderstood.  I was saying what you say in option (2) below.

Okay, but my 2) does not involve an IANA registry, and my point was that
an IANA registry for the names that would need to be mentioned
explicitly in GS2 does not work due to the future-mechanism negotiation
problem.

I think an IANA registry is only useful (and even compatible) together
with 1).

>> I guess the options are:
>> 
>> 1) Never use hash-derived mech names.  Instead require that a SASL name
>> is registered for every GSS-API mechanism OID.
>> 
>> 2) Use hash-derived mech names for "other" GSS-API mechanisms, but
>> mention the exceptions of SCRAM and KRBV5 in the GS2 document.
>> 
>> 3) Always use hash-derived mech names.
>
>> Frankly, I don't see the benefit of 2).  It has all the complexity of
>> BOTH solutions and I don't see any advantages.
>
> It'd make SCRAM more palatable to pure SASL implementors, I suspect.

They aren't likely to use KRBV5, so let's reduce the list of explicit
mech's to mention explicitly to only SCRAM then.  If even that is
needed.

/Simon

Date: Tue, 25 Nov 2008 16:08:06 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: 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]

On Tue, Nov 25, 2008 at 10:46:19PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > 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.
> 
> Ok.  Then I don't think an IANA registry will work: how will you handle
> negotiation of a future GSS-API mechanism X?  It won't be mentioned in

You misunderstood.  I was saying what you say in option (2) below.

> I guess the options are:
> 
> 1) Never use hash-derived mech names.  Instead require that a SASL name
> is registered for every GSS-API mechanism OID.
> 
> 2) Use hash-derived mech names for "other" GSS-API mechanisms, but
> mention the exceptions of SCRAM and KRBV5 in the GS2 document.
> 
> 3) Always use hash-derived mech names.

> Frankly, I don't see the benefit of 2).  It has all the complexity of
> BOTH solutions and I don't see any advantages.

It'd make SCRAM more palatable to pure SASL implementors, I suspect.

Nico
-- 

Date: Tue, 25 Nov 2008 23:09:17 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

What are some applications that implement their own SASL framework, 
would need updates to support new SASL mechanisms, and would NOT need 
updates to support new SASL/GS2 mechanisms?

Anrt

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 25 Nov 2008 22:46:19 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Nov 25, 2008 at 10:09:32PM +0100, Simon Josefsson wrote:
>> I'll prepare text to achieve this in the GS2 document.  It will require
>> some additional IANA considerations, but that shouldn't be too onerous.
>
> Wait.
>
> Sam has an objection to not deriving SASL/GS2 mech names from the OID of
> the GSS mech.
>
> Sam argues that that change would require updating SASL frameworks when
> new GSS mechs become available.  And he's right.
>
> 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.
>
> 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.
>
> 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.

Ok.  Then I don't think an IANA registry will work: how will you handle
negotiation of a future GSS-API mechanism X?  It won't be mentioned in
the GS2 document, so an initial GS2 implementation would not be aware of
it, and thus will use the hash-derived mech name.  If there is an IANA
registry, and some other GS2 implementation comes along that knows about
the SASL mech name registered for X, it won't interoperate with the
other GS2 implementation.

I guess the options are:

1) Never use hash-derived mech names.  Instead require that a SASL name
is registered for every GSS-API mechanism OID.

2) Use hash-derived mech names for "other" GSS-API mechanisms, but
mention the exceptions of SCRAM and KRBV5 in the GS2 document.

3) Always use hash-derived mech names.

Frankly, I don't see the benefit of 2).  It has all the complexity of
BOTH solutions and I don't see any advantages.

Well, ok, one minor advantage with 2) is that you will save 10-15 bytes
or so on the initial context token.  But bandwidth optimization doesn't
warrant complexity of this magnitude without benchmarks illustrating
bandwidth usage is the bottle-neck, in my opinion.

/Simon

Date: Tue, 25 Nov 2008 15:23:55 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: 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]

On Tue, Nov 25, 2008 at 10:09:32PM +0100, Simon Josefsson wrote:
> I'll prepare text to achieve this in the GS2 document.  It will require
> some additional IANA considerations, but that shouldn't be too onerous.

Wait.

Sam has an objection to not deriving SASL/GS2 mech names from the OID of
the GSS mech.

Sam argues that that change would require updating SASL frameworks when
new GSS mechs become available.  And he's right.

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.

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.

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.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 25 Nov 2008 22:09:32 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> 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.
>
> Yes, much, if not all of the text that describes SCRAM-as-a-GSS-API-mech
> should be in the main SCRAM doc.

I'll prepare text to achieve this in the GS2 document.  It will require
some additional IANA considerations, but that shouldn't be too onerous.

/Simon

Date: Tue, 25 Nov 2008 10:14:04 -0600
From: Nicolas Williams <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

On Tue, Nov 25, 2008 at 10:59:25AM -0500, Tom Yu wrote:
> Are you suggesting abandoning the OID-hash-based mech names for GS2 SASL
> mechs?

I am.  I see that Simon likes that, and I suspect that Chris would be
ecstatic.

Nico
-- 

Date: Tue, 25 Nov 2008 10:13:06 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

On Tue, Nov 25, 2008 at 05:03:59PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > 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?
> 
> 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:

I am not a fan of hashing OIDs to make SASL mech names.

> 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
> ...

Yes.

> Then you need to register a SASL mechanism name for every GSS-API
> mechanism you want to use in SASL via GS2 explicitly.

Yes.  Registration rules should be light-weight.

> 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.

Right.

> I would prefer this approach.  I think the B32(TRUNC(SHA1(DER(OID))))
> approach is complex and ugly.

Me too.

Nico
-- 

Date: Tue, 25 Nov 2008 10:01:34 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: 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]

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.

Yes, much, if not all of the text that describes SCRAM-as-a-GSS-API-mech
should be in the main SCRAM doc.

Nico
-- 

Date: Tue, 25 Nov 2008 11:06:28 -0500
From: John C Klensin <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
Sender: [email-masked]

--On Monday, 24 November, 2008 14:30 -0800
[email-masked] wrote:

> A New Internet-Draft is available from the on-line
> Internet-Drafts  directories.
> This draft is a work item of the Simple Authentication and
> Security Layer Working Group of the IETF.
> 
> 	Title		: CRAM-MD5 to Historic
> 	Author(s)	: K. Zeilenga
> 	Filename	: draft-ietf-sasl-crammd5-to-historic-00.txt
> 	Pages		: 6
> 	Date		: 2008-11-24
> 	
> This document recommends the retirement of the CRAM-MD5
> authentication   mechanism, and discusses the reasons for
> doing so.  This document   recommends RFC 2195 and its
> predecessor, RFC 2095, be moved to   Historic status.

Folks,

While I have no particular attachment to CRAM-MD5 -- Paul,
Randy, and I created it as a service to the community -- I
suggest that you consider this active _very_ carefully.   In
particular (and playing the role of devil's advocate much more
than that of author):

* CRAM-MD5 was designed at a time when the IETF was campaigning
against clear-text passwords on the wire, as a "better than
nothing" alternative.  While its perceived strength has weakened
over the years, it may still have some value in that area.
More important, it did not require cryptography, which was
perceived as an important issue for places and circumstances
where cryptography was prohibited or significantly restricted.

* Empirically, CRAM-MD5 is quite widely deployed and
interoperable.  The claims in this document about the weakness
of the definition notwithstanding, the evidence on the ground is
that people have been able to make it work (possibly by
aggressive application of the robustness principle).  Replacing
it on a flag-day basis ("move this to Historic when SCRAM is
published") with a protocol that has not been similarly tested
and deployed seems to me to be unwise.

* The document appears to suggest that clear-text passwords over
TLS are more desirable than CRAM-MD5.   In a world in which

	 (i) all certificates were anchored in well-established
	and trustworthy CAs and based on more than "responds to
	email" or "has domain" and
	
	 (ii) an in-depth analysis had been done on the ability
	to use partially-known-plaintext attacks (based on the
	very predictable nature of the SMTP, POP, IMAP, etc.,
	session-initiation dialogues) on TLS and a conclusion of
	"no problems" reached

I would certainly agree with that conclusion about clear-text
over TLS if it were substantiated.  However, in a world in which
typical certs for mail servers seem to be either self-signed (or
certified on the basis of email address dialogues or domain name
ownership), in which attacks on the DNS are well-known and the
proper response to "Bind 8 is dead" may be "before or after Bind
4?", methods based on challenge-response may have one advantage
that the I-D does not discuss, namely being independent of the
certificate and DNS situation and relationships.  

* The previous effort to replace CRAM-MD5 with something else
involved an effort to deprecate it in favor of Digest-MD5 which
was argued to be much more secure, etc., etc.   That effort
fizzled out when it became clear that Digest-MD5 had its own set
of problems and that the marginal security benefits were
probably not worth the trouble.  I have not studied SCRAM, but,
absent an RFC-published specification and several years of
experience, I don't have significant reason to believe that, in
practice, it will offer much more marginal benefit over CRAM-MD5
than Digest-MD5 turned out to.   Trying to replace one mechanism
with another involves significant costs, especially to
interoperability as some systems select one of the methods and
others select other ones, so the advantages had better be
significant.

Given all of that, I wonder if denouncing CRAM-MD5 as strongly
as this document seems to is really appropriate.  Would it not
be a lot more sensible and realistic to:

	(i) Publish an updated version of 2195 that reflects at
	more length on the security issues and warnings about
	them?  I note that, given the requirement for two
	interoperable implementations, this document could be
	published at Draft Standard and that there is _no_ bar
	to doing so under the procedures specified in RFC 2026.
	
	(ii) Publish SCRAM and see if it gets any traction in
	practice.
	
	(iii) When, and only if, SCRAM actually does get
	significant deployment in practice, move CRAM-MD5 to
	Historic.

regards,
    john

To: Nicolas Williams <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
From: Tom Yu <[email-masked]>
Date: Tue, 25 Nov 2008 10:59:25 -0500
Lines: 26
Sender: [email-masked]

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?

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 25 Nov 2008 17:03:59 +0100
Sender: [email-masked]

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?

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: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 25 Nov 2008 16:56:58 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Nov 25, 2008 at 11:01:50AM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> 
>> > On Fri, Nov 21, 2008 at 06:06:10PM -0600, Chris Newman wrote:
>> >> --On November 20, 2008 22:33:00 +0100 Simon Josefsson <[email-masked]> 
>> >> wrote:
>> >> >The wire protocol changes to turn SCRAM into a GSS-API mechanism are
>> >> >minimal: just the OID-prefix on the first message.  And a section
>> >> >describing the GSS-API related semantics (prot-ready etc).
>> >
>> > Only if we go with compression of that OID (which we should), though the
>> > change then is slightly more involved, IIRC, but still in the realm of
>> > the trivial.
>> 
>> What do you mean by OID compression?
>
> Sam and I came up with an OID compression scheme for SASL/GS2 quite a
> while ago as a way to make sure that implementors of SCRAM-as-a-pure-
> SASL mech don't have to put on the wire that pseudo-ASN.1 header from
> RFC2743 on initial context tokens.  I thought we'd discussed it on the
> list and/or at IETF meetings.
>
> Basically: you know the OID from the SASL mech name so there's no need
> to put in that header.
>
> A SASL/GS2 client implementation based on the GSS-API can recognize and
> remove that header trivially.  (The code to do this exists in most every
> GSS-API mechglue implementation, of which there are several open-source
> ones.)
>
> A SASL/GS2 server implementation based on the GSS-API will be able to
> recover the OID from the SASL mech name (yes, the SASL mech name results
> from applying a one way function to the mech's GSS OID, but there's a
> very small set of GSS mech OIDs) and so will be able to re-create that
> header prior to calling GSS_Accept_sec_context().  (The code to
> create that headerexists in most every GSS-API mechglue implementation,
> ...)

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.

/Simon

Date: Tue, 25 Nov 2008 09:26:58 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

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?

Nico
-- 

Date: Tue, 25 Nov 2008 09:21:46 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: GSS init tok header compression (Re: SCRAM and mechanism family)
Sender: [email-masked]

On Tue, Nov 25, 2008 at 11:01:50AM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> 
> > On Fri, Nov 21, 2008 at 06:06:10PM -0600, Chris Newman wrote:
> >> --On November 20, 2008 22:33:00 +0100 Simon Josefsson <[email-masked]> 
> >> wrote:
> >> >The wire protocol changes to turn SCRAM into a GSS-API mechanism are
> >> >minimal: just the OID-prefix on the first message.  And a section
> >> >describing the GSS-API related semantics (prot-ready etc).
> >
> > Only if we go with compression of that OID (which we should), though the
> > change then is slightly more involved, IIRC, but still in the realm of
> > the trivial.
> 
> What do you mean by OID compression?

Sam and I came up with an OID compression scheme for SASL/GS2 quite a
while ago as a way to make sure that implementors of SCRAM-as-a-pure-
SASL mech don't have to put on the wire that pseudo-ASN.1 header from
RFC2743 on initial context tokens.  I thought we'd discussed it on the
list and/or at IETF meetings.

Basically: you know the OID from the SASL mech name so there's no need
to put in that header.

A SASL/GS2 client implementation based on the GSS-API can recognize and
remove that header trivially.  (The code to do this exists in most every
GSS-API mechglue implementation, of which there are several open-source
ones.)

A SASL/GS2 server implementation based on the GSS-API will be able to
recover the OID from the SASL mech name (yes, the SASL mech name results
from applying a one way function to the mech's GSS OID, but there's a
very small set of GSS mech OIDs) and so will be able to re-create that
header prior to calling GSS_Accept_sec_context().  (The code to
create that headerexists in most every GSS-API mechglue implementation,
...)

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 25 Nov 2008 11:05:51 +0100
Sender: [email-masked]

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.

/Simon

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 25 Nov 2008 11:01:50 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Fri, Nov 21, 2008 at 06:06:10PM -0600, Chris Newman wrote:
>> --On November 20, 2008 22:33:00 +0100 Simon Josefsson <[email-masked]> 
>> wrote:
>> >The wire protocol changes to turn SCRAM into a GSS-API mechanism are
>> >minimal: just the OID-prefix on the first message.  And a section
>> >describing the GSS-API related semantics (prot-ready etc).
>
> Only if we go with compression of that OID (which we should), though the
> change then is slightly more involved, IIRC, but still in the realm of
> the trivial.

What do you mean by OID compression?

> As for implementations, the more significant are the changes to go from
> meeting whatever requirements of a SASL implementation's plug-in SPI to
> meeting the requirements of a GSS-API implementation's plug-in SPI, plus
> -optionally- providing a true SASL/GS2 implementation.

Agreed, this will be the challenge.  I believe it is likely that
implementation feedback will result in some specification changes or new
specification further down the road.

/Simon

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt 
Date: Mon, 24 Nov 2008 14:30:01 -0800 (PST)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: CRAM-MD5 to Historic
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-crammd5-to-historic-00.txt
	Pages		: 6
	Date		: 2008-11-24
	
This document recommends the retirement of the CRAM-MD5 authentication
  mechanism, and discusses the reasons for doing so.  This document
  recommends RFC 2195 and its predecessor, RFC 2095, be moved to
  Historic status.

  [[Note to RFC Editor: please publish at same time that [SCRAM] is
  published.]]

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-to-historic-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-crammd5-to-historic-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Date: Mon, 24 Nov 2008 14:16:31 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

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
-- 

Date: Mon, 24 Nov 2008 14:01:55 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

On Thu, Nov 20, 2008 at 01:03:06PM +0100, 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 be.  In fact, it shouldn't be in that a SASL mechglue
implementation should not be aware of it, even though the implementation
of the SCRAM mechanisms may well share so much common code as to be make
it a "mechanism family."

I.e., the "family" thing should be an implementation detail, not a
detail that binds us to today's SCRAM design when we go add a new hash
tomorrow.

> If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
> obvious reason for defining SCRAM as a family, taking the current SCRAM
> document and replacing SHA-1 with SHA-256 is possible.

No need to copy the doc, just have a new one with a normative reference
to the old one, with the new one saying "use the new OID/name and
SHA-256 instead of SHA-1."

> The non-family approach has the benefit of making it simple to introduce
> improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
> necessary.

Absolutely.

> I think SASL mechanism families introduce complexity for little gain,
> but I'd be interested to understand why it was added here.

I agree.

Nico
-- 

Date: Mon, 24 Nov 2008 13:08:14 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

On Thu, Nov 20, 2008 at 04:24:21PM -0600, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >Alexey Melnikov <[email-masked]> writes:
> >>I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1
> >>with IANA.
> >>   
> >>
> >It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
> >and supported in SASL via GS2, the mechanism name registered with IANA
> >will be the GS2-* name, not SCRAM-HMAC-SHA-1.
> >
> That is correct.
> But I wanted to resolve all outstanding issues except for GS2 framing 
> and make the document self consistent.

I'm confused.  How does registering "SCRAM-HMAC-SHA-1" help with that?

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.

> >Have we given up on supporting SCRAM as a GSS-API mechanism?
> >
> No.

Good.

Date: Mon, 24 Nov 2008 13:05:40 -0600
From: Nicolas Williams <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

On Fri, Nov 21, 2008 at 06:06:10PM -0600, Chris Newman wrote:
> --On November 20, 2008 22:33:00 +0100 Simon Josefsson <[email-masked]> 
> wrote:
> >The wire protocol changes to turn SCRAM into a GSS-API mechanism are
> >minimal: just the OID-prefix on the first message.  And a section
> >describing the GSS-API related semantics (prot-ready etc).

Only if we go with compression of that OID (which we should), though the
change then is slightly more involved, IIRC, but still in the realm of
the trivial.

As for implementations, the more significant are the changes to go from
meeting whatever requirements of a SASL implementation's plug-in SPI to
meeting the requirements of a GSS-API implementation's plug-in SPI, plus
-optionally- providing a true SASL/GS2 implementation.

> If only it were that simple.  We're still evaluating doing SCRAM as GS2, 
> but it looks like it adds an extra redundant hash computation for both ends 
> and a bunch of cruft to every message.  I still think we should make it 
> concrete to see if the result is palatable, but I can't predict if we'll 
> get WG rough consensus on the result.

Simon was talking about what it would take to get a GSS mechanism out of
a SCRAM specification based on SCRAM-as-a-SASL/GS2 mechanism that is not
described primarily as a GSS-API mechanism to begin with.

Nico
-- 

Date: Fri, 21 Nov 2008 18:06:10 -0600
From: Chris Newman <[email-masked]>
Subject: Re: SCRAM and mechanism family
To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On November 20, 2008 22:33:00 +0100 Simon Josefsson <[email-masked]> 
wrote:
> The wire protocol changes to turn SCRAM into a GSS-API mechanism are
> minimal: just the OID-prefix on the first message.  And a section
> describing the GSS-API related semantics (prot-ready etc).

If only it were that simple.  We're still evaluating doing SCRAM as GS2, 
but it looks like it adds an extra redundant hash computation for both ends 
and a bunch of cruft to every message.  I still think we should make it 
concrete to see if the result is palatable, but I can't predict if we'll 
get WG rough consensus on the result.

		- Chris

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 21 Nov 2008 08:55:29 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

>>It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
>>and supported in SASL via GS2, the mechanism name registered with IANA
>>will be the GS2-* name, not SCRAM-HMAC-SHA-1.
>>
> That is correct.
> But I wanted to resolve all outstanding issues except for GS2 framing
> and make the document self consistent.

Great.  To help the SCRAM document to prepare a GS2 name, here is text I
prepared, based on similar text for GS2+Krb5.  Someone needs to check
the computations, but that can happen later on.

X.Y SASL Mechanism Name for SCRAM

   The GSS-API OID for SCRAM is 1.3.6.1.4.1.11591.4.2 and its DER
   encoding is (in hex) 06 09 2B 06 01 04 01 DA 47 04 02.  The SHA-1
   hash is 29 06 29 12 AB 25 83 CD 02 92 1B 4E 2D D8 6A 40 CD D0 5D C2.
   Convert the first ten octets to binary, and re-group them in groups
   of 5, and convert them back to decimal, which results in these
   computations:

   hex:
   29 06 29 12 AB 25 83 CD 02 92

   binary:
   00101001 00000110 00101001 00010010 10101011
   00100101 10000011 11001101 00000010 10010010

   binary in groups of 5:
   00101 00100 00011 00010 10010 00100 10101 01011
   00100 10110 00001 11100 11010 00000 10100 10010

   decimal of each group:
   5 4 3 2 18 4 21 11 4 22 1 28 26 0 20 18

   base32 encoding:
   F E D C S E V L E W B 4 2 A U S

   The last step translate each decimal value using table 3 in Base32
   [RFC4648].  Thus the SASL mechanism name for SCRAM is
   "GS2-FEDCSEVLEWB42AUS".

/Simon

Date: Thu, 20 Nov 2008 16:24:21 -0600
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1
>>with IANA.
>>    
>>
>It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
>and supported in SASL via GS2, the mechanism name registered with IANA
>will be the GS2-* name, not SCRAM-HMAC-SHA-1.
>
That is correct.
But I wanted to resolve all outstanding issues except for GS2 framing 
and make the document self consistent.

>Have we given up on supporting SCRAM as a GSS-API mechanism?
>
No.

>That would be bad news for me,
>I still see a long-term need for a password-based GSS-API mechanism.
>
>The wire protocol changes to turn SCRAM into a GSS-API mechanism are
>minimal: just the OID-prefix on the first message.  And a section
>describing the GSS-API related semantics (prot-ready etc).
>
>We could also let SCRAM move forward as a native SASL mechanism, write a
>separate short document that says SCRAM plus OID-prefix and some
>semantics is a password-based GSS-API mechanism.  The problem then is
>how to deal with native SCRAM vs SCRAM-via-GS2.
>  
>

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 20 Nov 2008 22:33:00 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1
> with IANA.

It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
and supported in SASL via GS2, the mechanism name registered with IANA
will be the GS2-* name, not SCRAM-HMAC-SHA-1.  Have we given up on
supporting SCRAM as a GSS-API mechanism?  That would be bad news for me,
I still see a long-term need for a password-based GSS-API mechanism.

The wire protocol changes to turn SCRAM into a GSS-API mechanism are
minimal: just the OID-prefix on the first message.  And a section
describing the GSS-API related semantics (prot-ready etc).

We could also let SCRAM move forward as a native SASL mechanism, write a
separate short document that says SCRAM plus OID-prefix and some
semantics is a password-based GSS-API mechanism.  The problem then is
how to deal with native SCRAM vs SCRAM-via-GS2.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 20 Nov 2008 22:24:56 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Arnt Gulbrandsen wrote:
>
>> One one hand, having a single name saves clutter. I know I can use
>> the same code for all SCRAM varieties if they're defined using the
>> same words in the same document.
>>
>> On another, how many varieties are expected in the foreseeable
>> future? 1? 2? A generic mechanism that covers one or two cases has
>> bad karma, and one that is meant to cover the unforeseeable future
>> in cryptography and computer security has really awful karma.
>>
>> So I think that overall maybe I agree with Simon.
>
> I wanted to write a small rant in reply ;-), but I've realized there
> might be a couple of related issues here:
>
> 1). Structure of the document - SCRAM currently written with an
> assumption that any hash function can be used with it
> 2). Definition of SCRAM-HMAC-SHA-1 and IANA registration.
>
> I am quite reluctant to change 1). Speaking personally I have plenty
> of of other things to do that I consider more important and I am not
> looking forward potentially creating more work for myself by
> hardcoding the hash name in various places of the document.

I have no objection to the current structure.  1) is good in that it
makes it easy to do a search-n-replace for SHA-1 with SHA-256 or SHA-3
when the need arise.

/Simon

To: [email-masked], [email-masked]
Subject: IETF73 SASL WG summary
From: Tom Yu <[email-masked]>
Date: Thu, 20 Nov 2008 16:00:09 -0500
Lines: 44
Sender: [email-masked]

Simple Authentication And Security Layer (SASL)
IETF73, Minneapolis, MN

Tuesday, November 18, 2008 at 1520-1720
=======================================

Chairs:

Tom Yu <[email-masked]>
Kurt Zeilenga <[email-masked]>

====================

Alexey Melnikov talks about SCRAM, describing resolved issues.
Discussion about modified GS2 framing for easier (non-GSS)
implementation of SCRAM.  Sam Hartman previously gave three possible
alternatives.  Several opinions that option 3 is best; no objections.
Suggestion to prepare examples of GS2+krb5 and GS2+SCRAM to help
readers understand the encoding.

Kurt has submitted an I-D (this morning!) proposing moving CRAM-MD5 to
Historic status, and updating its IANA registry entry to "OBSOLETE".
The intent is to abandon current WG document draft-ietf-sasl-crammd5.
Strong opinions that Kurt's document be held from publication until
SCRAM is published; no objections.  General agreement that the IANA
registry entry for "usage" should remain "LIMITED" and contain
references to both 2195 and Kurt's document.

Kurt talks about 4422bis.  Some discussion about normative downrefs.

Action items:

* Tom - WGLC Kurt's CRAM-MD5-to-historic document
* Alexey, Sam, et al. - update docs for GS2 encoding (and SCRAM)
* implementors - help write GS2 encoding examples

Milestones:

Nov 08 - Initial RFC4422 impl. report
Nov 08 - Reach consensus on CRAM-MD5 successor approach (and update
       	 milestones accordingly)
Dec 08 - WGLC RFC4422bis and implementation report I-D
Jan 09 - WGLC DIGEST-MD5 replacement I-D
Jan 09 - WGLC GS2 I-D

Date: Thu, 20 Nov 2008 11:20:32 -0600
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

Alexey Melnikov wrote:

> 1). Structure of the document - SCRAM currently written with an 
> assumption that any hash function can be used with it
> 2). Definition of SCRAM-HMAC-SHA-1 and IANA registration.
>
> I am quite reluctant to change 1). Speaking personally I have plenty 
> of of other things to do that I consider more important and I am not 
> looking forward potentially creating more work for myself by 
> hardcoding the hash name in various places of the document.
>
> Speaking of 2): we've actually discussed this during the WG meeting in 
> Minneapolis and the room consensus was to NOT register a family of 
> SCRAM-HMAC mechanisms, but only register SCRAM-HMAC-SHA-1 and add some 
> text that any further SCRAM-HMAC-* registrations would need to be done 
> on the case by case basis. I will update the document to match, unless 
> somebody has a strong objection.

I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1 with 
IANA.
I've also added the following text:

Note that even though this document defines a family of SCRAM-HMAC 
mechanisms,
it doesn't register a family of SCRAM-HMAC mechanisms in the SASL Mechanisms
registry. IANA is requested to prevent future registrations of SASL 
mechanisms
starting with SCRAM-HMAC- without consulting the SASL mailing list
<[email-masked]> first.

Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC SASL
mechanism MUST be explicitly registered with IANA and MUST comply with
SCRAM-HMAC mechanism naming convention defined in Section 4 of this 
document.

Comments?
(Is the text entirely consistent? I am wondering if instructing IANA not 
to register future SCRAM-HMAC mechanism without consulting the mailing 
list is in fact a registration of the new SCRAM-HMAC family of SASL 
mechanisms?)

Date: Thu, 20 Nov 2008 11:05:17 -0600
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> One one hand, having a single name saves clutter. I know I can use the 
> same code for all SCRAM varieties if they're defined using the same 
> words in the same document.
>
> On another, how many varieties are expected in the foreseeable future? 
> 1? 2? A generic mechanism that covers one or two cases has bad karma, 
> and one that is meant to cover the unforeseeable future in 
> cryptography and computer security has really awful karma.
>
> So I think that overall maybe I agree with Simon.

I wanted to write a small rant in reply ;-), but I've realized there 
might be a couple of related issues here:

1). Structure of the document - SCRAM currently written with an 
assumption that any hash function can be used with it
2). Definition of SCRAM-HMAC-SHA-1 and IANA registration.

I am quite reluctant to change 1). Speaking personally I have plenty of 
of other things to do that I consider more important and I am not 
looking forward potentially creating more work for myself by hardcoding 
the hash name in various places of the document.

Speaking of 2): we've actually discussed this during the WG meeting in 
Minneapolis and the room consensus was to NOT register a family of 
SCRAM-HMAC mechanisms, but only register SCRAM-HMAC-SHA-1 and add some 
text that any further SCRAM-HMAC-* registrations would need to be done 
on the case by case basis. I will update the document to match, unless 
somebody has a strong objection.

Date: Thu, 20 Nov 2008 09:36:12 -0600
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>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.
>>    
>>
>>>If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
>>>obvious reason for defining SCRAM as a family, taking the current SCRAM
>>>document and replacing SHA-1 with SHA-256 is possible.
>>>
>>>The non-family approach has the benefit of making it simple to introduce
>>>improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
>>>necessary.
>>>      
>>>
>>While this is true, I would hate to have a set of similar, but
>>slightly different mechanisms.
>>If this happens, I would be strongly in favour of changing the
>>mechanism prefix name.
>>    
>>
>For a non-family mechanism, there is no prefix, so changing the name
>from SCRAM-HMAC-SHA-1 to SCRAM-HMAC-SHA-256 will change the name and
>make them non-equivalent from a SASL library perspective.
>  
>
I was thinking more from a developer prospective: trying to remember 
subtile differences between similar things is hard.

>But I don't care strongly, I was trying to understand if there were a
>strong reason to do this rather than a preference.
>  
>
No strong reason.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 20 Nov 2008 16:19:47 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> 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.
>
>>If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
>>obvious reason for defining SCRAM as a family, taking the current SCRAM
>>document and replacing SHA-1 with SHA-256 is possible.
>>
>>The non-family approach has the benefit of making it simple to introduce
>>improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
>>necessary.
>>  
>>
> While this is true, I would hate to have a set of similar, but
> slightly different mechanisms.
> If this happens, I would be strongly in favour of changing the
> mechanism prefix name.

For a non-family mechanism, there is no prefix, so changing the name
from SCRAM-HMAC-SHA-1 to SCRAM-HMAC-SHA-256 will change the name and
make them non-equivalent from a SASL library perspective.

But I don't care strongly, I was trying to understand if there were a
strong reason to do this rather than a preference.

/Simon

Date: Thu, 20 Nov 2008 16:14:58 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

One one hand, having a single name saves clutter. I know I can use the 
same code for all SCRAM varieties if they're defined using the same 
words in the same document.

On another, how many varieties are expected in the foreseeable future? 
1? 2? A generic mechanism that covers one or two cases has bad karma, 
and one that is meant to cover the unforeseeable future in cryptography 
and computer security has really awful karma.

So I think that overall maybe I agree with Simon.

Arnt

Date: Thu, 20 Nov 2008 08:00:22 -0600
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: SCRAM and mechanism family
Sender: [email-masked]

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.

>If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
>obvious reason for defining SCRAM as a family, taking the current SCRAM
>document and replacing SHA-1 with SHA-256 is possible.
>
>The non-family approach has the benefit of making it simple to introduce
>improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
>necessary.
>  
>
While this is true, I would hate to have a set of similar, but slightly 
different mechanisms.
If this happens, I would be strongly in favour of changing the mechanism 
prefix name.

>I think SASL mechanism families introduce complexity for little gain,
>but I'd be interested to understand why it was added here.
>  
>

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 20 Nov 2008 13:03:06 +0100
Sender: [email-masked]

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?

If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
obvious reason for defining SCRAM as a family, taking the current SCRAM
document and replacing SHA-1 with SHA-256 is possible.

The non-family approach has the benefit of making it simple to introduce
improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
necessary.

I think SASL mechanism families introduce complexity for little gain,
but I'd be interested to understand why it was added here.

/Simon

Date: Tue, 18 Nov 2008 16:49:03 -0600
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-00.txt
To: [email-masked], [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Nit: the "changes since last version" doesn't mention the examples were 
altered.

		- Chris

--On September 9, 2008 12:45:01 -0700 [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Simple Authentication and Security Layer
> Working Group of the IETF.
>
> 	Title		: Simple Authentication and Security Layer (SASL)
> 	Author(s)	: A. Melnikov, K. Zeilenga
> 	Filename	: draft-ietf-sasl-4422bis-00.txt
> 	Pages		: 33
> 	Date		: 2008-8-31
> 	
> The Simple Authentication and Security Layer (SASL) is a framework
>    for providing authentication and data security services in
>    connection-oriented protocols via replaceable mechanisms.  It
>    provides a structured interface between protocols and mechanisms.
>    The resulting framework allows new protocols to reuse existing
>    mechanisms and allows old protocols to make use of new mechanisms.
>    The framework also provides a protocol for securing subsequent
>    protocol exchanges within a data security layer.
>
>    This document describes how a SASL mechanism is structured, describes
>    how protocols include support for SASL, and defines the protocol for
>    carrying a data security layer over a connection.  In addition, this
>    document defines one SASL mechanism, the EXTERNAL mechanism.
>
>    This document obsoletes RFC 4422 [[when approved]].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sasl-4422bis-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

Date: Tue, 18 Nov 2008 15:00:55 -0600
From: Chris Newman <[email-masked]>
Subject: Re: ABNF for the three cases of GS2
To: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

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

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.  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).

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

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'm don't understand how a SASL-SCRAM implementation is supposed to 
generate the <MIC-of-something> that GSS wrap does.  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 understand why two sets of channel bindings appear to be present, 
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.

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.

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

Escaping is used where necessary to avoid delim.  Other than not wanting a 
NUL delim due to the negative impact it has on debugging (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'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.  Regardless, it seems fine to me.

		- Chris

--On August 11, 2008 17:14:33 -0400 Sam Hartman <[email-masked]> 
wrote:
> I have put together ABNF for the three cases of GS2.
>
> A few notes:
>
> * I've punted on the whole OID issue at the beginning of the client
>   context token, defining a rule oidgunk that we'll need to figure
>   out.  That may involve negotiation with kitten.
>
> * I'm only providing Grammar for the parts of scram that SASL actually
>   uses.  Nico at least believes that the GSS-API mechanism should
>   provide sequencing.  I've included enough stuff that a pure SASL
>   mechanism would parse and ignore any such usage but have not
>   explored it.
>
> * There are two channel binding slots: one used by sasl in
>   scram-wrap-c2-inner and one used by non-SASL GSS-API applications in
> scram-c2-ctx
>
> * Most of the protocol is the same between all three cases.
>
> * This assumes that gs2 implementations are required to send the
>   mic/wrap token as soon as possible and that scram implementations
>   are required to be prot_ready when the client final message is sent.
>
> My current preference is a moderate preference for case 2.  I might
> like case 3 better if someone suggested a better way to determine the
> end of the non-context part.
>
> ; Some rules used by most of the grammars:
> gs2-to-be-protected = qop ["," maxbuf] ["," cbqop "," channelbinding]
>     ["," authzid] ["," 1*extension]
> qop = "qop=" qopvalue *( "+" qopvalue)
> qopvalue = "none" ; no security layer
>     / "integ" ; integrity protection
>     / "conf" ; confidentiality protection
>     / "cbgood" ; channel binding validated (server to client)
> maxbuf = "maxbuf=" digits
> cbqop = "cbqop=" qopvalue *( "+" qopvalue); QOPs that can be used if
> channel binding succeeds channelbinding = "cb=" base64
> authzid = "authzid=" base64
> extension = alphanum "=" *extensionchar
> extensionchar = value-char
> value-safe-char = %20-2B / %2D-3C / %3E-7E /
> 		  UTF8-2 / UTF-3 / UTF8-4
> 		  ;; UTF8-char except CTL, "=", and ",".
>
> value-char      = value-safe-char / "="
>
> ; The scram message parts that are constant across all three cases
> scram-c1-ctx = oidgunk username "," hash-list "," nonce
> ; oidgunk needs to be discussed on the list
> scram-s1-ctx = nonce "," hash-list "," salt "," iteration-count
> scram-c2-ctx = nonce "," gss-channel-binding "," proof
> ; gss-channel-binding is used  for non-SASL GSS-API
> ; but not for sasl apps
>
> scram-s2-ctx = verifier
>
> ; The content that gets wrapped is also constant across all three cases
> ; We don't consider it desirable that scram have a security layer.
> ; However it seems like scram is going to be enough of a gss-api mechanism
> ; that it will end up having a well-defined security layer.
> ; A SCRAM implementation with a full GSS-API  implementation MAY end up
> using  ; security layers and as such all SCRAM implementations need to
> parse qops  and ; maxbuf specifications. However pure SASL implementation
> can send a limited set  of responses ; and need not actually implement
> security layers
> ; The following rules demonstrate what will be carried between  two sasl-
> ; only scram  implementations that do not support security layers.
> ; the following two rules are the scram wrap from client to server and
> server to client saslscram-wrap-c2-inner = "qop=none" ["," "cbqop=none"
> "," channelbinding]      ["," authzid] [ "," 1*extension]
> saslscram-wrap-s2-inner = "qop=none" [ "+cbgood" ] [ "," 1*extension]
> ; and here are rules for what implementations must parse
> scram-wrap-c2-inner = qop ["," maxbuf ] ["," cbqop "," channelbinding]
> ["," authzid]      ["," 1*extension]
> ; The following rule could probably be simplified  as it's not clear
> maxbuf ; will ever appear in the s2 message unless you have two
> gs2-implementations  ; talking that have actually decided to use security
> layers
> scram-wrap-s2-inner = qop ["," maxbuf] ["," 1*extension]
>
>
> ; Grammar: case 1 two base 64 tokens
>
> gs2-message = gs2-context "," gs2-wrap
> gs2-context = base64 ; completely defined by the mechanism
> gs2-wrap = base64 ; processed by the mechanism but including the data
> from gs2-wrap-inner gs2-wrap-inner = gs2-to-be-protected
> scram-wrap = "mic="base64 ["," 1*extension] "," "d=" *octet ; MIC and
> integrity protected data ; So, that would make the SCRAM c2 message look
> like:
> scram-c2-wrap = "mic=" base64 [ "," 1*extension] ",d=" scram-wrap-c2-inner
> scram-s2-wrap = "mic=" base64 ["," 1*extension] ",d=" scram-wrap-s2-inner
> ; So, the client sends base64(scram-c1-ctx):null
> ; the server sends base64(scram-s1-ctx):nothing
> ; the client sends base64(scram-c2-ctx):base64(scram-c2-wrap)
> ; the server sends base64(scram-s2-ctx):base64(scram-s2-wrap)
>
> ; Grammar 2: Escaping
> ; null null encodes null
> ; null "," separates the context from wrap token
> ; Feel free to use a different escaping mechanism
> escape-char = %x01-ff / (%x00 %x00)
> escaped = 1*escape-char
> delim = %x00 ","
> gs2-message = gs2-ctx delim gs2-wrap
> gs2-ctx = escaped
> gs2-wrap = escaped
> ; It happens that the scram messages below conform to escaped
> scram-wrap-part = "mic=" base64 ["," 1*extension] ",d="
> scram-wrap = scram-wrap-part escaped
>
> scram-c1 = scram-c1-ctx delim
> scram-s1 = scram-s1-ctx delim
> scram-c2 = scram-c2-ctx delim scram-wrap-part scram-wrap-c2-inner
> scram-s2 = scram-s2-ctx delim scram-wrap-part scram-wrap-s2-inner
>
> ; Grammar 3: mic and base64
> ; In this case we assume that scram-mic is a fixed-length binary hmac
> followed by extra stuff  ; used by GSS-API but not SASL for sequencing
> and replay
> gs2-message = [gs2-mic gs2-stuff  ","] "ctx="gs2-ctx
> ; Note that determining where the end of the MIC is a bit tricky; it
> extends to ; but does not include the final comma in gs2-stuff. You don't
> know you are at ; the end until you read ctx
> gs2-mic = "mic=" base64 "," ; base64 of gss_getmic of gs2-stuff
> gs2-stuff = gs2-to-be-protected
> gs2-ctx = 1*octet
> scram-c1 = "ctx"= scram-c1-ctx
> scram-s1 = "ctx"= scram-s1-ctx
> scram-c2 = gs2-mic scram-wrap-c2-inner ",ctx=" scram-c2-ctx
> scram-s2 = gs2-mic scram-wrap-s2-inner ",ctx=" scram-s2-ctx
>
>

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-zeilenga-sasl-crammd5-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 18 Nov 2008 18:14:47 +0100
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> I ask the WG to consider this I-D as an alternative to
> draft-ietf-sasl-
> crammd5.

+1

/Simon

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Fwd: I-D ACTION:draft-zeilenga-sasl-crammd5-00.txt 
Date: Tue, 18 Nov 2008 10:54:00 -0600
Sender: [email-masked]

--Apple-Mail-5--388062648
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I ask the WG to consider this I-D as an alternative to draft-ietf-sasl- 
crammd5.

Also, I recuse myself from all chair actions regarding the SASL WG's  
CRAM-MD5 work item.

-- Kurt

Begin forwarded message:

> From: [email-masked]
> Date: November 18, 2008 10:15:01 AM CST
> To: [email-masked]
> Subject: I-D ACTION:draft-zeilenga-sasl-crammd5-00.txt
> Reply-To: [email-masked]
> List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: CRAM-MD5 to historic
> 	Author(s)	: K. Zeilenga
> 	Filename	: draft-zeilenga-sasl-crammd5-00.txt
> 	Pages		: 6
> 	Date		: 2008-11-18
> 	
>  This document recommends the retirement of the CRAM-MD5  
> authentication
>  mechanism, and discusses the reasons for doing so.  This document
>  recommends RFC 2195 and its predecessor, RFC 2095, be moved to
>  Historic status.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zeilenga-sasl-crammd5-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

--Apple-Mail-5--388062648
Content-Disposition: attachment;
	filename=mime-attachment
Content-Type: message/external-body;
	x-unix-mode=0666;
	name="mime-attachment"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain<BR>Content-ID: &lt;[email-masked]&gt;<BR><BR>
--Apple-Mail-5--388062648
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-5--388062648--

To: [email-masked]
Subject: SASL and KRB-WG Time Change
From: Tom Yu <[email-masked]>
Date: Mon, 17 Nov 2008 00:37:59 -0500
Lines: 79
Sender: [email-masked]

--=-=-=

Note the time change.  SASL will meet at 15:20 on Tuesday, instead of
the previously-scheduled 13:00.

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

To: [email-masked]
Date: Sun, 16 Nov 2008 19:09:26 -0600
From: All IETF 73 Attendees <[email-masked]>
Subject: [73all] SASL and KRB-WG Time Change
Reply-To: [email-masked]
Sender: [email-masked]
Lines: 10

SASL will now meet at 1520-1700 on Tuesday instead of 1300-1500.

KRB-WG will now meet at 1300-1500 on Tuesday instead of 1520-1700.

Both meetings will meet in the Rochester room.

_______________________________________________
73All mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/73all

--=-=-=--

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Tom Yu <[email-masked]>
Subject: Re: making progress on CRAM-MD5 before IETF73
Date: Mon, 10 Nov 2008 06:30:06 -0800
Sender: [email-masked]

On Nov 6, 2008, at 1:12 PM, Tom Yu wrote:

> Is there any objection to Frank's suggestion about adding Simon's
> PLAIN/CRAM comparison text?  I have heard none so far, and plan to ask
> Lyndon to update the draft accordingly.

Aside from issues with the particular text Simon suggested (see list  
archives), I have a general concern with inclusion of such text.   It  
will likely be a lightening rod for contentious discussions in the WG  
and the IESG.  It's not clear to me whether we'll reach consensus on a  
particular text.  And as we simply don't need to, why bother?   That  
is, I rather we focus on building consensus on the specification less  
this text.

-- Kurt

Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Tom Yu <[email-masked]>
Subject: Re: SCRAM storage in LDAP (Re: SASL WG status, 11/5)
Date: Mon, 10 Nov 2008 06:17:04 -0800
Sender: [email-masked]

On Nov 6, 2008, at 12:26 PM, Tom Yu wrote:

>
> Hallvard B Furuseth <[email-masked]> writes:
>
>> Tom Yu writes:
>>> SCRAM:
>>>  * LDAP storage of auth info
>>>        - WG to consider draft-melnikov-sasl-scram-ldap-00
>>
>> Why not authPassword from RFC 3112?  Value something like
>>   scram-hmac-sha1$<iter-count>:<salt>$<stored-key>:<server-key>
>> or scram-hmac-sha1-<iter-count>$<salt>$<stored-key>:<server-key>
>> where salt and keys are base64-encoded.
>>
>> For that matter, I've missed why this is a SASL draft instead
>> of an ldapext draft.  Proof of concept for SCRAM, maybe?
>
> Chris Newman stated that he would not implmenent SCRAM if there were
> no published way to store its authentication secrets in LDAP.  I have
> no strong opinion either way on whether to adopt this draft as a SASL
> WG item, but I think it needs to get published somehow.

I have a mild preference for engineering this outside of the WG.

-- Kurt

Date: Sun, 09 Nov 2008 19:05:00 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: A minor issue with hash function name IANA registry defined by RFC 4572
Sender: [email-masked]

Alexey Melnikov wrote:

> RFC 4572 established an IANA registry for hash function names:
> <http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml>. 
> All function names defined so far are in lowercase. SASL mechanism 
> names only allow for uppercase letters.
> I think the registry need to be updated to restrict which US-ASCII 
> characters are allowed in textual representations of a hash function 
> name. It might also be a good idea to say that hash function names are 
> case insensitive.

Actually, RFC 4572 has ABNF for the hash function name, but it is not 
mentioned in the IANA registration. The document is referencing <token> 
from RFC 4566, which is defined:

   token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                         / %x41-5A / %x5E-7E

   token =               1*(token-char)

This is still too permissive for SASL mechanism names, which only allow 
uppercase letters, digits, "-" and "_".

Date: Sun, 09 Nov 2008 18:43:34 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: A minor issue with hash function name IANA registry defined by RFC 4572
Sender: [email-masked]

RFC 4572 established an IANA registry for hash function names:
<http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml>. 
All function names defined so far are in lowercase. SASL mechanism names 
only allow for uppercase letters.
I think the registry need to be updated to restrict which US-ASCII 
characters are allowed in textual representations of a hash function 
name. It might also be a good idea to say that hash function names are 
case insensitive.

To: [email-masked]
Subject: making progress on CRAM-MD5 before IETF73
From: Tom Yu <[email-masked]>
Date: Thu, 06 Nov 2008 16:12:38 -0500
Lines: 67
Sender: [email-masked]

What remains to be done on CRAM-MD5?  I outlined some of the items in
my draft IETF73 agenda, but I would like to make progress on these
before that meeting.

* whether to change the status of RFC 2195 (and maybe RFC 2095)
* whether to change the CRAM-MD5 IANA registry entry
* intended track of draft-ietf-sasl-crammd5-10

Additionally, Frank Ellerman has asked for the document to include
Simon Josefsson's summary comparison of PLAIN and CRAM-MD5.

Is there any objection to Frank's suggestion about adding Simon's
PLAIN/CRAM comparison text?  I have heard none so far, and plan to ask
Lyndon to update the draft accordingly.

2195/2095 Status:

It may be best to explicitly move 2095 and 2195 to Historic in
conjunction with publishing this I-D, regardless of its actual track.

IANA Registry Entry:

The existing registry entry for CRAM-MD5 says "LIMITED" for intended
usage.  The wording of the current I-D also implies that the listing
should remain "LIMITED", despite not giving the "intended usage" field
in the IANA Considerations section.  If we intend to change this
registry entry, this change should be in the IANA Considerations
section, and the requested registry change should be consistent with
the rest of the document.

Intended Status:

I have heard strong opinions on both sides from WG participants about
the intended standards status of the current I-D.  Previous WG
consensus was to publish the I-D as Informational, despite the
proclamation of "Intended status: Standards Track" on the current I-D.
The consensus was uneasy at best.  This document has dragged on for an
embarrassingly long time, and a number of WG participants just want to
get it published.

I observe that, as with the IANA registry entry mentioned above, the
existing text in the document is not really consistent with a protocol
that we intend to be on the standards track.  I suggest that any WG
participants who wish for the I-D to publish on the standards track
work on making the document text consistent with this intent.

                         ====================

Does anyone disagree with my above conclusions that text changes will
be necessary to either publish on the standards track or to change the
IANA registry entry?

My evaluation of the state of this document and of this WG indicates
that the way to most quickly get this document published is:

* Add Simon's comparison text
* Change intended status to "Informational"

and possibly

* Request that 2095 and 2195 be marked "Historic"

I request that any WG participants who want this document to be on the
standards track or who want the intended usage in the IANA registry
changed to declare, before IETF73, their intent to help produce the
required text changes rapidly, along with a proposed schedule for
doing so.

To: Hallvard B Furuseth <[email-masked]>
Cc: [email-masked]
Subject: SCRAM storage in LDAP (Re: SASL WG status, 11/5)
From: Tom Yu <[email-masked]>
Date: Thu, 06 Nov 2008 15:26:55 -0500
Lines: 19
Sender: [email-masked]

Hallvard B Furuseth <[email-masked]> writes:

> Tom Yu writes:
>> SCRAM:
>>   * LDAP storage of auth info
>>         - WG to consider draft-melnikov-sasl-scram-ldap-00
>
> Why not authPassword from RFC 3112?  Value something like
>    scram-hmac-sha1$<iter-count>:<salt>$<stored-key>:<server-key>
> or scram-hmac-sha1-<iter-count>$<salt>$<stored-key>:<server-key>
> where salt and keys are base64-encoded.
>
> For that matter, I've missed why this is a SASL draft instead
> of an ldapext draft.  Proof of concept for SCRAM, maybe?

Chris Newman stated that he would not implmenent SCRAM if there were
no published way to store its authentication secrets in LDAP.  I have
no strong opinion either way on whether to adopt this draft as a SASL
WG item, but I think it needs to get published somehow.

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: draft agenda IETF73 SASL WG session
From: Tom Yu <[email-masked]>
Date: Thu, 06 Nov 2008 15:23:41 -0500
Lines: 22
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Tom Yu wrote:

>>* CRAM-MD5 - 30 min
>>  - fate of RFC 2195
>>  - fate of CRAM-MD5 IANA registry entry
>>  - track of draft-ietf-sasl-crammd5-10
>>
>>* other technical discussion - 60 min
>>  - GS2
>>  - SCRAM
>>  - interop report
>>
>>
> Frankly, I am sick and tired of CRAM-MD5 track discussion and would
> rather talk about GS2 and SCRAM first. But the list looks good to me
> otherwise.

Ok, I will consider changing the order.  I hope that we can get some
productive discussion on-list about CRAM-MD5 before the meeting.  I
will send another message on this topic shortly.

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 6 Nov 2008 12:15:27 +0100
To: [email-masked]
Subject: Re: SASL WG status, 11/5
Sender: [email-masked]

Tom Yu writes:
> SCRAM:
>   * LDAP storage of auth info
>         - WG to consider draft-melnikov-sasl-scram-ldap-00

Why not authPassword from RFC 3112?  Value something like
   scram-hmac-sha1$<iter-count>:<salt>$<stored-key>:<server-key>
or scram-hmac-sha1-<iter-count>$<salt>$<stored-key>:<server-key>
where salt and keys are base64-encoded.

For that matter, I've missed why this is a SASL draft instead
of an ldapext draft.  Proof of concept for SCRAM, maybe?

-- 
Hallvard

Date: Thu, 06 Nov 2008 10:26:55 +0000
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: draft agenda IETF73 SASL WG session
Sender: [email-masked]

Tom Yu wrote:

>Also uploaded to meeting materials site.  Please comment if you would
>like to add things to the agenda.
>
>Simple Authentication And Security Layer (SASL)
>IETF73, Minneapolis, MN
>
>Tuesday, November 18, 2008 at 1300-1500
>=======================================
>
>Chairs:
>
>Tom Yu <[email-masked]>
>Kurt Zeilenga <[email-masked]>
>
>DRAFT AGENDA: (2 hours)
>
>* intro, scribe appointment, agenda bashing - 5 min
>
>* document status - 5 min
>  - draft-ietf-sasl-4422bis-00
>  - draft-ietf-sasl-crammd5-10
>  - draft-ietf-sasl-digest-to-historic-00
>  - draft-ietf-sasl-gs2-10
>  - draft-melnikov-sasl-scram-ldap-00
>  - draft-newman-auth-scram-06
>
>* CRAM-MD5 - 30 min
>  - fate of RFC 2195
>  - fate of CRAM-MD5 IANA registry entry
>  - track of draft-ietf-sasl-crammd5-10
>
>* other technical discussion - 60 min
>  - GS2
>  - SCRAM
>  - interop report
>  
>
Frankly, I am sick and tired of CRAM-MD5 track discussion and would 
rather talk about GS2 and SCRAM first. But the list looks good to me 
otherwise.

>* discuss milestones - 10 min
>
>* open microphone - remaining time
>  
>

Date: Thu, 06 Nov 2008 10:24:26 +0000
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: SASL WG status, 11/5
Sender: [email-masked]

Tom Yu wrote:

>SCRAM:
>  * PBKDF2 iteration counts - DONE (Alexey)
>  
>
Yes, the new draft wasn't posted before the deadline, but the change is 
done.

>  * channel binding - Nico?
>  
>
I think this is done as well. Nico said that the current text is Ok.

>  * LDAP storage of auth info
>        - WG to consider draft-melnikov-sasl-scram-ldap-00
>  
>
Yes, indeed.
I wasn't sure if the format proposed in the draft was reasonable and I 
didn't have time to consult with Kurt or anybody else. We can quickly 
discuss this in Minneapolis.

>  * make equivalent to a GS2 mech
>        - pending WG discussion of encoding issue?
>  
>

To: [email-masked]
Subject: draft agenda IETF73 SASL WG session
From: Tom Yu <[email-masked]>
Date: Wed, 05 Nov 2008 17:49:38 -0500
Lines: 39
Sender: [email-masked]

Also uploaded to meeting materials site.  Please comment if you would
like to add things to the agenda.

Simple Authentication And Security Layer (SASL)
IETF73, Minneapolis, MN

Tuesday, November 18, 2008 at 1300-1500
=======================================

Chairs:

Tom Yu <[email-masked]>
Kurt Zeilenga <[email-masked]>

DRAFT AGENDA: (2 hours)

* intro, scribe appointment, agenda bashing - 5 min

* document status - 5 min
  - draft-ietf-sasl-4422bis-00
  - draft-ietf-sasl-crammd5-10
  - draft-ietf-sasl-digest-to-historic-00
  - draft-ietf-sasl-gs2-10
  - draft-melnikov-sasl-scram-ldap-00
  - draft-newman-auth-scram-06

* CRAM-MD5 - 30 min
  - fate of RFC 2195
  - fate of CRAM-MD5 IANA registry entry
  - track of draft-ietf-sasl-crammd5-10

* other technical discussion - 60 min
  - GS2
  - SCRAM
  - interop report

* discuss milestones - 10 min

* open microphone - remaining time

To: [email-masked]
Subject: SASL WG status, 11/5
From: Tom Yu <[email-masked]>
Date: Wed, 05 Nov 2008 17:47:48 -0500
Lines: 28
Sender: [email-masked]

WG Charter - DONE

IETF73 draft WG agenda - Tom - 11/5 - DONE

IETF73 final WG agenda - Tom - 11/10

RFC 4422bis - review needed - WG

RFC 4422 implementation reports - Kurt - past due

RFC 4013bis - dropped from WG

CRAM-MD5 - resolve pending items from Frank:
  * adding Simon's PLAIN/CRAM comparison
  * tying to saslprep revision - N/A due to saslprep puntage
  * resolution on intended track - WG

digest-to-historic - mostly done, awaiting SCRAM

GS2 - Awaiting SCRAM issue resolution (encoding)

SCRAM:
  * PBKDF2 iteration counts - DONE (Alexey)
  * channel binding - Nico?
  * LDAP storage of auth info
        - WG to consider draft-melnikov-sasl-scram-ldap-00
  * make equivalent to a GS2 mech
        - pending WG discussion of encoding issue?