Subject: Comments on YAP

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Apr 2009 15:37:51 -0500

I looked at draft-zeilenga-sasl-yap-03 when revising
draft-ietf-sasl-channel-bindings.

Here are some comments:

 - YAP as a variant of SCRAM seems like a good idea: you can reuse the
   SCRAM PBKDF and key management.  That means less administration, and
   also that you could normatively refer to SCRAM for parts of YAP, thus
   making the YAP I-D smaller.

 - IMO there should be a server->client message for mutual
   authentication (though as with SCRAM there's no server name).  The
   following is a YAP-as-variant-of-SCRAM exchange as I imagine it:

    C: p,a=nico,n=Nico,p=<ClientKey XOR
			    HMAC(StoredKey, "n=Nico,cb=p,a=nico,tls-unique:...")
    S: v=HMAC(ServerKey, <client's first message>)
    C: <empty>  (optional depending on the app protocol)
    S: <outcome of authentication>

   With this you'd save a round-trip compared to SCRAM and could qualify
   for the Standards-Track (I guess what makes YAP Experimental is the
   lack of mutual authentication).

 - When the client has not cached the salt and/or PBKDF iteration counts
   or the cached values are out of date the mechanism could devolve into
   SCRAM:

    C: n,a=nico,n=Nico,p=<ClientKey XOR
			    HMAC(StoredKey, "n=Nico,cb=n,a=nico,tls-unique:...")
    S: s=<salt>,i=<iteration-count>
    C: n,a=nico,n=Nico,p=<ClientKey XOR ...>
    S: v=HMAC(ServerKey, <client's second message>)
    C: <empty>  (optional depending on the app protocol)
    S: <outcome of authentication>

 - You could even have YAP be exactly like SCRAM when the given channel
   binding type is not a unique channel binding type.

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 29 Apr 2009 09:01:24 -0700

> draft-ietf-sasl-channel-bindings.

I just uploaded -04.  Aside from other minor changes, it adds the  
following clarifying statement to the Introduction.

   YAP relies on client to authenticate the server within this lower- 
level security layer to avoid information disclosure to rogue servers.

This clarification is relevant to your comments concerning mutual  
authentication.  While YAP doesn't directly provide for mutual  
authentication, it does (quite strongly) encourage clients  
authenticate the server at the lower level.

>
>
> Here are some comments:
>
> - YAP as a variant of SCRAM seems like a good idea:

Having such a variant of SCRAM might be a good idea... but I still  
like to pursue YAP as specified in my I-D as I think its still, on its  
own, a good idea.

I leave pursuit of such a variant of SCRAM to others.

> you can reuse the

>   authentication (though as with SCRAM there's no server name).

YAP expects the client to authenticate the server (at the lower layer)  
prior to initiating the YAP exchange.  This ensures YAP authentication  
information, such as the autchid, is not disclosed to rogue servers.

>  The

I don't see mutual authentication as necessarily being a requirement  
for the Standards Track, but I note YAP does provide for mutual  
authentication.

That said, I continue to think Experimental as best for now (*) for YAP.

(* I don't preclude later seeking Standard Track status, such as after  
gaining significant operational experience with it.)

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Apr 2009 11:30:29 -0500

> level security layer to avoid information disclosure to rogue servers.

I don't think that's a good idea.  Here's why: if you're really
authenticating the server at the lower layer then why are you using
channel binding in YAP?  And if the lower layer is not authenticating a
server name then you don't get mutual auth at all.

Keep in mind that by "mutual authentication" I mean, in this case, that
a message is sent by the server that proves the server knew the
credential that it needed to verify the client's YAP message.  I do NOT
mean that the server _name_ is authenticated.

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 29 Apr 2009 10:54:38 -0700

On Apr 29, 2009, at 9:30 AM, Nicolas Williams wrote:

> channel binding in YAP?

The channel binding also ensures the client lower-level and YAP end  
points are the same.

One problem in many uses of TLS in application protocols is that the  
server has no clue wether the client's user well authenticated the  
server, hence the server has to be leery of man-in-the-middle  
attacks.  By using channel bindings, the server need not be concerned  
about whether the client's user well authenticated the server as it  
can rely on the channel binding to avoid man-in-the-middle attacks.

> And if the lower layer is not authenticating a

If the client doesn't adhere to the SHOULD, then it runs the risk of  
disclosing the portions of the credentials (e.g., the authcid).   My  
view is that client's user is more sensitive to associated risks of  
such disclosure than the server's operator, so it seems reasonable to  
me to make a recommendation that the client authenticate the server at  
the lower level.   For my uses this level of authentication is quite  
sufficient.

-- Kurt