Subject: Re: [HOKEY] 3 party protocol and EAP-ER

From: "M. Vanderveen" <[email-masked]>
Date: Wed, 21 Mar 2007 10:39:43 -0700 (PDT)

No, I am not saying that the protocol specified in the eap-er draft has security issues. I never thought that. It is likely a secure 2-party protocol, just like most EAP methods. 

My doubts were raised with the occasion of introducing the use of EAP-ER accross domains (use case 1 in draft-ohba). In this, the RE- authentication was not done with the same entity that the (original) authentication was done. That's the problem I saw even back in San Diego, and I  mentioned that to both you and Vidya.  No one has been able to convince me of the correctness of turning a correct 2-party protocol (as specified in draft-vidya-eap-er-02.txt) into a 3-party protocol as envisioned in hokey scenarios. That is why I was glad to see a team of contributors write a draft to outline these issues as well as several solutions to it. Fortunately there are solutions that don't increase the message count between any entities. 

Cheers,
Michaela

----- Original Message ----
From: Lakshminath Dondeti <[email-masked]>
To: M. Vanderveen <[email-masked]>
Cc: Dan Harkins <[email-masked]>; [email-masked]
Sent: Wednesday, March 21, 2007 10:00:37 AM
Subject: Re: [HOKEY] 3 party protocol and EAP-ER

Michaela,

What are you saying?  If you are saying that the protocol specified in 
the EAP-ER draft has security issues, please outline them here.  It is 
not constructive to simply say that you have doubts.

Dan is merely illustrating that there aren't really two camps.  The two 
approaches are merely two different ways of doing things.  The two 
approaches may indeed have different properties.

I have analyzed EAP-ER and stand by its correctness.  Does it mean there 
is no possibility of vulnerabilities?  I have never said that.  But, if 
there are concerns, please explain them clearly.

I haven't analyzed the protocol Dan wrote up.  I shall do that soon and 
continue offline discussions with Dan to see if we can converge here.  I 
encourage others to do the same and list any properties of interest.

regards,
Lakshminath

M. Vanderveen wrote:
> Hi Dan,
>  
> I have long harbored doubts about the use of 2-party EAP-ER in re-auth 
> with a Hokey server that is different (and possibly in a different 
> domain) from the EAP server with which the original full EAP method was 
> done.  The protocol you outline, which is a modified version of the one 
> in draft-ohba, looks like it will work without any additional messaging. 
> This is great news, if indeed it can be shown to be secure even without 
> the party B's nonce (Hokey server's).  We still have to work out at the 
> lower layer probably, how the Peer will know the Hokey server's id, but 
> other than that it something that can be overlayed with relative ease.
> Count one happy camper....
>  
> Michaela
> 
> ----- Original Message ----
> From: Dan Harkins <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, March 21, 2007 6:16:50 AM
> Subject: [HOKEY] 3 party protocol and EAP-ER
> 
> Hi,
> 
>   At the end of the HOKEY meeting on Monday there seemed to be a feeling
> that there were two camps with competing and incompatible proposals. I
> believe that feeling is incorrect.
> 
>   I spoke with Vidya, Lakshminath, and Madjid (separately but the same
> discussion) and they all agree that we are very close. I would like to
> demonstrate how a 3 party key distribution can be performed in the
> EAP-ER exchange.
> 
>   EAP-ER looks roughly like this (and apologies to the authors if I get
> something wrong):
> 
>   |<--------------- EAP ------------------------------------------>|
>                                        |<--------- AAA ----------->|
> 
>    Peer                          Authenticator                  Server
> 
>   peer-id, [counter]rki
>           ----------------------->   peer-id, [counter]rki
>                                           ------------------------->
> 
>                                                    [finish]rki, {key}foo
>                                      <------------------------------
>                [finish]rki
>      <-----------------------------
> 
> The peer sends all his stuff as a new EAP code. That gets put into a
> AAA request by the authenticator who sends it to the server in the
> traditional fashion. The server sends his finished message, using another
> new EAP code, as an EAP msg attribute and the key in something like the
> aes-key-wrap attribute using a key from the security association that the
> server already shares with the authenticator, denoted as 'foo').
> Other attributes assigned to that key's context are not shown for
> simplicity but are assumed to be there. The authenticator gets this EAP
> msg and forwards it onto the peer in the traditional fashion.
> 
>   This is how EAP-ER performs a secure 3 party protocol (note that the
> protocol might not be absolutely correct but any changes that may be
> necessary to ensure its security should not impact this):
> 
>   peer-id, {peer-id, auth-id,
>             counter}rke
>      ------------------------------>
>                                       {peer-id, auth-id}foo,
>                                       {peer-id, auth-id, counter}rke
>                                     ---------------------------------->
> 
>                                       {counter+1, peer-id, auth-id}rke,
>                                       {key}foo
>                                     <----------------------------------
>                 {counter+1, peer-id,
>                  auth-id} rke
>      <------------------------------
> 
> Same new EAP code in peer's message. Same new EAP code in server's
> response. Same conversion of EAP message to AAA attribute and back
> again. I have introduced only 1 new term and that is auth-id. I would
> like to point out that auth-id is going to be known by the peer and
> the server because they have to generate a key in the key hierarchy that
> is bound to that identity. So auth-id is not used in EAP-ER today but
> for HOKEY to work that identity must be known so my introduction of it
> into this protocol should not cause anyone any heartburn.
> 
>   I don't describe the necessary behavior of the server but it should
> be obvious and it isn't really germane to this demonstration.
> 
>   This exchange doesn't have the server nonce which I wanted in the
> "modified Otway-Rees" but it was not absolutely critical. The reason it
> cannot be in this protocol is that the authenticator doesn't speak EAP
> and most likely the only packets/frames it is sending to and receiving
> from the peer are an encapsulation of the EAP packet, e.g. 802.1x, such
> that it can be transmitted. It can't add anything to the message without
> breaking things.
> 
>   What this provides is identity confirmation by all parties involved.
> When the protocol finishes all parties know it finished and if it
> finishes successfully they will all agree on that point. It is not
> possible for someone to convince one party that the protocol finished
> in a different state than the others think and it is not possible for
> one of the parties to lie about his or her identity assuming the keys
> used-- rki/rke, foo-- are unique and bound to the identities being used
> in the protocol (which is not an unreasonable assumption and is, in fact,
> necessary for good crypto hygiene). The peer gives consent to the
> exchange by contributing the necessary data to initiate the protocol.
> 
>   As I said, this might not be 100% correct (I want to refer to my
> notes for the secure 3 party protocol) but differences should slip right
> in to it without any substantial changes.
> 
>   Any issues with EAP-ER (the state machine weirdness where the response
> to an identity request is not an identity response, the requirement that
> the authenticator change, etc) are unaffected by this addition. All that
> happened was that the key distribution was secured.
> 
>   Please take a look. If anyone thinks there are still 2 opposing camps
> with differing proposals please let me know.
> 
>   And if you will indulge my channelling of Rodney King I'd like to
> end by asking, "can't we all just get along?"
> 
>   thanks,
> 
>   Dan.
> 
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
> 
> 
> ------------------------------------------------------------------------
> Sucker-punch spam < 
> http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html> 
> with award-winning protection.
> Try the free Yahoo! Mail Beta. < 
> http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey

____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

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