Subject: Re: SCRAM-04 questions
From: Chris Newman <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Date: Thu, 28 Jun 2007 01:10:36 -0700
List-Id: <ietf-sasl.imc.org>

Frank Ellermann wrote on 6/16/07 19:58 +0200:
> Hi, I tried to implement SCRAM-04 based on MD5.  Some problems:
>
> 1 - The I-D uses B64 as specified in RFC 2045, but the example
>     strings s=PxR/wv+epq and c=QWBv+XbwcaI/wp are "ambiguous",
>     compare RFC 4648.
>
>     Do you mean s=PxR/wv+epqA= and c=QWBv+XbwcaI/wpA= ?
>
>     For n= and a= names the I-D encodes '=' as '=3D', and maybe
>     you tried to avoid B64 '=' padding using the UTF-7 version.
>
>     IMO you could just use hex. instead B64 for s=, c=, p=, and
>     v= (at least for p= and v= the encoded length is irrelavant).

The examples are placeholders and don't contain valid data yet.  This is fairly 
preliminary -- more about circulating the idea than "implement now" level.  I'm 
hoping it will merge with the HEXA proposal and add channel bindings.  But that 
decision will be made by the primary editor (not me).

> 2 - The terms in the algorithm overview confused me.  There's a
>     StoredKey = H( ClientKey ) with ClientKey = H( SaltedPw ),
>     but the server needs ServerKey = HMAC( SaltedPw, salt ).  So
>     apparently the server has to "store" the SaltedPw, while a
>     client likely doesn't store any password at all, it gets the
>     original password as input.
>
>     If that's correct I propose to rename the terms:
>
>     StoredKey := Hi( HMAC( password, salt )) /* was SaltedPw */
>     ClientKey := H( StoredKey )
>     ServerKey := HMAC( StoredKey, salt )
>     ServerSig := HMAC( ServerKey, Msg )

An attacker who gets the saltedPw has the ability to impersonate the client, so 
having the server store that would remove a nice security property of SCRAM. 
The server should instead store the quad { username, salt, H(ClientKey), 
ServerKey} (ServerKey is only necessary if mutual authentication is performed). 
The ClientKey can't be derived from that quad so the stored information can't 
be used to impersonate the client by itself.  This is a difference from 
DIGEST-MD5 where the server stored information is plaintext equivalent and 
sufficient to impersonate the client in that realm.

> 6 - As always annotated examples with a known password will help.

Agreed.

>     Before I try to tackle v= I'd like to know if the following
>     result for p= is still correct (using MD5 as hash):

MD5 is sufficiently broken that it's unwise to use in new protocols.

                - Chris

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  SCRAM-04 questions
Date:  Sat, 16 Jun 2007 19:58:49 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 69
Sender: [email-masked]

Hi, I tried to implement SCRAM-04 based on MD5.  Some problems:

1 - The I-D uses B64 as specified in RFC 2045, but the example
    strings s=PxR/wv+epq and c=QWBv+XbwcaI/wp are "ambiguous",
    compare RFC 4648.

    Do you mean s=PxR/wv+epqA= and c=QWBv+XbwcaI/wpA= ?

    For n= and a= names the I-D encodes '=' as '=3D', and maybe
    you tried to avoid B64 '=' padding using the UTF-7 version.

    IMO you could just use hex. instead B64 for s=, c=, p=, and
    v= (at least for p= and v= the encoded length is irrelavant).

2 - The terms in the algorithm overview confused me.  There's a
    StoredKey = H( ClientKey ) with ClientKey = H( SaltedPw ),
    but the server needs ServerKey = HMAC( SaltedPw, salt ).  So
    apparently the server has to "store" the SaltedPw, while a
    client likely doesn't store any password at all, it gets the
    original password as input.

    If that's correct I propose to rename the terms:

    StoredKey := Hi( HMAC( password, salt )) /* was SaltedPw */
    ClientKey := H( StoredKey )
    ServerKey := HMAC( StoredKey, salt )
    ServerSig := HMAC( ServerKey, Msg )

3 - Likewise the term ClientSignature in the draft confused me,
    what's sent is ClientProof = ClientKey XOR ClientSignature.

    How about using one term integrating the intermediate steps:

    ClientSig := ClientKey XOR HMAC( H( ClientKey ), Msg )

4 - The definition of the "signed" Message apparently allows to
    omit the first client and server messages.  It's clearer if
    that's not allowed, also getting rid of the "[ ]" operator:

    Msg        := FirstClientMsg + "," +
                  FirstServerMsg + "," + FinalClientMsgExcludingP

5 - The v=WxPv/siO5l+qxN4 calculation in the I-D isn't explained,
    I guess it's the B64 encoded ServerSignature.  Even if that's
    not the idea, v= can't be the same as p=WxPv/siO5l+qxN4.

6 - As always annotated examples with a known password will help.
    Before I try to tackle v= I'd like to know if the following
    result for p= is still correct (using MD5 as hash):

    MX = SCRAM( 1, 'Chris Newman', 'ClientNonce' )
    M1 = 'r=ClientNonce,n=Chris Newman'

    SALT = B64.I( 'PxR/wv+epqA=' )     /* fixed s= in scram-04 */

    MX = SCRAM( 2, M1, 128, SALT, 'ServerNonce' )
    M2 = 'r=ClientNonceServerNonce,i=128,s=PxR/wv+epqA='

    BIND = B64.I( 'QWBv+XbwcaI/wpA=' ) /* fixed c= in scram-04 */
    PASS = 'test'
    WANT = 'LYjXouG9hmwjCozUNmJViA=='

    MX = SCRAM( 3, M1, M2, BIND, PASS )
    M3 = 'r=ClientNonceServerNonce,c=QWBv+XbwcaI/wpA=,p=' || WANT

    Is WANT = 'LYjXouG9hmwjCozUNmJViA==' the correct result ?

Frank

Date: Fri, 15 Jun 2007 17:36:59 -0500
From: Nicolas Williams <[email-masked]>
To: Michael B Allen <[email-masked]>
Cc: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: domain-based service names redux
Mail-Followup-To: Michael B Allen <[email-masked]>, Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

To clarify, (1) means "run each service with a separate keytab (and
rcache) with entries only for the principals that you want the service
to be able to accept as."

Date: Fri, 15 Jun 2007 14:55:59 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: Peter Saint-Andre <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Hostbased service names (Re: domain-based service names redux)
Mail-Followup-To: Martin Rex <[email-masked]>, Peter Saint-Andre <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Jun 12, 2007 at 11:03:11PM +0200, Martin Rex wrote:
> The most sensible and infrastructure-independent approach (i.e. independent
> of how load-balancing is done within the backend and where within
> the backend the secure communication is terminated) for traditional
> Kerberos authentication would be to standardize the user2user
> authentication exchange and use that (no use of _hostbased_
> service names).

Well, no.  The ideal thing to do (as opposed to the *pragmatic* thing to
do) is to add a new krb5 mech or extension to the existing mech that
uses three tokens, with an option for user-to-user[*], so as to get rid
of the need for a replay cache.

That has nothing to do with also deprecating the user of hostbased
service names.  Apps will still need a way to name non-human entities
running on specific hosts.  And whether we drop the _service_ part of
hostbased service names is also an other story.

[*]  With RFC4120 as it is it is not quite possible to do a three-token
     user-2-user mechanism; four tokens are required.  That's because
     the initiator has to be the one sending the AP-REQ, but it can't
     make an AP-REQ until it has obtained the acceptor's Ticket (which
     has got to be sent no earlier than in the second token since in the
     GSS-API the initiator always sends the first token).

     A user-2-user three-token mechanism is possible however, but the
     spec for it would have to update RFC4120.

Nico
--