Subject: draft-josefsson-password-auth-00.txt

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 Mar 2007 15:03:42 +0200

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

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 08:17:16 -0500

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

[...]
> for other resources related to this effort, see:

Not another mailing list... :/  :)

> eventually be possible to use it in SASL anyway.

Agreed.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 Mar 2007 15:33:33 +0200

> whatever the mech uses internally.  And there's the exported name token

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

Excellent!

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 08:42:56 -0500

> >        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: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 08:57:43 -0500

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

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Mar 2007 16:28:30 +0200 (MEST)

> distribute the output of the first step as the verifier for all servers

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Mar 2007 16:48:50 +0200 (MEST)

> distribute the output of the first step as the verifier for all servers

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: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 10:21:29 -0500

> and for those the authentication scheme usually does not have

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: Martin Rex <[email-masked]>
Date: Thu, 29 Mar 2007 18:08:33 +0200 (MEST)

> authentication is requested then the password should be salted with the
 
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: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 11:17:01 -0500

> 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: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 11:28:40 -0500

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 16:15:14 -0500

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

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Mar 2007 00:11:16 +0200 (MEST)

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 17:37:56 -0500

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

> 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

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]>
Date: Fri, 30 Mar 2007 00:50:43 +0200 (MEST)

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

> associated with some secure channel below the application layer is not a

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Mar 2007 17:59:00 -0500

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

> a particular combination of challenge and response is acceptable.

Yes, proxying should be acceptable.

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