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

From: "Dan Harkins" <[email-masked]>
Date: Wed, 21 Mar 2007 06:16:50 -0700 (PDT)

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 21 Mar 2007 17:42:12 +0100

Hi Dan

please see inline...

> believe that feeling is incorrect.
I agree on this in some sense. To me, EAP-ER has a two-party vision but 
it might be used as part of
a 3 party key distribution protocol. In particular, it would allow to 
contact the EAP peer (A) and the
server (S) as part of the 3 party key distribution protocol.

In fact in our 3-party protocol I-D, we don't specify any particular 
transport between the parties.
Therefore, under my point of view, EAP-ER might be used to put in 
contact A and S (passing through B)
in a 3-party protocol approach.
>   EAP-ER looks roughly like this (and apologies to the authors if I get
I think server also sends the counter (SEQ) in the EAP Finish Re-auth 
message, anyway...
>           ----------------------->   peer-id, [counter]rki
I think EAP-ER is not always assuming that really "key" is protected by 
foo because basically follows a two party vision.
In fact "key" might be seen by several entities between authenticator 
and server.

> server already shares with the authenticator, denoted as 'foo').
For clarification, 'foo' would be the Kbs in the 3 party protocol which 
we showed in the 3 party protocol I-D.
>   peer-id, {peer-id, auth-id,
Btw, i think "rki" can be safely used here.

Dan, let me translate this a little bit to the terminology we used in 
the 3 party protocol I-D. Hopefully it will help to make some comparison

A= EAP peer/peer-id
B= EAP authenticator/auth-id

Kbs = foo
Kab = key/rMSK
Kas = rke/rki
{X}k = Encryption of message X with key K to provide confidentiality and 
integrity

A->B : A,{A,B,SEQ}Kas
B->S : {A,B}Kbs,{A,B,SEQ}Kas
S->B : {SEQ+1,A,B}Kas, {Kab}Kbs
B->A : {SEQ+1,A,B}Kas

For me, there are two options. Either {A,B,SEQ}Kas is transported within 
the EAP Initiate Re-auth Packet
and {SEQ+1,A,B}Kas in the EAP Finish Re-auth message. That is, EAP-ER is 
used as a transport protocol between A
(EAP peer) and S. This would follow the initial nature of our 3 
party-protocol I-D where the candidate solutions
are independent of the transport protocol you use.

Or the particular implementation of {A,B,SEQ}Kas might include the EAP packet itself
(headers and everything). That is, Kas is used to protect the EAP packet itself (which seems 
the approach you have followed).

> "modified Otway-Rees" but it was not absolutely critical.
Actually server nonce is not needed, since a counter is already used for 
freshness,
that is enough for the EAP peer to know the message from the server is 
fresh...

Btw, there would also be the possibility to replace the counter SEQ by a 
timestamp...
>  The reason it
I don't understand what you mean here?... Between (authenticator) B and 
S you may want use a AAA protocol as transport protocol no?
> with differing proposals please let me know.
I agree that they are NOT 2 opposing camps. In fact, 3 party protocol 
approach
try to put things in order under a security point of view when 3 
entities are
involved for a key distribution procedure. EAP-ER may well complement the
3 party protocol approach.

My Best Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 21 Mar 2007 10:30:45 -0700

Hi Dan,
Thanks for the good explanation of our discussions. We can discuss more
about details (like why you think counter+1 is needed, for e.g. :))
later (I'll try to send more detailed thoughts soon), but, I agree that
we can move forward with the approach given that it basically works for
what we all want to do. 

Regards,
Vidya

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 6:17 AM
> To: [email-masked]
> 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.
> 
> 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):
> 
> 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 
> 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):
> 
> 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.
> 
> 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.
> 
> 
> 
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 21 Mar 2007 10:48:18 -0700

Dan,

Many thanks.  I am responding without having done a detailed analysis so 
there may be holes in my arguments.

We have a baseline agreement and I am happy about that.

I think we may have more of an agreement than indicated here.  We should 
consider the differences in using integrity protection vs encryption and 
see which way to go.  Rafa seems to note that in your message flow, 
integrity protection can be substituted for encryption.

As Rafa also notes, the Finish message of EAP-ER has the sequence 
number.  Vidya and I reasoned and decided that we can use the same 
sequence number in the reverse direction.  We can talk about what seq+1 
might provide.

Peer-id equivalent in EAP-ER is in fact the rIKname (for reauth we 
cannot use the peer's NAI ).  With the rIKname as the peer-id it is 
integrity protected without being included in the MAC coverage.  The 
server-id part might be tricky.  In some cases, the server-id may be 
known to the peer and thus we have no problems to include it optionally 
in the MAC coverage.  However, in other cases rIKname@serving-realm 
(serving== visited == local :) ) is used for AAA routing of the reauth 
message.

As for Rafa's concern of key delivery, if MSK delivery is secure, 
EMSK-derived key delivery is also secure!

thanks,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 21 Mar 2007 10:49:31 -0700 (PDT)

Hi Vidya,

  Good news! I'm glad you agree with this approach.

  I added the +1 because the message the peer sends the server contains
the same information the server sends the peer-- the nonce (which is a
counter in this case), and the identities of the other 2 parties-- and
I want to prevent the authenticator from just mirroring the request.
Adding a +1 ensures the data is different and not just rearranged. For
a good pseudo-random function PRF(A|B|C) is different than PRF(C|B|A)
but it seems to make the protocol more robust if you don't rely on that.

  Also, I drew that protocol up from memory over lunch which is why I'm
hedging my statements of its correctness. I want to look things over to
make sure it's correct. But I was just trying to illustrate a point
which I think worked given your approval of this approach. If +1 is not
needed or some other piece of information is it should be trivial to
fix it. There shouldn't be anything that would make it fundamentally
incompatible with EAP-ER.

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 21 Mar 2007 11:19:31 -0700

Hi Dan, 

> Sent: Wednesday, March 21, 2007 10:50 AM
> To: Narayanan, Vidya
> Cc: Dan Harkins; [email-masked]
> Subject: RE: [HOKEY] 3 party protocol and EAP-ER
> 
> 
>   Hi Vidya,
> 

It is great to see convergence - the emails were not helping that as
much :)

>   I added the +1 because the message the peer sends the 
> server contains the same information the server sends the 
> peer-- the nonce (which is a counter in this case), and the 
> identities of the other 2 parties-- and I want to prevent the 
> authenticator from just mirroring the request.
> Adding a +1 ensures the data is different and not just 
> rearranged. For a good pseudo-random function PRF(A|B|C) is 
> different than PRF(C|B|A) but it seems to make the protocol 
> more robust if you don't rely on that.
> 

Hmmm.. Let me think about this a bit more. 

>   Also, I drew that protocol up from memory over lunch which 
> is why I'm hedging my statements of its correctness. I want 
> to look things over to make sure it's correct. But I was just 
> trying to illustrate a point which I think worked given your 
> approval of this approach. If +1 is not needed or some other 
> piece of information is it should be trivial to fix it. 

Agreed. 

> There 
> shouldn't be anything that would make it fundamentally 

Yes. Actually, one of the confusing points until now has been the
notions of 2-party/3-party and what each one of us has meant by it.
After talking to you and looking at what you wrote down in email, I'm
glad to see that we haven't really been saying much different things.
What you have added to the exchange is channel binding capability and
we've discussed that in regular EAP as well and we can surely discuss
that here, earlier on in the design than later. I think modulo channel
binding, our exchanges are essentially identical. 

Vidya

> > Thanks for the good explanation of our discussions. We can discuss 
> > more about details (like why you think counter+1 is needed, 
> for e.g. 
> > :)) later (I'll try to send more detailed thoughts soon), 
> but, I agree 
> > that we can move forward with the approach given that it basically 
> > works for what we all want to do.
> >
> > Regards,
> > Vidya
> >
> >>   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.
> >>
> would like 
> >> to demonstrate how a 3 party key distribution can be 
> performed in the 
> >> EAP-ER exchange.
> >>
> >>   |<--------------- EAP 
> ------------------------------------------>|
> >>                                        |<--------- AAA 
> ----------->|
> >>
> >>    Peer                          Authenticator             
>      Server
> >>
> >>   peer-id, [counter]rki
> >> 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').
> >> 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):
> >>
> >> 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.
> >>
> 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 
> >> 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.
> >>
> >> 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.
> >>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 22 Mar 2007 04:36:07 -0400

Dan,

I am fine with the outline of the proposal as long as the 3-party key
distribution protocol is designed to work on *any transport*,
including EAP, AAA, IP, and link-layer frames so that the protocol
could be usable for other similar cases where 3 parties are involved
in key-hierarchy based key-exchange in mobile environment.  I actually
see a similar case in MIPSHOP.  I hope my comment is constructive.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 22 Mar 2007 03:18:23 -0700

For the record, I like to repeat my point at the meeting and second Dan's
statement, that the proposed mechanism in 3 party is not meant to propose a
new protocol, it simply tries to achieve better security in the identity
exchange (channel binding) and key transport. Furthermore, having thought
about it some more, it is remarkably similar to the channel binding solution
I presented in SJ, if you put a nonce in the "other info" field of the
channel binding tuple there.

3-party method actually fits nicely with any of considered signaling
alternatives discussed in SJ interim: EAP code, EAP method, if you can get
away with round trip problem, even a hokey signaling. Note that I am NOT
proposing a brand new HOKEY signaling. I am just pointing out that EAP-ER
still need to be investigated with respect to legacy authenticator and EAP
statement machine impact carefully before the group puts an approval stamp
on creating EAP codes according to EAP-ER (lets not discuss that on this
thread). 

That point aside, if and when we adopt EAP-ER as a signaling mechanism, I do
not see ANY problems in integrating the 3 party mechanism into EAP-ER. In
fact I am willing to lend a hand in integrating this mechanism into EAP-ER
draft, assuming that a lending hand is welcome.

Hope this helps putting out the seemingly big fires

Madjid

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 6:17 AM
To: [email-masked]
Subject: [HOKEY] 3 party protocol and EAP-ER

  Hi,

  peer-id, [counter]rki

                                                   [finish]rki, {key}foo

  thanks,

  Dan.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 22 Mar 2007 11:32:37 +0100

Hi Madjid,

<snip>
> not see ANY problems in integrating the 3 party mechanism into EAP-ER. 
Me neither. As a I commented, an option is that EAP-ER may be used as 
transport between EAP peer and the server.
> In
Me too :).

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 22 Mar 2007 12:36:23 +0100

Lakshminath Dondeti escribió:

Hi Laksminath, thanks for reflecting some of my comments.

a few clarifications/comments inline...
> Dan,
>
> Many thanks.  I am responding without having done a detailed analysis 
> so there may be holes in my arguments.
>
> I think we may have more of an agreement than indicated here.  We 
> should consider the differences in using integrity protection vs 
> encryption and see which way to go.  Rafa seems to note that in your 
> message flow, integrity protection can be substituted for encryption.
What i basically said  was "{X}k = Encryption of message X with key K to 
provide confidentiality and integrity" . So that it provides both 
confidentitaly and integrity. Dan expressed that in his EAP-ER adapted 
protocol (he wrote things between {}) and I fully agree with him.
> EMSK-derived key delivery is also secure!
I guess you refer to my comment " I think EAP-ER is not always assuming 
that really "key" is protected by foo because basically follows a two 
party vision. In fact "key" might be seen by several entities between 
authenticator and server."

Basically, what i am saying is that a secure 3 party protocol clearly 
explains and defines what security and a "secure delivery" means between 
the three parties involved.

But EAP-ER vision is two party, right?. In fact, in the EAP-ER i-d says 
something like

"Authenticate all parties

         The EAP-ER protocol provides mutual authentication of the peer
         and the server."

So "all parties" seem to be EAP peer and the server... which are only 
part of the game...

After that, you honestly RECOMMEND in the I-D ("Keying material 
confidentiality") that the key should be delivered securely.

Having said that, again I think, as I already stated, EAP-ER might 
complement a solution that follows a secure 3 party protocol. So, it may 
be worthy
to make the effort to analyze how to converge :).

My 0.001 cents.

>> another