Subject: Re: draft-josefsson-password-auth-00.txt
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 29 Mar 2007 17:59:00 -0500
List-Id: <ietf-sasl.imc.org>

On Fri, Mar 30, 2007 at 12:50:43AM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > Any where the server stores a secret verifier derived from the password
> > salted with the server's name.  If the server sends a response to the
> > client's response that proves it knows the verifier then the client can
> > consider the server to be authenticated to the client.
> 
> Depending on the architecture of the challenge response scheme
> this may not be easily done.
> 
> There are legacy systems where the (app)server actually possesses
> the shared secret and could therefore "prove he knows it".

Indeed.  But that doesn't mean that a generic mechanism in this area
must not support salting passwords as I described.

> AFAIK, the NTLM authentication on windows differs here.  The
> server doesn't have access to the shared secret, but has a
> secure channel to a domain controller where he can ask whether
> a particular combination of challenge and response is acceptable.

Yes, proxying should be acceptable.

> > You're misusing the term "channel binding" here.  A server name not
> > associated with some secure channel below the application layer is not a
> > channel binding.
> 
> Sorry, but I have to disagree completely.  GSS-API has a very
> "open" concept of channel bindings.

Here we're talking about a mechanism more generic still than a GSS
mechanism.  Lately when we speak of channel binding we mostly mean it in
the "transformed representations of encryption keys) of the underlying
communications channel, of protection mechanisms applied to that
communications channel," subset of the sense of RFC2743.

You may want to comment on draft-williams-on-channel-binding-01.txt;
it's in IETF Last Call.

> You might want to turn your attention to RFC-2744 Section 3.11.

The relevant text is in RFC2743, section 1.1.6, first paragraph.

Nico
-- 

From: Martin Rex <[email-masked]>
Subject: Re: draft-josefsson-password-auth-00.txt
To: [email-masked] (Nicolas Williams)
Date: Fri, 30 Mar 2007 00:50:43 +0200 (MEST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Nicolas Williams wrote:
> 
> On Fri, Mar 30, 2007 at 12:11:16AM +0200, Martin Rex wrote:
> > To me that seems to be slightly inappropriate terminology.
> > 
> > Which particular challenge-response scheme do you have in mind
> > where the server actually performs a mutual authentication,
> > i.e. provides a cryptographic proof of his identity?
> 
> Any where the server stores a secret verifier derived from the password
> salted with the server's name.  If the server sends a response to the
> client's response that proves it knows the verifier then the client can
> consider the server to be authenticated to the client.

Depending on the architecture of the challenge response scheme
this may not be easily done.

There are legacy systems where the (app)server actually possesses
the shared secret and could therefore "prove he knows it".

AFAIK, the NTLM authentication on windows differs here.  The
server doesn't have access to the shared secret, but has a
secure channel to a domain controller where he can ask whether
a particular combination of challenge and response is acceptable.

> 
> > If the client derives the target name from the network endpoint
> > address (i.e. fqdn-hostname plus service/tcp-port-no) and
> > the server simply "asserts" this name, then this is really
> > a channel binding based on a printable name instead of
> 
> You're misusing the term "channel binding" here.  A server name not
> associated with some secure channel below the application layer is not a
> channel binding.

Sorry, but I have to disagree completely.  GSS-API has a very
"open" concept of channel bindings.

You might want to turn your attention to RFC-2744 Section 3.11.
which lists all types of channel bindings that "GSS-API v2"
knows about.  None of what I see there is what I recognize
as "secure" channel bindings, but it does have the "GSS_C_AF_INET"
type.

-Martin

Date: Thu, 29 Mar 2007 17:37:56 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-josefsson-password-auth-00.txt
Mail-Followup-To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Fri, Mar 30, 2007 at 12:11:16AM +0200, Martin Rex wrote:
> To me that seems to be slightly inappropriate terminology.
> 
> Which particular challenge-response scheme do you have in mind
> where the server actually performs a mutual authentication,
> i.e. provides a cryptographic proof of his identity?

Any where the server stores a secret verifier derived from the password
salted with the server's name.  If the server sends a response to the
client's response that proves it knows the verifier then the client can
consider the server to be authenticated to the client.

> If the client derives the target name from the network endpoint
> address (i.e. fqdn-hostname plus service/tcp-port-no) and
> the server simply "asserts" this name, then this is really
> a channel binding based on a printable name instead of

You're misusing the term "channel binding" here.  A server name not
associated with some secure channel below the application layer is not a
channel binding.

> the low-level network address, but still a channel binding and
> not an authentication.

I really didn't want to talk about server name canonicalization.  I
wanted to sketch a generic password-based challenge/response mechanism
that supports the optional use of channel binding and optional mutual
authentication.

Yes, I included in my sketch an acceptor-side assertion of its name.
This has two purposes that I did not mention.  One: when the client
doesn't know the server's name the client can simply go ahead and use
the asserted server name as the salt -- if the alternative is not to
salt the password at all then this is clearly good and not harmful (the
client provides material that can be attacked offline regardless of how
the password is salted).  The other: so the client can output the
correct server name to the application which can then prompt the user,
or for "fuzzy" server name canonicalization.

(I know, you don't have to remind me that the GSS-APIv2u1's
GSS_Canonicalize_name() is supposed to be able to canonicalize the given
server (or whatever) name securely and out of band w.r.t. security
context establishment.  But we're talking here too about a mechanism
usable outside the context of the GSS-API also, and anyways, that bit of
GSS-APIv2u1 semantics is rather cumbersome.)

From: Martin Rex <[email-masked]>
Subject: Re: draft-josefsson-password-auth-00.txt
To: [email-masked] (Nicolas Williams)
Date: Fri, 30 Mar 2007 00:11:16 +0200 (MEST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Nicolas Williams wrote:
> 
> A target name is needed so the acceptor's verifier can be a weak
> password equivalent (meaning it's a password equivalent only for
> authenticating to the same acceptor).  Therefore it's useful to
> have a target name even when mutual auth is not requested.
> 
> A target name is required for mutual auth, of course.

To me that seems to be slightly inappropriate terminology.

Which particular challenge-response scheme do you have in mind
where the server actually performs a mutual authentication,
i.e. provides a cryptographic proof of his identity?

If the client derives the target name from the network endpoint
address (i.e. fqdn-hostname plus service/tcp-port-no) and
the server simply "asserts" this name, then this is really
a channel binding based on a printable name instead of
the low-level network address, but still a channel binding and
not an authentication.

-Martin

Date: Thu, 29 Mar 2007 16:15:14 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-josefsson-password-auth-00.txt
Mail-Followup-To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> I.e., we could merge YAP and the other proposals into one generic
> mechanism.

Very, very roughly, primarily to illustrate the context token exchanges:

IDi = initiator name
IDt = target acceptor name
IDa = acceptor name (like IDt, but asserted by the acceptor)
S   = salt derived from IDt or IDa
K   = PBKDF2(password || S, iteration)
R1  = response_function(K, [challenge] || channel bindings || [cnonce])
R2  = response_function2(K, R1)

1/2   rt (   channel bindings and no mutual auth)
    I -> A:  IDi, [IDt,] R1

1     rt (   channel bindings and    mutual auth)
    I -> A:  IDi, IDt, R1
    A -> I:  R2

1 1/2 rt (no channel bindings and no mutual auth)
    I -> A:  IDi, [IDt]
    A -> I:  IDa, challenge
    I -> A:  nonce, R1

2     rt (no channel bindings and    mutual auth)
    I -> A:  IDi
    A -> I:  IDa, challenge
    I -> A:  nonce, R1
    A -> I:  R2

A target name is needed so the acceptor's verifier can be a weak
password equivalent (meaning it's a password equivalent only for
authenticating to the same acceptor).  Therefore it's useful to
have a target name even when mutual auth is not requested.

A target name is required for mutual auth, of course.

The 1 1/2 rt version could add DH key agreement for PFS.  And the 2 rt
version could add DH key agreement for PFS and some privacy protection
of IDi.  That is probably not worthwhile for any SASL application, since
they tend to have STARTTLS-type options, and for GSS one could always
add PFS with stackable mechanisms.

Nico
-- 

Date: Thu, 29 Mar 2007 11:28:40 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-josefsson-password-auth-00.txt
Mail-Followup-To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

A very general password-based challenge-response mechanism that provides
optional channel binding and optional mutual authentication in one, one
and a half and two round-trips should be feasible:

 - w/  unique channel bindings -> 1 rt
 - w/o unique channel bindings + uni-dir authen -> 1 and 1/2 rt
 - w/o unique channel bindings + mutual auth -> 2 rt

Mutual authentication would work the acceptor name into the PBKDF
inputs.  Uni-directional authentication would not work the acceptor name
into the PBKDF (only if no acceptor name was given? or always).

I.e., we could merge YAP and the other proposals into one generic
mechanism.

Nico
-- 

Date: Thu, 29 Mar 2007 11:17:01 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-josefsson-password-auth-00.txt
Mail-Followup-To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Thu, Mar 29, 2007 at 06:08:33PM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > On Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote:
> > > Most challenge-response protocols perform a unidirectional
> > > authentication of the client/initiator to the server/acceptor only,
> > > and for those the authentication scheme usually does not have
> > > a name for the acceptor.
> > 
> > Understood.  Perhaps then what I should have said is that when mutual
> > authentication is requested then the password should be salted with the
> > acceptor name.
>  
> At first glance I think it should be OK if some kind of channel bindings
> are included in (hashed into) the challenge-response exchange.

Certainly, provided any are available.

Last week Kurt proposed a mechanism that requires channel bindings, and
called it YAP (yet another ...).

It works in just one round-trip (in addition to however many the secure
channel required to establish) because the channel binding acts as the
server challenge (provided the channel binding is unique in time, else
there's a replay attack).

Nico
-- 

From: Martin Rex <[email-masked]>
Subject: Re: draft-josefsson-password-auth-00.txt
To: [email-masked] (Nicolas Williams)
Date: Thu, 29 Mar 2007 18:08:33 +0200 (MEST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Nicolas Williams wrote:
> 
> On Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote:
> > Most challenge-response protocols perform a unidirectional
> > authentication of the client/initiator to the server/acceptor only,
> > and for those the authentication scheme usually does not have
> > a name for the acceptor.
> 
> Understood.  Perhaps then what I should have said is that when mutual
> authentication is requested then the password should be salted with the
> acceptor name.
 
At first glance I think it should be OK if some kind of channel bindings
are included in (hashed into) the challenge-response exchange.

-Martin

From: Kurt Zeilenga <[email-masked]>
Subject: YAP applicability in Lemonade
Date: Thu, 29 Mar 2007 08:32:25 -0700
To: [email-masked]
Sender: [email-masked]

I chatted with Eric Burger briefly last week about YAP applicability
to use in Lemonade deployments.  We concluded as Lemonade use of TLS
is quite limited, applicability of YAP in Lemonade is limited.

-- Kurt

Date: Thu, 29 Mar 2007 10:21:29 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-josefsson-password-auth-00.txt
Mail-Followup-To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote:
> Most challenge-response protocols perform a unidirectional
> authentication of the client/initiator to the server/acceptor only,
> and for those the authentication scheme usually does not have
> a name for the acceptor.

Understood.  Perhaps then what I should have said is that when mutual
authentication is requested then the password should be salted with the
acceptor name.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-gs2-08.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 29 Mar 2007 17:20:13 +0200
Sender: [email-masked]

The GS2 -08 document contains minor fixes based on WGLC feedback, see:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-08-from-7.diff.html

/Simon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gs2-08.txt 
Date: Thu, 29 Mar 2007 10:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Using GSS-API Mechanisms in SASL: The GS2 
                          Mechanism Family
	Author(s)	: S. Josefsson
	Filename	: draft-ietf-sasl-gs2-08.txt
	Pages		: 34
	Date		: 2007-3-29
	
This document describes how to use a Generic Security Service
   Application Program Interface (GSS-API) mechanism in the the Simple
   Authentication and Security Layer (SASL) framework.  This is done by
   defining a new SASL mechanism family, called GS2.  This mechanism
   family offers a number of improvements over the previous SASL/GSS-API
   mechanism: it is more general, uses fewer messages for the
   authentication phase in some cases, and supports a SASL-specific
   notion of channel binding.

   See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sasl-gs2-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-gs2-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-gs2-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-gs2-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

From: Martin Rex <[email-masked]>
Subject: Re: draft-josefsson-password-auth-00.txt
To: [email-masked] (Nicolas Williams)
Date: Thu, 29 Mar 2007 16:48:50 +0200 (MEST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Nicolas Williams wrote:
> 
> > any case, how to salt the password is an open question.  Perhaps the
> 
> Well, you'd want to salt it with the server's name, so the verifier is
> different at each server.  Then again, many sites might object.  So you
> might want a two level verifier derivation where the first step is not
> salted with the server name and the second is -- then one could
> distribute the output of the first step as the verifier for all servers
> in a site.

What you seem to be looking/asking for sounds like "channel bindings"
rather than name-based mutual authentication of the server (many
password-based challenge-response authentication schemes do not
provide mutual authentication).

Keep in mind that it might be difficult for servers and clients
to agree on the same name for the server.  Take Microsoft Kerberos
as an example: there the server usually doesn't know (and doesn't
care) what target name the client is using -- the server will
always try to open service tickets by "brute force" using
his own secret key.  With very few exceptions, service principals
don't exist in Microsofts Kerberos, they're mere aliases known
to the KDC/Active Directory and may be used by clients/initiators--
A Microsoft server/acceptor normally doesn't know or care what service
pricipal aliases exist for his own account and which particular
alias was used by a client, it will look at the realm on the service
ticket to get the salting right, but entirely ignore the principal
name on the ticket.

(At least that is what happend with W2K Kerberos when I tested,
 and it can be verified by setting up two seperate user accounts "b" and "c"
 with the same password (both enabled for rfc-1964 authentication
 if W2K3 AD is used).  A server started under "b" will then
 happily establish security contexts with clients that use "b"
 as the target name as well as clients that use "c" as the target name.)

-Martin

From: Martin Rex <[email-masked]>
Subject: Re: draft-josefsson-password-auth-00.txt
To: [email-masked] (Nicolas Williams)
Date: Thu, 29 Mar 2007 16:28:30 +0200 (MEST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Nicolas Williams wrote:
> 
> > any case, how to salt the password is an open question.  Perhaps the
> 
> Well, you'd want to salt it with the server's name, so the verifier is
> different at each server.  Then again, many sites might object.  So you
> might want a two level verifier derivation where the first step is not
> salted with the server name and the second is -- then one could
> distribute the output of the first step as the verifier for all servers
> in a site.

Most challenge-response protocols perform a unidirectional
authentication of the client/initiator to the server/acceptor only,
and for those the authentication scheme usually does not have
a name for the acceptor.

I know that the Kerberos gss-api mechanism is "slightly" broken in
this respect since it requires a target name for gss_init_sec_context
even for unidirectional-only authentication.  This requirement
is one of the reasons why in many Kerberos scenarios an end-point
identification similar to what HTTPoverSSL/TLS does is used instead
of a real mutual authentication. 

One example for a challenge-repsonse authentication with GSS-API
style token exchange is Microsoft's NTLM SSP.  My GSS-API wrapper
for Microsoft's Kerberos SSP also includes a wrapper for Microsoft's
NTLM SSP.  

-Martin

Cc: [email-masked], [email-masked], [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: draft-josefsson-password-auth-00.txt
Date: Thu, 29 Mar 2007 07:13:03 -0700
To: Simon Josefsson <[email-masked]>
Sender: [email-masked]

On Mar 29, 2007, at 6:03 AM, Simon Josefsson wrote:

> I'm cc:ing this to the password-auth mailing list that I created for
> discussion of the document.  Some discussions of the document may be
> off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to
> see it discussed elsewhere (let me know!), so consider dropping the
> IETF lists when starting such a thread.

Given the SASL charter allows for the WG to review, as time permits,
independently developed SASL mechanism specifications, and the SASL
WG is currently discussing revision of our charter to include
additional work item(s) in this area, I would prefer discussions
related to password-based SASL mechanisms stay on the SASL WG list
(at least for now).

-- Kurt, SASL WG co-chair

Date: Thu, 29 Mar 2007 08:57:43 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-josefsson-password-auth-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Thu, Mar 29, 2007 at 03:33:33PM +0200, Simon Josefsson wrote:
> I'm not really that familiar with the naming corners of GSS-API...  In

You need to specify what name types the mech supports and how to convert
from generic name syntaxes (<username>, <service>@<host>) to mechanism-
specific syntaxes (which for a password-based mechanism might be the
identity function) and what mechanism-specific name types exist, their
syntaxes and so on (there wouldn't be any for a password-based mech).
And then there's the exported name token format, which for
password-based mechs should also be trivial.

> any case, how to salt the password is an open question.  Perhaps the

Well, you'd want to salt it with the server's name, so the verifier is
different at each server.  Then again, many sites might object.  So you
might want a two level verifier derivation where the first step is not
salted with the server name and the second is -- then one could
distribute the output of the first step as the verifier for all servers
in a site.

> exported name format can be used as the salt value with PKCS#5 PBKDF2?

Yes.  But there's two names: the client's and the server's.

> But then you'll need to transfer the PBKDF2 iteration counter, or
> (worse) fixate it.  The iteration counter question is the main reason
> why I haven't used PBKDF2 yet.  That, and I'm not sure PBKDF2 in this
> protocol actually protects against any valid security threats.

Either negotiate the iteration count or make it part of the mechanism
name/OID.

Kerberos V uses PBKDF2.  I see no reason why we couldn't use it here.

Nico
-- 

Date: Thu, 29 Mar 2007 08:42:56 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: pw-based mech options (Re: draft-josefsson-password-auth-00.txt)
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Thu, Mar 29, 2007 at 08:17:16AM -0500, Nicolas Williams wrote:
> Not another mailing list... :/  :)
> 
> >        http://josefsson.org/password-auth/

And moderated to boot.  I'd rather we first seek consensus on the SASL
list as to whether the WG should take on any new password-based
mechanisms, and if so whether to proceed as Sam suggested (spec the mech
as a SASL/GS2 mech without reference to the GSS-API and describe its GSS
bindings in a separate section/document).

Me, I'm all for doing this work in this WG.  Of course, there were
several options on the table, and we may want to pick one, or maybe two.

I volunteered to help with the GSS bits regardless of which options we
choose.

BTW, about YAP, I get it now: it uses unique channel bindings as a
standing for both, server challenge and client nonce.

Also, during SAAG EKR suggested to me (via jabber) doing a password-
based mechanism as a profile of TLS PSK.

Of course, doing password auth in TLS PSK can work and it can even
provide a measure of protection against off-line dictionary attacks, but
it does not provide for privacy protection of the client identity.  If
we really want the latter then YAP seems like a good choice for SASL
apps running over TLS, else a password-based profile of TLS PSK seems
like a better approach.  We'd still need a password-based GSS mechanism,
but if we push the SASL mechanism to TLS then we effectively wash SASL's
hands of a password-based GSS mech.

Our options so far:

 - TLS PSK profile
 - YAP (which, incidentally, it seems it can't be a GS2 mech, though it
        can be a SASL mech and it can be a GSS mech)
 - Traditional challenge/response mechanisms (Simon's, Hexa, etc...)

A TLS profile seems un-SASLish, but we (the IETF) could use that too.

YAP is neat (one round-trip!), but absolutely depends on an underlying
channel with unique channel bindings (else it's replayable).

A traditional challenge/response design is needed to have a well rounded
SASL/GSS mechanism story.

So, my tentative position:

 - pursue a traditional challenge/response mechanism as a WG item
 - pursue YAP as a WG item IFF the privacy protection angle is deemed
   important
 - pursue a TLS PSK profile as an individual submission or let the TLS
   WG take it

Comments?

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: draft-josefsson-password-auth-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 29 Mar 2007 15:33:33 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Thu, Mar 29, 2007 at 03:03:42PM +0200, Simon Josefsson wrote:
>> My idea is to specify a challenge/response protocol that is (somewhat)
>> agnostic to the framework (GSS-API or SASL) and then specify how that
>> protocol is used in these two frameworks.  Since the wire protocol is
>> highly influenced by GSS-API and SASL concepts, the mappings for how
>> to use the protocol in GSS-API or SASL is just one page.  The
>
> I guess it can be one page, since for GSS challenge/response password-
> based mechs there won't be many name types available, thus not much
> discussion of naming.  Right?  Maybe not: presumably acceptor names are
> used to salt the password, in which case any name type goes and the mech
> has to specify the relevant mappings from generic name syntax to
> whatever the mech uses internally.  And there's the exported name token
> format to consider also.

I'm not really that familiar with the naming corners of GSS-API...  In
any case, how to salt the password is an open question.  Perhaps the
exported name format can be used as the salt value with PKCS#5 PBKDF2?
But then you'll need to transfer the PBKDF2 iteration counter, or
(worse) fixate it.  The iteration counter question is the main reason
why I haven't used PBKDF2 yet.  That, and I'm not sure PBKDF2 in this
protocol actually protects against any valid security threats.

> But in any case, it needn't be much text, and I've volunteered to write
> that text.

Excellent!

/Simon

Date: Thu, 29 Mar 2007 08:17:16 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-josefsson-password-auth-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Thu, Mar 29, 2007 at 03:03:42PM +0200, Simon Josefsson wrote:
> My idea is to specify a challenge/response protocol that is (somewhat)
> agnostic to the framework (GSS-API or SASL) and then specify how that
> protocol is used in these two frameworks.  Since the wire protocol is
> highly influenced by GSS-API and SASL concepts, the mappings for how
> to use the protocol in GSS-API or SASL is just one page.  The

I guess it can be one page, since for GSS challenge/response password-
based mechs there won't be many name types available, thus not much
discussion of naming.  Right?  Maybe not: presumably acceptor names are
used to salt the password, in which case any name type goes and the mech
has to specify the relevant mappings from generic name syntax to
whatever the mech uses internally.  And there's the exported name token
format to consider also.

But in any case, it needn't be much text, and I've volunteered to write
that text.

[...]
> Comments?
> 
> I'm cc:ing this to the password-auth mailing list that I created for
> discussion of the document.  Some discussions of the document may be
> off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to
> see it discussed elsewhere (let me know!), so consider dropping the
> IETF lists when starting such a thread.  To subscribe to the list, and
> for other resources related to this effort, see:

Not another mailing list... :/  :)

>        http://josefsson.org/password-auth/
> 
> Even if there isn't much uptake from the SASL community on this idea,
> I believe having a password-based GSS-API mechanism is an important
> contribution and I'll continue working on that.  How much the document
> talks about SASL will depend on the interest.  Through GS2, it will
> eventually be possible to use it in SASL anyway.

Agreed.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: draft-josefsson-password-auth-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 29 Mar 2007 15:03:42 +0200
Sender: [email-masked]

Hi all!

The SASL WG discussed new password-based mechanisms, and there were
some discussions at the last meeting to do this through a GSS-API
mechanism instead.  I mentioned on jabber that I had been working on a
draft to do that, and while it is far from finished I thought I'd
publish it early to gauge interest in the work.

My idea is to specify a challenge/response protocol that is (somewhat)
agnostic to the framework (GSS-API or SASL) and then specify how that
protocol is used in these two frameworks.  Since the wire protocol is
highly influenced by GSS-API and SASL concepts, the mappings for how
to use the protocol in GSS-API or SASL is just one page.  The
cryptographic primitive is right now HMAC-SHA-256 but the intention is
that other MACs, including non-HMAC based approaches such as AES-CMAC
(RFC 4493) can be supported easily.

To make it easier to implement this as a SASL mechanism, I'm sure the
document could say a lot more.  I intend to include sample code for
DER length encoding (it is only a few lines of C code), which is
something some people consider complex.  Providing an entire
implementation of the GS2-YGZBCUXPNWNVHSI mechanism would be possible
to include, I believe there is not a lot of code to do it.  This might
make it easier for IMAP/SMTP implementers to start using it quickly.

The document is available from the IETF servers, see the announcement
below.

Comments?

I'm cc:ing this to the password-auth mailing list that I created for
discussion of the document.  Some discussions of the document may be
off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to
see it discussed elsewhere (let me know!), so consider dropping the
IETF lists when starting such a thread.  To subscribe to the list, and
for other resources related to this effort, see:

       http://josefsson.org/password-auth/

Even if there isn't much uptake from the SASL community on this idea,
I believe having a password-based GSS-API mechanism is an important
contribution and I'll continue working on that.  How much the document
talks about SASL will depend on the interest.  Through GS2, it will
eventually be possible to use it in SASL anyway.

/Simon

[email-masked] writes:

> 	Title		: A Password-based Authentication Protocol
> 	Author(s)	: S. Josefsson
> 	Filename	: draft-josefsson-password-auth-00.txt
> 	Pages		: 16
> 	Date		: 2007-3-28
> 	
>    There is a lack of a simple, standardized, secure and modern
>    password-based mechanism for user authentication in application
>    protocols.  This document specify a challenge/response protocol that
>    provide password-based authentication services.  We describe how the
>    protocol may be used as a GSS-API mechanism and, using the GS2
>    framework, how it may be used as a SASL mechanism.  The protocol
>    supports HMAC-SHA-256 as the mandatory to implement algorithm, and it
>    supports channel bindings.  The intended use is by application
>    protocol that today use CRAM-MD5 or DIGEST-MD5 via SASL, or by GSS-
>    API applications that needs a password based method.  The protocol is
>    applicable to other environments, such as EAP, should the need arise.
>
>    See <http://josefsson.org/password/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-password-auth-00.txt

To: [email-masked], [email-masked]
Subject: IETF68 SASL WG summary
From: Tom Yu <[email-masked]>
Date: Thu, 22 Mar 2007 22:07:00 -0400
Lines: 54
Sender: [email-masked]

SASL WG
Wednesday, March 21, 2006, at 1300-1500

SUMMARY
=======

Thanks to Bob Morgan for scribing.

Document Status:

draft-ietf-sasl-crammd5-08     in WGLC
draft-ietf-sasl-gs2-07         in WGLC
draft-ietf-sasl-gssapi-08      RFC 4752
draft-ietf-sasl-rfc2831bis-12  some issues...

WGLC documents -- mostly only have minor issues.  We need more
reviewers for CRAM-MD5.

Given problems with DIGEST-MD5 in terms of interoperability and
implementability, there appears to be consensus to move DIGEST-MD5 (in
the form of RFC 2831) to Historic.

Presentations about several proposed alternative password-based
mechanisms:

draft-cridland-sasl-hexa-00.txt
draft-newman-auth-scram-04.txt
draft-zeilenga-sasl-yap-00.txt

HEXA and SCRAM are somewhat similar and may end up being combined
eventually.  YAP may remain independent.  There appears to be
consensus for adopting at least one of these hash-based password
mechanisms as a WG work item, and adopting some HEXA+SCRAM derivative
as a replacement for DIGEST-MD5.  There appears to be consensus that
the WG doesn't yet have enough information about application
requirements to determine whether one of these mechanisms or two of
these mechansisms should be adopted.

Kurt talked about interop reports, and there was discussion about the
Draft Standard advancement process.

Alexey talked about Sam's Discuss on the smtp-auth document, regarding
mandating of the verification of server TLS certificates when using
PLAIN over TLS.

ACTION ITEMS
============

* in the next week, acquire more information about application
  requirements upon password-based mechanisms.

* conclude WG Last Calls

* recharter including DIGEST-MD5 replacement(s)

To: [email-masked]
Subject: IETF68 SASL WG slides uploaded
From: Tom Yu <[email-masked]>
Date: Wed, 21 Mar 2007 05:30:54 -0400
Lines: 5
Sender: [email-masked]

I have uploaded some presentation slides to the meeting materials web
page, in preparation for the WG session, so that people not physically
attending may review them.

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68

To: [email-masked]
Subject: presentation slides requested for WG session
From: Tom Yu <[email-masked]>
Date: Tue, 20 Mar 2007 17:00:41 -0400
Lines: 6
Sender: [email-masked]

If you are planning to present at the SASL WG session tomorrow, please
get your slides (if any) to me (in PDF or PPT format) by 11:30 local
time tomorrow so that I can post them on the meeting materials web
page.  Thanks.

---Tom

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: Future of DIGEST-MD5
Date: Sun, 18 Mar 2007 21:55:36 +0100
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

On Mar 18, 2007, at 11:56 AM, Alexey Melnikov wrote:
> Hi folks,
> During recent IETF Last Calls on SMTP and POP3 AUTH documents it  
> became
> quite clear that implementors didn't like DIGEST-MD5 for the following
> reasons:
>
> 1). it is complex to implement and has too many options that don't
> interoperate well
> 2). it has some minor design flaws (e.g. lack of protection of the qop
> and cipher lists sent by the server, doesn't provide hash agility)
> 3). some features cause pain for sysadmins (e.g. renaming a user
> invalidates SS hash)
>
> I am also seeing general lack of interest in the document. Even though
> it was fun learning new things while working on DIGEST-MD5, I am  
> feeling
> like I am dragging both the carriage and the horse. Which makes me
> wonder if I should continue to spend my time on this document (*).
> Having said that I see some alternatives in moving forward:
>
> 1). Abandon 2831bis. Possibly publish a document moving RFC 2821 to
> Historic. (**)

My personal preference would be to publish a short I-D which provided a
brief overview of the specification (RFC2831) and implementation issues
with DIGEST-MD5 and to submit this to the IESG as rationale for moving
RFC 2831 to Historic.  In absence of volunteer to write such a document,
I would simply let RFC 2831 rot.

-- Kurt

Date: Sun, 18 Mar 2007 20:53:57 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Future of DIGEST-MD5
Cc: [email-masked]
Sender: [email-masked]

My preference, for what little it's worth, would be to gently ditch 
digest-md5. Fix the clear bugs in 2831 and say that there have been 
many interoperbility problems, so implementers should look at 
implementing <othermech> instead of or in addition to digest-md5.

(I say this as someone who's written most of the MUA I use as well as a 
big chunk of the IMAP server I use, and their digest-md5 
implementations don't intereoperate perfectly.)

Arnt

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Future of DIGEST-MD5
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 18 Mar 2007 20:27:02 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> 1). Abandon 2831bis. Possibly publish a document moving RFC 2821 to
> Historic. (**)
> 2). Abandon attempts to fix RFC 2831. Publish 2831bis which only
> clarifies ambiguities and fixes obvious bugs. It will document features
> which must not be used due to lack of interoperability. The document
> will not define any new features, i.e. no channel bindings, SASLPrep,
> fixed confidentiality layer, etc. (**)
> 3). Get 2831bis published.
>
> So I would like to poll the WG to see what the WG preference is.

My choice is #1, because none of the other choices above will change
that DIGEST-MD5 is based on a non-standardized keyed MAC mode with a
hash algorithm that has been deprecated for 10 years, and #1 leads to
the least amount of additional time you and the WG have to spend on
DIGEST-MD5.

I deeply wished that the WG could have made this decision long time
ago, to have let you spend the time working on something better than
DIGEST-MD5.  I've written 3 or 4 implementations of DIGEST-MD5, and
every time I find something new when I re-read the specification.
Maintaining that complexity while adding new features must have
required a lot of work...

/Simon

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Future of DIGEST-MD5
Date:  Sun, 18 Mar 2007 16:23:33 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 35
Sender: [email-masked]

Alexey Melnikov wrote:
 
> Possibly publish a document moving RFC 2821 to Historic.
                                         ^^^^
That's rather harsh... <gd&r>  Back to 2831:  I'm not sure
about the channel binding stuff, should it use the same
name "DIGEST-MD5", or should it go into a separate text
(based on 2831bis) with its own name ?

Simply saying that it's historic isn't true, at least for
the 2617 incarnation.  What you have for 2831bis should be
a good start for a hypothetical "CHANNEL-MD5" or a 2617bis.

If "CHANNEL-MD5" can happily ignore backwards compatibility
issues, with SASLPREP as given (in a 2831bis), it might be
less confusing.  

> I have 20 or so other documents I am [co-]editing so I
> would rather concentrate on getting them finished.

Last state I know is that anything for a 2831bis _minus_
"channel bindings" is ready.  IOU a note about the LWSP
issue, what else is missing ?

> WG time might be better spent on designing a new mechanism
> that is simpler than DIGEST-MD5 and/or has better properties.

For CRAM-MD5 I failed to figure out how precisely the RFC
2195 <msg-id> style of a challenge might be related to the 
"channel bindings".  A <msg-id> has a left hand side with a
domain, now what, could this help with CRAM-MD5 over TLS ? 
Could clients try to match the domain with the certificate ?

Frank

Date: Sun, 18 Mar 2007 08:10:42 -0400
From: Tony Hansen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: Future of DIGEST-MD5
Sender: [email-masked]

Alexey Melnikov wrote:
> 
> 1). Abandon 2831bis. Possibly publish a document moving RFC 2821 to
> Historic. (**)

No to both.

I also feel the documents saying "move XXX to historic" are silly and
should never have been started.

> 2). Abandon attempts to fix RFC 2831. Publish 2831bis which only
> clarifies ambiguities and fixes obvious bugs. It will document features
> which must not be used due to lack of interoperability. The document
> will not define any new features, i.e. no channel bindings, SASLPrep,
> fixed confidentiality layer, etc. (**)
> 3). Get 2831bis published.

I think #2 would be fine.

	Tony Hansen
	[email-masked]

Date: Sun, 18 Mar 2007 11:46:28 +0000
From: Chris Newman <[email-masked]>
Subject: Re: Future of DIGEST-MD5
To: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

I concur with your observations.

It's my preference that we document the mistakes that were made with RFC 2831 
so we have a better chance of not repeating them.  So I slightly prefer option 
2, but option 1 is also fine.

                - Chris

Alexey Melnikov wrote on 3/18/07 10:56 +0000:

>
> Hi folks,
> During recent IETF Last Calls on SMTP and POP3 AUTH documents it became
> quite clear that implementors didn't like DIGEST-MD5 for the following
> reasons:
>
> 1). it is complex to implement and has too many options that don't
> interoperate well
> 2). it has some minor design flaws (e.g. lack of protection of the qop
> and cipher lists sent by the server, doesn't provide hash agility)
> 3). some features cause pain for sysadmins (e.g. renaming a user
> invalidates SS hash)
>
> I am also seeing general lack of interest in the document. Even though
> it was fun learning new things while working on DIGEST-MD5, I am feeling
> like I am dragging both the carriage and the horse. Which makes me
> wonder if I should continue to spend my time on this document (*).
> Having said that I see some alternatives in moving forward:
>
> 1). Abandon 2831bis. Possibly publish a document moving RFC 2821 to
> Historic. (**)
> 2). Abandon attempts to fix RFC 2831. Publish 2831bis which only
> clarifies ambiguities and fixes obvious bugs. It will document features
> which must not be used due to lack of interoperability. The document
> will not define any new features, i.e. no channel bindings, SASLPrep,
> fixed confidentiality layer, etc. (**)
> 3). Get 2831bis published.
>
> So I would like to poll the WG to see what the WG preference is.
>
> Thanks,
> Alexey
>
> (*) I have 20 or so other documents I am [co-]editing so I would rather
> concentrate on getting them finished.
>
> (**) WG time might be better spent on designing a new mechanism that is
> simpler than DIGEST-MD5 and/or has better properties. I got impressions that
> many people think that it would be nice to have a SASL mechanism which has
> properties similar to the ones provided by DIGEST-MD5.
>
>

Date: Sun, 18 Mar 2007 10:56:30 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Future of DIGEST-MD5
Sender: [email-masked]

Hi folks,
During recent IETF Last Calls on SMTP and POP3 AUTH documents it became
quite clear that implementors didn't like DIGEST-MD5 for the following
reasons:

1). it is complex to implement and has too many options that don't
interoperate well
2). it has some minor design flaws (e.g. lack of protection of the qop
and cipher lists sent by the server, doesn't provide hash agility)
3). some features cause pain for sysadmins (e.g. renaming a user
invalidates SS hash)

I am also seeing general lack of interest in the document. Even though
it was fun learning new things while working on DIGEST-MD5, I am feeling
like I am dragging both the carriage and the horse. Which makes me
wonder if I should continue to spend my time on this document (*).
Having said that I see some alternatives in moving forward:

1). Abandon 2831bis. Possibly publish a document moving RFC 2821 to
Historic. (**)
2). Abandon attempts to fix RFC 2831. Publish 2831bis which only
clarifies ambiguities and fixes obvious bugs. It will document features
which must not be used due to lack of interoperability. The document
will not define any new features, i.e. no channel bindings, SASLPrep,
fixed confidentiality layer, etc. (**)
3). Get 2831bis published.

So I would like to poll the WG to see what the WG preference is.

Thanks,
Alexey

(*) I have 20 or so other documents I am [co-]editing so I would rather
concentrate on getting them finished.

(**) WG time might be better spent on designing a new mechanism that is
simpler than DIGEST-MD5 and/or has better properties. I got impressions 
that many people think that it would be nice to have a SASL mechanism 
which has properties similar to the ones provided by DIGEST-MD5.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Security (crammd5)
Date:  Fri, 16 Mar 2007 13:02:27 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 41
Sender: [email-masked]

Philip Guenther wrote:

  [comparison with 2831bis authentication]
>> CRAM-MD5 still isn't much worse for its purpose:  It only has 
>> no <cnonce> and no <response-auth>.
 
> And no channel bindings, so it's subject to a channel replacement
> attack: you *thought* you were talking to the server over SSL,
> but you were really talking to that MitM.

Yes, I tried to mention that near the begin of my mail as "over TLS
it could be fine (ignoring the issue discussed in a separate thread
wrt 2554bis)".  

Maybe not exactly the same issue, Sam's 2554bis discuss wasn't about
"channel bindings".  And as far as CRAM-MD5 or DIGEST-MD5 are only
used for authentication (not auth-int or auth-conf) I still fail to
see the point of "channel bindings":

Again assuming that folks don't accept TLS certificates just because
they happen to be syntactically valid.

2195 clearly says "CRAM does not support a protection mechanism" and
2195bis states "This mechanism does not provide a security layer".

> If he wants to go the catalog-of-passwords route, he can even supply
> you with his own constant challenge on your first login attempt, and
> then pass through the real server's challenge after you glare at
> your keyboard and try again.

Yes, that's addressed in the 2195bis security considerations.  I did
not claim that a <cnonce> as in DIGEST-MD5 is pointless.  CRAM-MD5 is
better than plain text, "login", APOP, or a derived SMTP-after-APOP
kludge, but it's not what you want to secure say banking transactions.

Wrt a constant challenge it would be better if 2195bis sticks to the
original <msg-id> concept, where that's at least in theory forbidden,
I've noted that in another mail.

Frank

Date: Wed, 14 Mar 2007 14:37:39 -0600
From: Philip Guenther <[email-masked]>
To: Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: Security (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Sender: [email-masked]

On Wed, 14 Mar 2007, Frank Ellermann wrote:
> | CRAM-MD5 is no longer considered to provide adequate protection.
...
> It's also "better" than DIGEST-MD5 where it's easy to implement
> and almost impossible to get it wrong.  Where somebody managed
> to implement 2069 / 2617 / 2831 / 2831bis with their many more
> or less subtle differences CRAM-MD5 still isn't much worse for
> its purpose:  It only has no <cnonce> and no <response-auth>.

And no channel bindings, so it's subject to a channel replacement attack: 
you *thought* you were talking to the server over SSL, but you were really 
talking to that MitM.  If he wants to go the catalog-of-passwords route, 
he can even supply you with his own constant challenge on your first login 
attempt, and then pass through the real server's challenge after you glare 
at your keyboard and try again.

Does anyone recall the expected cost-per-password that Christian Huitema 
claimed for dictionary and bruteforcing CRAM-MD5 traces during in his 
presentation to the apps area meeting in Paris?  My notes simply say 
"cheap".

Philip Guenther

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Security (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date:  Wed, 14 Mar 2007 21:11:29 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 30
Sender: [email-masked]

| CRAM-MD5 is no longer considered to provide adequate protection.

That's not the case, as it depends on the circumstances where
CRAM-MD5 is used.  E.g. over TLS it could be fine (ignoring the
issue discussed in a separate thread wrt 2554bis), and CRAM-MD5
is certainly better than APOP (as stated in 2195) or "LOGIN".

It's also "better" than DIGEST-MD5 where it's easy to implement
and almost impossible to get it wrong.  Where somebody managed
to implement 2069 / 2617 / 2831 / 2831bis with their many more
or less subtle differences CRAM-MD5 still isn't much worse for
its purpose:  It only has no <cnonce> and no <response-auth>.

That's noted in the 3rd paragraph of the security considerations.
Readers are able to draw their own conclusions without this 
"executive summary" at the begin.  Besides there is already
another summary in the intro:

| The mechanism offers inadequate protection against common
| attacks against application-level protocols (see Section 5)
| and is prone to interoperability problems (see Section 4).

Section 5 explains why that's not limited to application-
level protols, therefore this statement could be truncated:

| The mechanism offers inadequate protection against common
| attacks (see Section 5).

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Interoperability (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date:  Wed, 14 Mar 2007 20:40:07 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 21
Sender: [email-masked]

> address feedback to the Working Group mailing list.

| prone to interoperability problems (see Section 4).

If folks used their own kludges to negotiate charsets out of band
it's their problem, not a problem in 2195.  The RFC 822 <msg-id>
in the challenge is clearly ASCII.

RFC 2277 published one year after 2095 clearly mandates to use
UTF-8.  Alexey proposed to add a "SHOULD UTF-8" somewhere, IMO a
"MUST" is clearer.

The only "interoperability problem" left will be to use SASLprep,
and that solves an inherent interoperability problem for Unicode.

RFC 4616 also doesn't spread FUD about alleged "interoperability
problems" wrt SASLprep, so I don't see why that should be needed
here (in chapter 1).

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Limited use (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date:  Wed, 14 Mar 2007 20:13:13 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Tom Yu wrote:

> address feedback to the Working Group mailing list.

| The CRAM-MD5 mechanism is intended to have limited use on the Internet.

That's not the case, as it clearly contradicts what RFC 2195 says.
It's also in conflict with BCP 46, RFC 2244, RFC 2645, and 2554bis.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Random data (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date:  Wed, 14 Mar 2007 20:05:03 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Tom Yu wrote:
 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-08.txt
[...] 
> Please review this document, and address feedback to the Working 
> Group mailing list.

Why does it say "MUST NOT interpret the challenge in any way" ?  It
used to be an STD 11 <msg-id> as described in STD 53 (= different
for each challenge).

"Random data" is NEVER a <msg-id>, it could be the same no matter 
how unlikely that is.  A <msg-id> is supposed to be worldwide unique
_forever_ (the 2195 use of the term "timestamp" also suggests this).

Frank

Date: Tue, 13 Mar 2007 22:36:54 +0000
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: cram draft bug
Sender: [email-masked]

Kurt Zeilenga wrote:

> On Mar 13, 2007, at 2:19 PM, Alexey Melnikov wrote:
>
>> I think it should be: "If the username is in UTF-8, it MUST be well- 
>> formed UTF-8".
>
> In the context of a standardized specification, such a
> statement would seem odd.  Either the text is UTF-8
> encoded or its not UTF-8 encoded.

The document doesn't say that username MUST be in UTF-8. Thus the 
strange wording.
I guess I would also be Ok with removing the comment, but I think saying 
that an implementation may verify UTF-8 for being well-formed would be a 
good thing.

Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: cram draft bug
Date: Tue, 13 Mar 2007 15:20:29 -0700
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

On Mar 13, 2007, at 2:19 PM, Alexey Melnikov wrote:

> I think it should be: "If the username is in UTF-8, it MUST be well- 
> formed UTF-8".

In the context of a standardized specification, such a
statement would seem odd.  Either the text is UTF-8
encoded or its not UTF-8 encoded.

- Kurt

Date: Tue, 13 Mar 2007 21:29:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-crammd5-08.txt
Sender: [email-masked]

I just want to clarify that my previous comments are mostly nitpicking. 
Overall, I am happy with -08.

Date: Tue, 13 Mar 2007 21:27:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-crammd5-08.txt
Sender: [email-masked]

Tom Yu wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>This message commences a Working Group Last Call on the following
>document:
>
>	Title		: The CRAM-MD5 SASL Mechanism
>	Author(s)	: L. Nerenberg
>	Filename	: draft-ietf-sasl-crammd5-08.txt
>	Pages		: 10
>	Date		: 2007-3-7
>  
>
Hi Lyndon,
You've already spotted an inconsistent comment in section 3:

     username   = 1*OCTET
                  ; MUST be well-formed UTF-8.

In section 4:

   The client SHOULD prepare the user name and shared secret strings
   using the SASLprep [RFC4013] profile of the Stringprep [RFC3454]
   algorithm.  The resulting values SHOULD be encoded as UTF-8 [RFC3629]

The second quoted sentence seems to imply that the resulting value should be in UTF-8 only if SASLPrep is applied to it.
I think that use of UTF-8 should be recommended even if SASLPrep is applied (which is likely the common case these days).

   strings.  The server may store the prepared string instead of, or as
   well as, the unprepared string, so that it does not have to prepare
   it every time it is needed for computation.  However, if the original
   (unprepared) string is not stored, it may render the computed secret
   to be incompatible with a future revisions of SASLprep that support
   currently unassigned code points (see section 7 of [RFC3454]).  It is
   therefor recommended to store the unprepared string in the database.

Some other comments:

 I've checked ABNF with Bill Fenner's parser and it passes (not really 
surprised).

Some errors reported by IDnits 2.03.15:

>  Checking nits according to http://www.ietf.org/ID-Checklist.html:
>  * The document seems to lack a both a reference to RFC 2119 and the
>    recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
>    keywords. 
>  
>
Indeed. The reference to RFC 2119 is missing.

>    RFC 2119 keyword, line 93: '...ts).  The client MUST NOT interpret or a...'
>    RFC 2119 keyword, line 103: '...   server MUST ensure the right-most spa...'
>    RFC 2119 keyword, line 124: '...               ; MUST be well-formed UTF...'
>    RFC 2119 keyword, line 148: '...   The client SHOULD prepare the user na...'
>    RFC 2119 keyword, line 150: '...   algorithm.  The resulting values SHOULD be encoded as UTF-8 [RFC3629]...'
>    (1 more instance...)
>  
>
 [...]

>  Checking references for intended status: Proposed Standard
>  - Unused Reference: 'RFC4616' is defined on line 259, but not referenced
>  
>
This reference is not needed, as the text that was comparing CRAM-MD5 
with PLAIN got deleted.

>  - Obsolete informational reference (is this intentional?): RFC 2095
>
Indeed, use RFC 2195 instead.

Date: Tue, 13 Mar 2007 21:19:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
CC: [email-masked]
Subject: Re: cram draft bug
Sender: [email-masked]

Lyndon Nerenberg wrote:

> I just noticed an inconsistency in the -08 draft.  The <username> 
> terminal specifies "MUST be well-formed UTF-8" in contradiction to the 
> "SHOULD be encoded as UTF-8" in section 4.  The section 3 <username> 
> comment needs to be changed to "SHOULD" with a pointer to section 4.

I think it should be: "If the username is in UTF-8, it MUST be 
well-formed UTF-8".

Date: Mon, 12 Mar 2007 16:25:14 -0700 (PDT)
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: cram draft bug
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

I just noticed an inconsistency in the -08 draft.  The <username> terminal 
specifies "MUST be well-formed UTF-8" in contradiction to the "SHOULD be 
encoded as UTF-8" in section 4.  The section 3 <username> comment needs to 
be changed to "SHOULD" with a pointer to section 4.

--lyndon

Date: Mon, 12 Mar 2007 17:09:02 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: SASL WG session at IETF68
Originator-Info: login-token=Mulberry:012lvYLkTDTaImplCvDdkInXHND1lhj1FH0AaTENs=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, March 12, 2007 06:09:23 PM +0100 Frank Ellermann 
<[email-masked]> wrote:

> Finally the second part says implementations won't bother to check the
> certificate, and then PLAIN isn't good enough.  Now that's tricky, if
> it's true

Sadly, it is.  All too many TLS-using applications, especially email 
clients, either completely ignore certificate validation or treat all 
self-signed certificates as trust anchors.  So, mechanisms which do not 
reveal the user's password to the "server" are highly desirable.

-- Jeff

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: SASL WG session at IETF68
Date: Mon, 12 Mar 2007 12:46:41 -0700
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Mar 12, 2007, at 11:27 AM, Frank Ellermann wrote:

> Anyway, if you don't like to replace PLAIN you can either add a
> "SHOULD check cert" (the TLS RFC might have some MUSTard in this
> direction, I'm too lazy to look), or maybe Sam's argument isn't
> correct (?)

IIRC, it is the application protocol specification which
specifies what, if any, TLS certificate verification is
required in its use of TLS.

-- Kurt 

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SASL WG session at IETF68
Date:  Mon, 12 Mar 2007 19:27:49 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

Alexey Melnikov wrote:

>> Finally the second part says implementations won't bother
>> to check the certificate, and then PLAIN isn't good enough.

> This is the part I would like to discuss.
 
>> Now that's tricky, if it's true you could as well replace
>> the "MUST do PLAIN" by a "MUST do CRAM-MD5",
[both over TLS, obviously]

> This wouldn't fly for a set of reasons I wouldn't repeat here.

I don't recall any discussion involving you about "CRAM-MD5 over
TLS" here (or elsewhere).  But I don't read this list very long,
if it was before 2005 I've certainly missed it.

Anyway, if you don't like to replace PLAIN you can either add a
"SHOULD check cert" (the TLS RFC might have some MUSTard in this
direction, I'm too lazy to look), or maybe Sam's argument isn't
correct (?)

Frank

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: Alternative password SASL authentication mechanims
Date: Mon, 12 Mar 2007 10:53:32 -0700
To: Steven Simon <[email-masked]>
Sender: [email-masked]

On Mar 12, 2007, at 8:19 AM, Steven Simon wrote:
> I have a suggestion for this method that probably runs counter to  
> traditional security practices:
> Leave the realm out of the hash.

By "this method" I assume you refer to HEXA and not YAP (even though  
you quoted only the
YAP abstract in your message) as the realm concept is purposely  
absent from YAP.

-- Kurt

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: Alternative password SASL authentication mechanims
Date: Mon, 12 Mar 2007 10:50:43 -0700
To: Simon Josefsson <[email-masked]>
Sender: [email-masked]

On Mar 12, 2007, at 3:52 AM, Simon Josefsson wrote:
> Why not define these new password-based mechanisms as GSS-API
> mechanisms and use them under GS2?

Ease specification and ease of implementation.  At least for me, it
is far easier to specify and implement a mechanism like YAP as a
SASL mechanism than as a GSS-API mechanism.  Anyone who thinks
otherwise is certainly free to show me that I'm wrong by producing
an easy-to-understand and easy-to-implement I-D specifying YAP as a
GSS-API mechanism.

Beyond this, well, see Jeffrey's comments.

> This suggestion assume that nobody intends to use these password-based
> SASL mechanisms without a secure channel (e.g., TLS).  Does that
> assumption hold?

YAP require a secure channel.

-- Kurt

Date: Mon, 12 Mar 2007 17:21:21 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: SASL WG session at IETF68
Sender: [email-masked]

Frank Ellermann wrote:

>Alexey Melnikov wrote:
> 
>  
>
>>Sam posted a DISCUSS on draft-siemborski-rfc2554bis-08.txt (SMTP AUTH).
>>The DISCUSS is in relationship to use of SASL PLAIN over TLS.
>>If I can't clear the DISCUSS this week, I would like to discuss it
>>during the meeting, because I think this is a general issue regarding
>>use of SASL PLAIN in protocols.
>>    
>>
>The [Discuss] has two parts.  The first part claims that 4616 requires
>TLS as some kind of "default", but I don't see this in 4616.  Saying
>that PLAIN must not be advertised / negotiated without TLS should be
>good enough, and the I-D like 4616 do this.
>  
>
I've already addressed this part in the way you describe.

>The second part says that all implementations must implement STARTTLS.
>That's implied by the "MUST implement PLAIN", but saying so explicitly
>in the same paragraph with "MUST implement PLAIN" can't hurt.
>
>Finally the second part says implementations won't bother to check the
>certificate, and then PLAIN isn't good enough.
>
This is the part I would like to discuss.

>Now that's tricky, if it's true you could as well replace the "MUST do PLAIN" by a "MUST do
>CRAM-MD5",
>
This wouldn't fly for a set of reasons I wouldn't repeat here.

>remove the old "MAY CRAM-MD5", add a "SHOULD STARTTLS", and
>remove most of the PLAIN discussion, because it's just what 4616 says.
>  
>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SASL WG session at IETF68
Date:  Mon, 12 Mar 2007 18:09:23 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 25
Sender: [email-masked]

Alexey Melnikov wrote:
 
> Sam posted a DISCUSS on draft-siemborski-rfc2554bis-08.txt (SMTP AUTH).
> The DISCUSS is in relationship to use of SASL PLAIN over TLS.
> If I can't clear the DISCUSS this week, I would like to discuss it
> during the meeting, because I think this is a general issue regarding
> use of SASL PLAIN in protocols.

The [Discuss] has two parts.  The first part claims that 4616 requires
TLS as some kind of "default", but I don't see this in 4616.  Saying
that PLAIN must not be advertised / negotiated without TLS should be
good enough, and the I-D like 4616 do this.

The second part says that all implementations must implement STARTTLS.
That's implied by the "MUST implement PLAIN", but saying so explicitly
in the same paragraph with "MUST implement PLAIN" can't hurt.

Finally the second part says implementations won't bother to check the
certificate, and then PLAIN isn't good enough.  Now that's tricky, if
it's true you could as well replace the "MUST do PLAIN" by a "MUST do
CRAM-MD5", remove the old "MAY CRAM-MD5", add a "SHOULD STARTTLS", and
remove most of the PLAIN discussion, because it's just what 4616 says.

Frank

Date: Mon, 12 Mar 2007 12:19:55 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Alternative password SASL authentication mechanims
Originator-Info: login-token=Mulberry:01cHhGJdrgu5m8w76mo/Z2lAfqfVD3rL/d7XSKpvg=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, March 12, 2007 11:52:46 AM +0100 Simon Josefsson 
<[email-masked]> wrote:

> I have one idea/suggestion for these new password-based SASL
> authentication mechanisms: have them prefix the initial message with
> the mechanism-independent GSS-API token tag (see RFC 2743 section
> 3.1).  That would allows these SASL protocols to more easily be
> re-used as GSS-API mechanism protocols.  What do people think?

This does not seem like a good idea.  The protocol element in question is 
used in the GSS-API to allow negotiation mechanisms to identify the GSS-API 
mechanism which created a particular token; it includes a GSS-API mechanism 
OID.  Including such a tag in a SASL token would be meaningless to SASL, 
and would require the assignment of an OID to identify a GSS-API mechanism 
that is not actually being defined.

It might allow the initial SASL token to be used as an initial GSS-API 
token, but that wouldn't be true for all tokens, and it wouldn't save you 
from actually writing the specification for the GSS mechanism.  It would 
also create significant confusion the first time the GSS mechanism spec 
evolved to the point where a new OID was required.

The right way to go about this is either to simultaneously defined SASL, 
GSS-API, and EAP mechanisms based on the same underlying technology, or to 
do this:

> Why not define these new password-based mechanisms as GSS-API
> mechanisms and use them under GS2?  If you look at the bytes sent on
> the wire, there would not be that much differences.  The difference is
> the addition of the GS2 headers, and the GSS-API mechanism-independent
> token tag.

> If we go this route, we could eventually close the SASL registry, and
> make all future work be done within the GSS-API context instead.

Unfortunately not.  The SASL and GSS-API frameworks have different 
properties, which means there are some technologies for which a SASL 
mechanism can be defined which provides functionality that could not be 
obtained from a GSS-API mechanism, if one could be defined at all.  The 
most common example of this is technologies which provide a protected 
channel with sequencing -- the GSS-API supports reporting missing or 
out-of-sequence messages but leaves it up to the caller to decide what to 
do about them; a technology which cannot do the latter cannot provide 
sequencing protection to GSS-API applications, and in fact it may not be 
possible to define a GSS mechanism at all for such a technology.  However, 
it would still be possible and even useful to directly define a SASL 
mechanism.

> I believe that what we specify for wide use that should, at the very
> least, offer integrity protection.  Therefor, all these password-based
> authentication mechanism should require a secure channel, or specify
> its own secure channel.  Given DIGEST-MD5, the second approach of
> specifying its own secure channel seems like a bad choice.  Thus,
> relying on some external secure channel, like TLS or IPSEC, through
> channel bindings, seems like a good solution.

I agree that it is a bad idea to attempt to define a security layer for a 
SASL mechanism built on technology which does not already provide that 
functionality.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-07.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 12 Mar 2007 17:00:57 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

>>> Only one editorial issue in section 14 (Security Considerations):
>>>
>>>>        This solution, however, is not guaranteed
>>>>        to the lead to the mutually most secure mechanism, and is
>>>
>>> I think "the" needs to be removed here.
>>
>> I agree.  Removed, thanks.
>>
>>> I understand what this sentence is trying to say, but it doesn't
>>> quite read correctly even after removing of the "the".
>>
>> I tried to rephrase it, but couldn't come up with something that quite
>> said exactly the same thing and were more readable.  Suggestions
>> welcome...
>
> "... to the most secure mechanism supported by both parties" ?

Installed, thanks!

/Simon

Date: Mon, 12 Mar 2007 11:51:22 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-07.txt
Originator-Info: login-token=Mulberry:01Um1Q/LzVxXCeuMh9heuAa+nfhyfZocm/4n5hiO0=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, March 12, 2007 12:50:01 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

>
> Alexey Melnikov <[email-masked]> writes:
>
>> Kurt Zeilenga wrote:
>>
>>> This message initiates a SASL Working Group Last Call on the
>>> document:
>>>
>>>   Title:     Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
>>>   Editor:    S. Josefsson
>>>   Filename:  draft-ietf-sasl-gs2-07.txt
>>>
>>> The purpose of this WG Last Call is to ensure that the Working
>>> Group has achieved consensus that the document is suitable for
>>> publication on the Standards Track.
>>>
>>> Please review the document for both technical and editorial
>>> problems.  Technical issues should be discussed on this list.
>>> Editorial issues may be sent to the document editor.  In
>>> the case that a reviewer finds no technical issues, the
>>> reviewer should send a note to the WG chairs indicating
>>> so.
>>>
>>> Reviewers are asked to consider the suitability of the documents
>>> referenced, in particular Channel Binding drafts, by this I-D for
>>> this I-D's purposes.  Note that this is not a request to review
>>> anew each referenced document.  Referenced documents have either
>>> been, or will be, subjected to appropriate review before publication.
>>> This consideration is intended only to ensure this I-D is suitable
>>> for publication on the Standards Track.
>>>
>>> The Last Call period will close on Tuesday, 20 March 2007.
>>
>> Only one editorial issue in section 14 (Security Considerations):
>>
>>>        This solution, however, is not guaranteed
>>>        to the lead to the mutually most secure mechanism, and is
>>
>> I think "the" needs to be removed here.
>
> I agree.  Removed, thanks.
>
>> I understand what this sentence is trying to say, but it doesn't
>> quite read correctly even after removing of the "the".
>
> I tried to rephrase it, but couldn't come up with something that quite
> said exactly the same thing and were more readable.  Suggestions
> welcome...

"... to the most secure mechanism supported by both parties" ?

-- Jeff

Cc: [email-masked]
From: Steven Simon <[email-masked]>
Subject: Re: Alternative password SASL authentication mechanims
Date: Mon, 12 Mar 2007 08:19:55 -0700
To: Kurt Zeilenga <[email-masked]>
Sender: [email-masked]

--Apple-Mail-2--15416702
Content-Type: multipart/alternative;
	boundary=Apple-Mail-1--15416770

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

I have a suggestion for this method that probably runs counter to  
traditional security practices:
Leave the realm out of the hash.

This auth method is nice because it takes the username first, which  
allows us to route the
authentication to the correct server before having to generate a  
challenge.

Hashing in a realm causes problems with administration. For example,  
with the realm hashed in,
it's impossible for us to dynamically add a user to a new apache  
realm. The password must be
reset so the server gets a chance to rehash the cleartext for the new  
realm. This issue has been a
disappointment with DIGEST-MD5 for us. There are similar problems  
with backup/restore/migration
if servers are replaced or the network topology is reorganized.

In theory, the realm protects against replay at a different realm,  
but in practice there are other ways to do that.
One could add the realm to the challenge, for example.

On a side note, I'll also make a plug for using SHA-256 as the  
mandatory hash. MD5 (and SHA1) are
being phased out.

- Steven Simon

On Mar 11, 2007, at 6:10 PM, Kurt Zeilenga wrote:

> Title		: SASL Yet Another Password Mechanism
> Author(s)	: K. Zeilenga
> Filename	: draft-zeilenga-sasl-yap-00.txt
> Pages		: 7
> Date		: 2007-2-27
> 	
>   This document describes a password authentication mechanism, called
>   YAP-SHA-256, for use in protocols support Simple Authentication and
>   Security Layer (SASL) framework.  The mechanism relies on security
>   services provided by a lower layer, such as Transport Layer Security
>   (TLS), to protect the authentication exchange, and subsequent
>   application data exchange, from common attacks.  The YAP-SHA-256
>   mechanism may be viewed as an alternative to other password-based  
> SASL
>   mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5.

--Apple-Mail-1--15416770
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">I have a suggestion for this =
method that probably runs counter to traditional security =
practices:<DIV>Leave the realm out of the hash.</DIV><DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>This auth method is nice =
because it takes the username first, which allows us to route =
the</DIV><DIV>authentication to the correct server before having to =
generate a challenge.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Hashing in a realm causes =
problems with administration. For example, with the realm hashed =
in,=A0</DIV><DIV>it's impossible for us to dynamically add a user to a =
new apache realm. The password must be</DIV><DIV>reset so the server =
gets a chance to rehash the cleartext for the new realm. This issue has =
been a</DIV><DIV>disappointment with DIGEST-MD5 for us. There are =
similar=A0problems with=A0backup/restore/migration</DIV><DIV>if servers =
are replaced or the network topology is reorganized.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>In theory, the =
realm=A0protects against replay at a different realm, but in practice =
there are other ways to do that.</DIV><DIV>One could add the realm to =
the challenge, for example.=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>On a side note, I'll also =
make a plug for using SHA-256 as the mandatory hash. MD5 (and SHA1) =
are</DIV><DIV>being phased out.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>- Steven =
Simon</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR><DIV><DIV>On Mar 11, =
2007, at 6:10 PM, Kurt Zeilenga wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Title<SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>: SASL =
Yet Another Password Mechanism</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">Author(s)<SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>: K. Zeilenga</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Filename<SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>: =
draft-zeilenga-sasl-yap-00.txt</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">Pages<SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>: 7</FONT></P> <P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Date<SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>: 2007-2-27</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</SPAN></FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>This document describes a =
password authentication mechanism, called</FONT></P> <P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><SPAN class=3D"Apple-converted-space">=A0=
 </SPAN>YAP-SHA-256, for use in protocols support Simple Authentication =
and</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Security Layer (SASL) =
framework.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>The mechanism =
relies on security</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica"><SPAN class=3D"Apple-converted-space">=A0 </SPAN>services =
provided by a lower layer, such as Transport Layer Security</FONT></P> =
<P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>(TLS), to protect the =
authentication exchange, and subsequent</FONT></P> <P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><SPAN class=3D"Apple-converted-space">=A0=
 </SPAN>application data exchange, from common attacks.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>The YAP-SHA-256</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>mechanism may be viewed as an =
alternative to other password-based SASL</FONT></P> <P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><SPAN class=3D"Apple-converted-space">=A0=
 </SPAN>mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5.</FONT></P> =
</BLOCKQUOTE></DIV><BR></DIV></DIV></BODY></HTML>=

--Apple-Mail-1--15416770--

--Apple-Mail-2--15416702
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-2--15416702--

Date: Mon, 12 Mar 2007 13:11:48 +0000
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: SASL WG session at IETF68
Sender: [email-masked]

I would like to request one minor addition to the agenda:

Sam posted a DISCUSS on draft-siemborski-rfc2554bis-08.txt (SMTP AUTH). 
The DISCUSS is in relationship to use of SASL PLAIN over TLS.
If I can't clear the DISCUSS this week, I would like to discuss it 
during the meeting, because I think this is a general issue regarding 
use of SASL PLAIN in protocols.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-07.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 12 Mar 2007 12:50:01 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Kurt Zeilenga wrote:
>
>> This message initiates a SASL Working Group Last Call on the
>> document:
>>
>>   Title:     Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
>>   Editor:    S. Josefsson
>>   Filename:  draft-ietf-sasl-gs2-07.txt
>>
>> The purpose of this WG Last Call is to ensure that the Working
>> Group has achieved consensus that the document is suitable for
>> publication on the Standards Track.
>>
>> Please review the document for both technical and editorial
>> problems.  Technical issues should be discussed on this list.
>> Editorial issues may be sent to the document editor.  In
>> the case that a reviewer finds no technical issues, the
>> reviewer should send a note to the WG chairs indicating
>> so.
>>
>> Reviewers are asked to consider the suitability of the documents
>> referenced, in particular Channel Binding drafts, by this I-D for
>> this I-D's purposes.  Note that this is not a request to review
>> anew each referenced document.  Referenced documents have either
>> been, or will be, subjected to appropriate review before publication.
>> This consideration is intended only to ensure this I-D is suitable
>> for publication on the Standards Track.
>>
>> The Last Call period will close on Tuesday, 20 March 2007.
>
> Only one editorial issue in section 14 (Security Considerations):
>
>>        This solution, however, is not guaranteed
>>        to the lead to the mutually most secure mechanism, and is
>
> I think "the" needs to be removed here.

I agree.  Removed, thanks.

> I understand what this sentence is trying to say, but it doesn't
> quite read correctly even after removing of the "the".

I tried to rephrase it, but couldn't come up with something that quite
said exactly the same thing and were more readable.  Suggestions
welcome...

/Simon

Date: Sun, 11 Mar 2007 11:59:03 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-07.txt
Sender: [email-masked]

Kurt Zeilenga wrote:

> This message initiates a SASL Working Group Last Call on the
> document:
>
>   Title:     Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
>   Editor:    S. Josefsson
>   Filename:  draft-ietf-sasl-gs2-07.txt
>
> The purpose of this WG Last Call is to ensure that the Working
> Group has achieved consensus that the document is suitable for
> publication on the Standards Track.
>
> Please review the document for both technical and editorial
> problems.  Technical issues should be discussed on this list.
> Editorial issues may be sent to the document editor.  In
> the case that a reviewer finds no technical issues, the
> reviewer should send a note to the WG chairs indicating
> so.
>
> Reviewers are asked to consider the suitability of the documents
> referenced, in particular Channel Binding drafts, by this I-D for
> this I-D's purposes.  Note that this is not a request to review
> anew each referenced document.  Referenced documents have either
> been, or will be, subjected to appropriate review before publication.
> This consideration is intended only to ensure this I-D is suitable
> for publication on the Standards Track.
>
> The Last Call period will close on Tuesday, 20 March 2007.

Only one editorial issue in section 14 (Security Considerations):

>        This solution, however, is not guaranteed
>        to the lead to the mutually most secure mechanism, and is

I think "the" needs to be removed here. I understand what this sentence 
is trying to say, but it doesn't quite read correctly even after 
removing of the "the".

>        therefor only recommended as an additional precaution.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: Alternative password SASL authentication mechanims
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 12 Mar 2007 11:52:46 +0100
Sender: [email-masked]

Interesting documents!

I have one idea/suggestion for these new password-based SASL
authentication mechanisms: have them prefix the initial message with
the mechanism-independent GSS-API token tag (see RFC 2743 section
3.1).  That would allows these SASL protocols to more easily be
re-used as GSS-API mechanism protocols.  What do people think?

I'm working on a password-based GSS-API authentication mechanism, for
use with GS2, which would be quite similar to these protocols too.
That work lead me to the following ideas...:

Why not define these new password-based mechanisms as GSS-API
mechanisms and use them under GS2?  If you look at the bytes sent on
the wire, there would not be that much differences.  The difference is
the addition of the GS2 headers, and the GSS-API mechanism-independent
token tag.

If we go this route, we could eventually close the SASL registry, and
make all future work be done within the GSS-API context instead.

This suggestion assume that nobody intends to use these password-based
SASL mechanisms without a secure channel (e.g., TLS).  Does that
assumption hold?

I believe that what we specify for wide use that should, at the very
least, offer integrity protection.  Therefor, all these password-based
authentication mechanism should require a secure channel, or specify
its own secure channel.  Given DIGEST-MD5, the second approach of
specifying its own secure channel seems like a bad choice.  Thus,
relying on some external secure channel, like TLS or IPSEC, through
channel bindings, seems like a good solution.

/Simon

Date: Mon, 12 Mar 2007 07:29:42 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: [email-masked]
Subject: Re: Alternative password SASL authentication mechanims
Sender: [email-masked]

At 2007-03-11 18:10:21 -0700, [email-masked] wrote:
>
> I draw your attention to two individual submissions proposing new
> password SASL authentications mechanisms as alternatives...

There's also this one:

Title    : Salted Challenge Response Authentication Mechanism (SCRAM)
Author(s): Abhijit Menon-Sen, Chris Newman
Filename : draft-newman-auth-scram-04.txt
Pages    : 12
Date     : 2007-03-08

Abstract

    The secure authentication mechanism most widely deployed and used by
    Internet application protocols, is the transmission of clear-text
    passwords over a channel protected by Transport Layer Security
    (TLS).  There are some significant security concerns with that
    mechanism which could be addressed by the use of a challenge
    response authentication mechanism protected by TLS. Unfortunately,
    the challenge response mechanisms presently on the standards track
    all fail to meet requirements necessary for widespread deployment
    and have had success only in limited use.

    This specification describes the Salted Challenge Response
    Authentication Mechanism (SCRAM) which addresses the deployability
    requirements.  When used in combination with Transport Layer
    Security or an equivalent security layer, this mechanism could
    improve the status-quo for application protocol authentication and
    provide a suitable choice for a mandatory-to-implement mechanism for
    future application protocol standards.

-- ams

To: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Alternative password SASL authentication mechanims
Date: Sun, 11 Mar 2007 18:10:21 -0700
Sender: [email-masked]

I draw your attention to two individual submissions proposing new
password SASL authentications mechanisms as alternatives...

Title		: The Hash Exchange Authentication SASL Mechanism
Author(s)	: D. Cridland, A. Melnikov
Filename	: draft-cridland-sasl-hexa-00.txt
Pages		: 12
Date		: 2007-2-28
	
    This memo defines and discusses a SASL mechanism that is based on  
the
    exchange of hashes.  It does not require the storage of a plaintext
    equivalent on the server, is simple to implement, and provides a
    reasonable level of security.

Title		: SASL Yet Another Password Mechanism
Author(s)	: K. Zeilenga
Filename	: draft-zeilenga-sasl-yap-00.txt
Pages		: 7
Date		: 2007-2-27
	
   This document describes a password authentication mechanism, called
   YAP-SHA-256, for use in protocols support Simple Authentication and
   Security Layer (SASL) framework.  The mechanism relies on security
   services provided by a lower layer, such as Transport Layer Security
   (TLS), to protect the authentication exchange, and subsequent
   application data exchange, from common attacks.  The YAP-SHA-256
   mechanism may be viewed as an alternative to other password-based  
SASL
   mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5.

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-crammd5-08.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 11 Mar 2007 11:10:39 +0100
Sender: [email-masked]

I re-read the latest draft and it looks fine to me.  Good work!

/Simon

To: [email-masked]
Subject: WG Last Call: draft-ietf-sasl-crammd5-08.txt
From: Tom Yu <[email-masked]>
Date: Fri, 09 Mar 2007 16:57:45 -0500
Lines: 19
Sender: [email-masked]

This message commences a Working Group Last Call on the following
document:

	Title		: The CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-08.txt
	Pages		: 10
	Date		: 2007-3-7

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

The Last Call will expire on Friday, March 23, 2007.

Please review this document, and address feedback to the Working Group
mailing list.

Tom Yu, SASL WG co-chair

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-08.txt 
Date: Wed, 07 Mar 2007 15:50:03 -0500
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		: The CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-08.txt
	Pages		: 10
	Date		: 2007-3-7
	
This document defines a simple challenge-response authentication
   mechanism, using a keyed MD5 digest, for use with the Simple
   Authentication and Security Layer (SASL).

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sasl-crammd5-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-crammd5-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-crammd5-08.txt

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

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

--OtherAccess--

--NextPart--

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-07.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 07 Mar 2007 10:23:15 +0100
Sender: [email-masked]

Tom Yu <[email-masked]> writes:

> Minor error which can probably fixed in AUTH48:
>
> I went to double-check the Base32-encoded mechanism names, and
> discovered that the krb5 mechanism name in the draft,
>
> GS2-QLJHGJLWNPLNQRNK
>
> is off by one character from the value I computed,
>
> GS2-QLJHGJLWNPLMQRNK

Nice catch!

I have fixed this in my local copy, changes since -07:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--07.diff.html

I agree that this may be fixed during AUTH48, although if a -08 will
be needed for other reasons, this fix will definitely be in it.

Thanks,
Simon

To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-07.txt
From: Tom Yu <[email-masked]>
Date: Tue, 06 Mar 2007 19:04:39 -0500
Lines: 55
Sender: [email-masked]

Minor error which can probably fixed in AUTH48:

I went to double-check the Base32-encoded mechanism names, and
discovered that the krb5 mechanism name in the draft,

GS2-QLJHGJLWNPLNQRNK

is off by one character from the value I computed,

GS2-QLJHGJLWNPLMQRNK

Note the off-by-one ("N" vs "M") in the 12th position of the
Base32-encoded string, which is probably due to a typo; the
corresponding list of 5-bit values rendered as decimal appears to be
correct.  Starting from the truncated SHA-1 hash

82 D2 73 25 76 6B D6 C8 45 AA

we have (hex, binary, decimal, Base32)

-------+-------+-------+-------+-------
   8   |   2   |   D   |   2   |   7
-------+-------+-------+-------+-------
1 0 0 0|0|0 1 0|1 1|0 1|0 0 1|0|0 1 1 1
---------+---------+---------+---------
   16    |   11    |    9    |    7
    Q    |    L    |    J    |    H
---------+---------+---------+---------

-------+-------+-------+-------+-------
   3   |   2   |   5   |   7   |   6
-------+-------+-------+-------+-------
0 0 1 1|0|0 1 0|0 1|0 1|0 1 1|1|0 1 1 0
---------+---------+---------+---------
    6    |    9    |   11    |   22
    G    |    J    |    L    |    W
---------+---------+---------+---------

-------+-------+-------+-------+-------
   6   |   B   |   D   |   6   |   C
-------+-------+-------+-------+-------
0 1 1 0|1|0 1 1|1 1|0 1|0 1 1|0|1 1 0 0
---------+---------+---------+---------
   13    |   15    |   11    |   12
    N    |    P    |    L    |    M
---------+---------+---------+---------

-------+-------+-------+-------+-------
   8   |   4   |   5   |   A   |   A
-------+-------+-------+-------+-------
1 0 0 0|0|1 0 0|0 1|0 1|1 0 1|0|1 0 1 0
---------+---------+---------+---------
   16    |   17    |   13    |   10
    Q    |    R    |    N    |    K
---------+---------+---------+---------

Date: Tue, 6 Mar 2007 10:35:50 -0800 (PST)
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: CRAM-MD5 draft 8 pushed
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

While it works its way through the I-D queue you can find a copy at

   http://orthanc.ca/draft-ietf-sasl-crammd5-08.txt

--lyndon

To: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: WG Last Call: draft-ietf-sasl-gs2-07.txt
Date: Mon, 5 Mar 2007 17:21:38 -0800
Sender: [email-masked]

This message initiates a SASL Working Group Last Call on the
document:

   Title:     Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
   Editor:    S. Josefsson
   Filename:  draft-ietf-sasl-gs2-07.txt

The purpose of this WG Last Call is to ensure that the Working
Group has achieved consensus that the document is suitable for
publication on the Standards Track.

Please review the document for both technical and editorial
problems.  Technical issues should be discussed on this list.
Editorial issues may be sent to the document editor.  In
the case that a reviewer finds no technical issues, the
reviewer should send a note to the WG chairs indicating
so.

Reviewers are asked to consider the suitability of the documents
referenced, in particular Channel Binding drafts, by this I-D for
this I-D's purposes.  Note that this is not a request to review
anew each referenced document.  Referenced documents have either
been, or will be, subjected to appropriate review before publication.
This consideration is intended only to ensure this I-D is suitable
for publication on the Standards Track.

The Last Call period will close on Tuesday, 20 March 2007.

Upon completion of the WG Last Call, the WG chair(s) will take
action based upon the consensus of the WG.  Possible actions
include:

   1) recommending to the IETF Security Area Directors
      that the document, after possible editorial or
      other minor changes, be considered by the IESG
      for publication as a Standard Track RFC; or

   2) requiring that outstanding issues be adequately
      addressed prior to further action (including,
      possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members
to ensure the quality of our documents.  So, please read and
comment!

Kurt Zeilenga, SASL WG co-chair

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-12.txt 
Date: Mon, 05 Mar 2007 18:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Using Digest Authentication as a SASL Mechanism
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-rfc2831bis-12.txt
	Pages		: 48
	Date		: 2007-3-5
	
This specification defines how HTTP Digest Authentication (RFC 2617)
   can be used as a Simple Authentication and Security Layer (SASL, RFC
   4422) mechanism for any protocol that has a SASL profile. It is
   intended both as an improvement over CRAM-MD5 (RFC 2195) and as a
   convenient way to support a single authentication mechanism for web,
   mail, LDAP, and other protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-12.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sasl-rfc2831bis-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-12.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-rfc2831bis-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: remaining DIGEST-MD5 items?
Date:  Fri, 02 Mar 2007 16:07:42 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 48
Sender: [email-masked]

Alexey Melnikov wrote:

 [LWSP => folded continuation lines containing only white space]
> ACAP uses strings with explicit length, so this is not a problem
> for ACAP.

Okay.

> HTTP is not a protocol supporting SASL.

ACK, a future 2617bis can tackle this.  It should also explain the
various fallback strategies, e.g. when to use 2069 instead of 2617,
or when to use a future 2617bis "prep" instead of 2617.

  [unescaping quoted pairs]
>> I looked into Simon's GNU SASL code, and found no hint that he
>> tries to get rid of backslashes anywhere
[...]
> He confirmed that this can be a bug rather than a feature, i.e.
> he hasn't thought about the issue when coding. But for now I've
> suggested that he leaves his code as is.

IOW some code in the wild does _NOT_ unescape quoted pairs.  For
backwards compatibility you could decree that applications MUST NOT
generate or use \\, \", or other quoted pairs.  On that firm ground
they could still accept it, either as is (old) or unescaped (new).

Of course "accept as is" is a weird strategy for arbitrary quoted
pairs excluding \\ and \".  If quoted pairs are anyway illegal it
should be no showstopper.

> I still need to send a message to the HTTP mailing list to confirm
> what people are doing

Maybe you can use Henrik's "loginmgr" on the tools server for tests.
I tried that once (checking that my Digest-MD5 script in theory, and
that a submitted 2069 erratum is no nonsense), but that was a hack.

> Hopefully I will get around to doing that before the upcoming
> Prague IETF.

It's not urgent.  There are enough interesting drafts like the new
I-D.zeilenga-sasl-yap-00 or I-D.cridland-sasl-hexa-00.

Nothing for MD5 "fans" like me unfortunately... ;-)

Frank

Date: Fri, 02 Mar 2007 11:37:11 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: remaining DIGEST-MD5 items?
Sender: [email-masked]

Frank Ellermann wrote:

>Alexey Melnikov wrote:
>  
>
>>This particular thing causes no harm in SASL, as it is not being used
>>inside RFC 2822 messages.
>>    
>>
>Relevant for 2617bis, where the Auth digest stuff isn't B64-encoded.
>  
>
Correct.

>Do _all_ SASL-applications use B64 ?
>
No.

>Checking, no, ACAP (RFC 2244) apparently uses lines of plain text, no LWSP folding at all, let alone
>continuation lines consisting only of trailing white space.
>  
>
But ACAP uses strings with explicit length, so this is not a problem for 
ACAP.

Note that in general any protocol supporting SASL must be capable of 
transporting arbitrary data, include CRLFs and NULs.
And HTTP is not a protocol supporting SASL.

>>>Maybe a case for a MUST NOT generate + MUST accept (?)
>>>      
>>>
>>I think "SHOULD NOT generate LWS + MUST accept them" is more reasonable,
>>as there might be implementations that already use them. And I would
>>rather not declare them non compliant just for that.
>>    
>>
>The 2822 <obs-FWS> is a MUST NOT.   The main point here is to mention
>the (potential) issue somewhere in the prose, SHOULD NOT is also fine.
>  
>
>>>I still don't know if your're really really sure about your new and
>>>in theory incompatible with 2831/2617/2069 "backslash unescaping"
>>>_within_ <qdstr-value>.
>>>      
>>>
>>I always thought that "unquoting" also means removing any escaping
>>backslashes. I might be wrong on this.
>>    
>>
>I looked into Simon's GNU SASL code, and found no hint that he tries
>to get rid of backslashes anywhere - or is that a feature of asprintf ?
>Apparently his Digest-MD5 code is 2831 (written 2006), not 2831bis.
>  
>
He confirmed that this can be a bug rather than a feature, i.e. he 
hasn't thought about the issue when coding. But for now I've suggested 
that he leaves his code as is.

>>I haven't seen anybody using backslashes in DIGEST-MD5 except for 
>>Microsoft implementation, which uses them in usernames.  I think I 
>>need to do some testing to confirm one way or the other.
>>    
>>
>"Take <qdstr-val> as is (after removing the quotes)" could be a very
>simple solution, if folks always escape a '\' and '"' as '\\' or '\"',
>and otherwise stay away from <quoted-pair>.
>  
>
I still need to send a message to the HTTP mailing list to confirm what 
people are doing, plus I need to test Microsoft's implementation.
Hopefully I will get around to doing that before the upcoming Prague IETF.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gs2-07.txt 
Date: Thu, 01 Mar 2007 15:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)	: S. Josefsson
	Filename	: draft-ietf-sasl-gs2-07.txt
	Pages		: 34
	Date		: 2007-3-1
	
This document describes how to use a Generic Security Service
   Application Program Interface (GSS-API) mechanism in the the Simple
   Authentication and Security Layer (SASL) framework.  This is done by
   defining a new SASL mechanism family, called GS2.  This mechanism
   family offers a number of improvements over the previous SASL/GSS-API
   mechanism: it is more general, uses fewer messages for the
   authentication phase in some cases, and supports a SASL-specific
   notion of channel binding.

   See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sasl-gs2-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-gs2-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-gs2-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-gs2-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--