Subject: [HOKEY] ERX-12 -- Please review changes

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 02:11:42 -0800

Hi all,

During the IESG review, Jari and Sam had some comments that needed to 
resolved for the document to advance.  I have now uploaded a version 
with further clarifications (please review the differences between v11 
and v12 and let me know if anything is amiss).

Additionally, Sam suggested inclusion of a mechanism to support DSRK 
delivery authorization indication from the home ER server to the peer. 
The idea is for the home ER server to indicate to the peer that the home 
ER server was able to verify authorized delivery of the DSRK to the 
home.  For instance that is possible if the home ER server can directly 
verify the local ER server's authentication credentials and can deliver 
the DSRK via an end-to-end authenticated secure channel between those 
two entities.  The mechanism for this is an additional TLV in the 
EAP-Finish/Re-auth message which contains a MAC that proves possession 
of a key that only the home ER server and the peer have.  I have 
specified the derivation of a "special" DSRK-level key from the EMSK 
derived using the label "DSRK Delivery Authorized [email-masked]" and with 
domain name in the optional data field as usual for DSRK derivation.

I have added text in the security considerations on the use of this key 
for secure key delivery.

Sam and I talked about adding more text in the security considerations 
saying that the home ER server may choose to include this TLV when it 
knows that it has delivered a specific DSRK to one and only server (in 
addition to the secure channel case, which is more of a direct 
indication of an authorized delivery).  I have not yet added that claim. 
  I plan to add that to the next revision (hope to submit that before 
tomorrow's deadline).

Please let me know your thoughts.

thanks,
Lakshminath
_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 13:08:27 +0200

Going through my Discuss & Comments wrt -12:

Part 1: Mostly OK, but I'd prefer two additional changes, see below
Part 2: Mostly outside the spec. If 1 and 3 are handled, I'm fine with
the responses I have gotten so far.
Part 3: I did not see any changes related to this.
Part 4: This is something we have to do outside the spec. I.e., dig up
the information or perform the tests.
Domain: OK
Home ER server: not sure if there were any changes related to this.
Bernard's review: Need to wait for him to respond (a while, at least).
Comment: OK

Details:

>   The authenticator MAY
>    initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start
>    message, and if there is no response, sends the EAP-Request/Identity
>    message.  Note that this avoids having two EAP messages in flight at
>    the same time [2].  The authenticator may send the EAP-Initiate/
>    Re-auth-Start message and wait for a short, locally configured,
>    amount of time.  If the peer does not already know, this message
>    indicates to the peer that the authenticator supports ERP.  In
>    response to this trigger from the authenticator, the peer can
>    initiate the ERP exchange by sending an EAP-Initiate/Re-auth message.
>    If there is no response from the peer after the necessary
>    retransmissions (see Section 6), the authenticator initiates EAP by
>    sending EAP-Request/Identity message.

s/the authenticator initiates EAP/the authenticator MUST initiate EAP/

>    Eventually the authenticator would send EAP
>    Request/Identity messages and the peer can respond to those and start
>    EAP authentication. In some lower layers, the peer may initiate EAP
>    by sending messages such as EAPoL-Start in the IEEE 802.1X
>    specification [10].
Mumble. Right, but this is not the same as being able to ask the network
to send a specific message. The authenticator will still be making a
decision on whether to send a re-auth-initiate or identity request
message. I think you need to say this more clearly (and indicate that
there is a potential delay to plain old EAP clients).

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 25 Feb 2008 06:29:05 -0800

Jari Arkko <> scribbled on Monday, February 25, 2008 6:08 PM:

...

>>    Request/Identity messages and the peer can respond to those and
>>    start EAP authentication. In some lower layers, the peer may
>>    initiate EAP by sending messages such as EAPoL-Start in the IEEE
>>    802.1X specification [10].
> Mumble. Right, but this is not the same as being able to ask the
> network to send a specific message. 

Um, it's pretty much exactly like that: the only purpose for the
EAPOL-Start message is to trigger the transmission of an EAP Request, in
particular an EAP Request/Identity message.  

> The authenticator will still be
> making a decision on whether to send a re-auth-initiate or identity
> request message. 

Not if we're both talking about the same 802.1X: even though section
8.1.2.2 of .1X 2004 leaves open the possibility that a non-Identity EAP
Request might be sent in response to EAPOL-Start, neither the text nor
the state machine allows the transmission of an EAP-Initiate/Re-auth
message & an authenticator that responded in that way would be seriously
broken

> I think you need to say this more clearly (and
> indicate that there is a potential delay to plain old EAP clients).  
> 
> Jari
>

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 25 Feb 2008 06:36:25 -0800

...

> Please let me know your thoughts.

I'll go through this more closely later, but one quick suggestion would
be to lose reference 8 since it is to an expired I-D that seems unlikely
to be anything other than an expired I-D...

...

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 09:04:41 -0800

> message & an authenticator that responded in that way would be seriously

Glen is right.  The peer starts ERP.  So, if it instead sends 
EAPoL-Start type of messages (could be different depending on the lower 
layer), that indicates to the authenticator that the peer wants to start 
plain old EAP.

>> indicate that there is a potential delay to plain old EAP clients).  
I have added this.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 09:27:26 -0800

> Part 1: Mostly OK, but I'd prefer two additional changes, see below

Hi Jari,

I incorporated your suggested changes in v13; Glen's and my response 
along with that should now cover this topic.  Does it?

> Part 3: I did not see any changes related to this.

Retransmission semantics are specified in Section 6.  That takes care of 
specification in the presence of loss of messages.  Issues related to 
legacy clients are resolved as per the discussion on Part 1.  I am not 
sure what is missing.

> the information or perform the tests.

I have done some of this.  I will send notes later.

> Home ER server: not sure if there were any changes related to this.

I have added text to further clarify that the local ER server MUST be in 
the path.  It appears that I did miss one part and I am adding the 
following in v13:

"ER server is a logical entity; the home ER server is located on
                         the same backend authentication server as the 
EAP server in the home domain. The local ER server
                         may not necessarily be a full EAP server."

The addressability of the servers is already covered; the peer sends the 
messages to EMSKname@realm; the realm is either the same as used in EAP 
or local domain name.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 09:32:09 -0800

> to be anything other than an expired I-D...
I am ok with removing it, if there are no objections.

regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 20:30:42 +0200

Lakshminath, Glen,

> EAPoL-Start type of messages (could be different depending on the
> lower layer), that indicates to the authenticator that the peer wants
> to start plain old EAP.

I have a hard time understanding why you two are saying that peer starts
ERP and that only EAP Identity-Request may come after EAPOL-Start. Your
own spec shows very clearly in figure 2 that
the first ERX message (initiate re-auth-start) is sent from the
authenticator to the peer. Presumably whatever initiates EAP on a given
lower layer (EAPOL-Start in 1X) kicks the entire process into action, be
it ERX-enhanced or not. Or are you expecting some other lower layer
start method if ERX is employed?

(But it is true that Figure 2 shows EAP Request Identity as the first
message. However that seems to be in contradiction with the paragraph 2
below the figure that says initiate-re-auth-start is sent first and only
if there is no response the authenticator will send revert back to the
usual EAP exchange. Maybe the figure needs to be updated; that text
changed in -12.)

In any case, if you are making the two changes that I asked for earlier
today and update the figure, your document should be fine...

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 25 Feb 2008 10:37:36 -0800

Jari Arkko <mailto:[email-masked]> scribbled on Tuesday, February
26, 2008 1:31 AM:

>>>>>    initiate EAP by sending messages such as EAPoL-Start in the
>>>>>    IEEE 802.1X specification [10].
>>> EAPOL-Start message is to trigger the transmission of an EAP
>>> Request, in particular an EAP Request/Identity message.
>>> 8.1.2.2 of .1X 2004 leaves open the possibility that a non-Identity
>>> EAP Request might be sent in response to EAPOL-Start, neither the
>>> text nor the state machine allows the transmission of an
>>> EAP-Initiate/Re-auth message & an authenticator that responded in
>>> that way would be seriously broken
>> 
> I have a hard time understanding why you two are saying that peer
> starts ERP and that only EAP Identity-Request may come after
> EAPOL-Start. 

I'm not saying it, the IEEE has already said it...

...

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 10:45:35 -0800

> start method if ERX is employed?

I can understand the confusion.  If the authenticator starts by itself, 
it does not know what to do when it supports ERX. We are biasing it to 
start with EAP Initiate/Re-auth-Start.  If it knows -- the peer sends 
EAPoL-Start for example, it knows that the peer does not support ERP. 
If the peer does support ERP, it must start with EAP-Initiate/Re-auth 
and it must not send EAPoL-Start (of course we can't mandate the second 
part in an IETF spec; we have already mandated the first part and that 
is sufficient).  If you want me to provide the second part in the lower 
layer considerations, I can add text.

> usual EAP exchange. Maybe the figure needs to be updated; that text

Yeah, they are both optional messages and so I left the figure as is.  I 
will edit that in the next revision to avoid confusion.

> today and update the figure, your document should be fine...

I will do that.  Thanks.

regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 20:47:45 +0200

Lakshminath,

> along with that should now cover this topic.  Does it?

If you incorporated the changes in v13, it may be OK. You should still
sync Figure 2 to text, and I don't know exactly what text you used to
fix my second issue. As long as you are not claiming that EAPOL-Start
somehow makes you go back to legacy EAP you are fine.

> Retransmission semantics are specified in Section 6.  That takes care
> of specification in the presence of loss of messages.  Issues related
> to legacy clients are resolved as per the discussion on Part 1.  I am
> not sure what is missing.

What I was missing was text that in the context of Figure 2 and text
below it would state that the normal RFC 3748 retransmission rules apply
to the EAP Request / Identity packet. You have stated before that you
believe this is the case and that it is obvious. Given that you have a
new sequence of messages where EAP Request / Identity is a part, I think
you should explicitly call this out. For instance:

OLD:
   ... , the authenticator initiates EAP by
   sending EAP-Request/Identity message.
NEW:
   ... , the authenticator initiates EAP by
   sending EAP-Request/Identity message. This message is sent
  and if needed, retransmitted using the normal EAP processing
  rules.

> I have done some of this.  I will send notes later.

Ack.

> I have added text to further clarify that the local ER server MUST be
> in the path.  It appears that I did miss one part and I am adding the
> following in v13:
>

OK.

>
> The addressability of the servers is already covered; the peer sends
> the messages to EMSKname@realm; the realm is either the same as used
> in EAP or local domain name.
>
OK.

Jari

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 10:56:45 -0800

Hi Jari,

Ack on the retransmissions text (I have text on that already; but happy 
to say that explicitly as you suggest ahead of the "lower layer 
considerations section").

> somehow makes you go back to legacy EAP you are fine.

I responded to your other message.  I do think we should not change 
802.1X behavior and instead take advantage of it given that ERP is 
peer-initiated.  I'd agree with your position if we developed a protocol 
that is authenticator initiated; I also see the use of that mode of 
operation in the current context, but there are also disadvantages.

We have developed the entire specification with the assumption that the 
peer initiates the exchange.  If the peer does not have information that 
it might get from the EAP-Initiate/Re-auth-Start (domain name), it can 
get it through other means (lower layer is one and at the ERP level, 
with bootstrapping).

So, we would like to keep the EAPoL-Start behavior as is and that is to 
trigger EAP Request (identity or otherwise, in the optimization case).

regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 20:59:18 +0200

Glen,

> I'm not saying it, the IEEE has already said it...
Then I guess I must be missing something very basic. I _might_ imagine
the IEEE spec has been written so that it expects EAP Request/Identity
to be sent out, even if that would preclude things like APs that are
configured to start EAP TLS directly. (I don't seem to have access to
the IEEE spec, can you send the relevant text excerpt?)

However, what is more troubling is that you seem to be saying that EAPOL
Start indicates non-ERX capable client. Since ERX capable hosts will
also need some way of initiating EAP with the authenticator, I must be
assume that you expect to have something else. I.e., a major requirement
for link layer. I do not understand why you need to do that, and I do
not think you should be doing this lightly.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 21:07:58 +0200

Lakshminath,

> I can understand the confusion.  If the authenticator starts by
> itself, it does not know what to do when it supports ERX. We are
> biasing it to start with EAP Initiate/Re-auth-Start.  If it knows --
> the peer sends EAPoL-Start for example, it knows that the peer does
> not support ERP. If the peer does support ERP, it must start with
> EAP-Initiate/Re-auth and it must not send EAPoL-Start
Again, I'm greatly confused -- but possibly its just me.

First, there is EAPOL-Start and only then the EAP messages even start to
flow. See
http://fi.wikipedia.org/wiki/Kuva:802.1x_Authentication_Procedure.png

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 21:11:20 +0200

Lakshminath,

>
> We have developed the entire specification with the assumption that
> the peer initiates the exchange.

Ah, now I finally see where my confusion is. Your first two messages in
Figure 2 that come from the authenticator are in fact optional.

I have to think about what this means for interoperability in terms of
legacy client/authenticator.

Jari

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 11:14:45 -0800

> the IEEE spec, can you send the relevant text excerpt?)

Not necessarily Identity, but EAP Request packet.

Section 8.1.2.2. of 802.1X

In order to request that the Authenticator PAE initiate authentication, 
the Supplicant PAE sends an EAPOL-Start packet (see 7.5.4).  The 
Authenticator PAE receiving an EAPOL-Start packet responds by sending an 
EAP-Request packet that is chosen by EAP.

I saw your other message and so I will stop here :).

regards,
Lakshminath

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 25 Feb 2008 11:42:09 -0800

Jari Arkko <> scribbled on Tuesday, February 26, 2008 1:48 AM:

> If you incorporated the changes in v13, it may be OK. You should
> still sync Figure 2 to text, and I don't know exactly what text you
> used to fix my second issue. As long as you are not claiming that
> EAPOL-Start somehow makes you go back to legacy EAP you are fine. 

Are you claiming that anything but an EAP Request is a valid response to
EAPOL-Start?  

...

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 25 Feb 2008 12:02:57 -0800

Jari Arkko <mailto:[email-masked]> scribbled on Tuesday, February 26, 2008 1:59 AM:

> Then I guess I must be missing something very basic. I _might_
> imagine the IEEE spec has been written so that it expects EAP
> Request/Identity to be sent out, even if that would preclude things
> like APs that are configured to start EAP TLS directly. 

This is what I said (in part): "Not if we're both talking about the same 802.1X: even though section 8.1.2.2 of .1X 2004 leaves open the possibility that a non-Identity EAP Request might be sent in response to EAPOL-Start, neither the text nor the state machine allows the transmission of an EAP-Initiate/Re-auth message & an authenticator that responded in that way would be seriously broken"  This doesn't preclude an AP sending an EAP-TLS/Request but it _does_ rather obviously preclude an authenticator sending an EAP-Initiate message.  EAP-Request ~= EAP-Initiate.

> (I don't seem
> to have access to the IEEE spec, can you send the relevant text
> excerpt?)  

This is relevant, but not complete: 

8.1.2.2 Supplicant initiation
In order to request that the Authenticator PAE initiate authentication, the Supplicant PAE sends an EAPOLStart
packet (see 7.5.4). The Authenticator PAE receiving an EAPOL-Start packet responds by sending an
EAP-Request packet that is chosen by EAP.
   
> 
> However, what is more troubling is that you seem to be saying that
> EAPOL Start indicates non-ERX capable client. Since ERX capable hosts
> will also need some way of initiating EAP with the authenticator, I
> must be assume that you expect to have something else. I.e., a major
> requirement for link layer. I do not understand why you need to do
> that, and I do not think you should be doing this lightly.  

I don't particularly like the idea but I prefer it to redefining the behavior of another organization's standard "beneath the sheets" (although I know other that some SDOs don't seem to have any problem with such actions (e.g., 3GPP vis-à-vis Diameter)).

> Jari

"if you haven't read it, you don't have an opinion"
_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 22:29:26 +0200

Glen,

> This doesn't preclude an AP sending an EAP-TLS/Request but it _does_ rather obviously preclude an authenticator sending an EAP-Initiate message.  EAP-Request ~= EAP-Initiate.
>   

Ok. I see that now. Thanks for taking the time to explain it.

> I don't particularly like the idea but I prefer it to redefining the behavior of another organization's standard "beneath the sheets"

Right, now I understand the issue with ERX Initiate vs. 802.1X.

However, aren't you trading one problem to another? I understand the
desire to avoid breaking the 802.1X state machine rules on sending
something else than EAP Request. But does 802.1X allow you to send (any)
EAP message as the first message from the client?

More generally, now that I'm beginning to understand the lower layer
implications, I'm not sure the document has enough information on them.
I searched for lower layer troughout the text, but it really said very
little about the implications. The basic requirements appear to be:

- Should be able to send first message either from the authenticator or
peer.
- Not tied to RFC 3748 messages.
- Some additional retransmission rules.

In particular, IF (and I may be wrong on this) there are implications
along the lines of known EAP lower layers not being able to handle ERX,
I think that needs to be spelled out very clearly. The 802.1X question
was above. Looking at another popular lower layer, IKEv2, it is also
very unclear to me whether that would be able to carry ERX. In fact, RFC
4306 Section 3.16 rules on Length field seem to preclude non-req/resp
packets that have some other length than 4.

One way of addressing this is to describe the applicability of ERX for
lower layers (1x/ikev2/etc/new) as not applicable, applicable under some
given conditions or always applicable, as appropriate.

Jari

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 13:05:10 -0800

On 2/25/2008 12:29 PM, Jari Arkko wrote:
> Glen,
> 
>> This doesn't preclude an AP sending an EAP-TLS/Request but it
>> _does_ rather obviously preclude an authenticator sending an
>> EAP-Initiate message.  EAP-Request ~= EAP-Initiate.
>> 
> 
>>> However, what is more troubling is that you seem to be saying
>>> that EAPOL Start indicates non-ERX capable client. Since ERX
>>> capable hosts will also need some way of initiating EAP with the
>>> authenticator, I must be assume that you expect to have something
>>> else. I.e., a major requirement for link layer. I do not
>>> understand why you need to do that, and I do not think you should
>>> be doing this lightly.
>>> 
>> I don't particularly like the idea but I prefer it to redefining
>> the behavior of another organization's standard "beneath the
>> sheets"
> 
> something else than EAP Request. But does 802.1X allow you to send
> (any) EAP message as the first message from the client?
> 
> implications, I'm not sure the document has enough information on
> them. I searched for lower layer troughout the text, but it really
> said very little about the implications. The basic requirements
> appear to be:
> 
> - Should be able to send first message either from the authenticator
> or peer. - Not tied to RFC 3748 messages. - Some additional
> retransmission rules.
> 
>  along the lines of known EAP lower layers not being able to handle
> ERX, I think that needs to be spelled out very clearly. The 802.1X
> question was above. Looking at another popular lower layer, IKEv2, it
> is also very unclear to me whether that would be able to carry ERX.
> In fact, RFC 4306 Section 3.16 rules on Length field seem to preclude
> non-req/resp packets that have some other length than 4.

Sure, it appears from the 802.1X and 4306 that their specifications were 
written with 3748 in mind and that makes sense.  Open ended 
specifications don't always work.

So if 802 networks or IKEv2 want to use ERX, they need to update their 
specifications.  If I were adding ERX to IKEv2 -- I'd send 
EAP-Initiate/Re-auth message in the third message (from Initiator to 
Responder); if the authenticator does not understand ERX, it responds 
with EAP-Request.  Since the lower layer is reliable, the authenticator 
always starts with EAP-Request and not EAP-Initiate/Re-auth-Start 
message.  I will specify an N payload for the authenticator to send 
domain name information and another to indicate ERP support in message 2.

I would imagine that is quite clear from the specification; if not, 
future designers can look at this archive for information.  It is 
contextual to the lower layer and so it is not clear what to write in 
the current specification.

regards,
Lakshminath

> 
> One way of addressing this is to describe the applicability of ERX
> for lower layers (1x/ikev2/etc/new) as not applicable, applicable
> under some given conditions or always applicable, as appropriate.
> 
> Jari
> 
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 13:21:33 -0800

On 2/25/2008 1:14 PM, Jari Arkko wrote:
> Lakshminath,
> 
>> Sure, it appears from the 802.1X and 4306 that their specifications
>> were written with 3748 in mind and that makes sense.
> Right.
> 
>>   Open ended specifications don't always work.
> 
> But we should have gotten this done more right than it appears to have
> been done, at least with IKEv2...
> 
>> with EAP-Request.  Since the lower layer is reliable, the
>> authenticator always starts with EAP-Request and not
>> EAP-Initiate/Re-auth-Start message.  I will specify an N payload for
>> the authenticator to send domain name information and another to
>> indicate ERP support in message 2.
> 
> Right.
> 
> I think the applicability of ERX in currently popular lower layers is an
> important piece of information for the reader. Please document this in
> hokey-erx.

Hi Jari,

Do you want me to write about how ERX might work with some "common" 
lower layers or write guidance notes?

regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 23:14:26 +0200

Lakshminath,

Right.

Right.

Jari

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 14:15:47 -0800

On 2/25/2008 1:30 PM, Bernard Aboba wrote:
> Is this true of all existing EAP lower layers? IEEE 802.16, IEEE 802.1, 
> IEEE 802.11,
> IKEv2, etc.? Are the changes just to accomodate the Initiate/Re-auth 
> message,
> or also for other aspects, such as the Local Domain ID?

The changes are primarily to accommodate the peer initiated aspect; the 
new code; and less so about communicating support for ERP (optional 
really) and to send local domain id (there are other ways for the peer 
to get this information, e.g., ERP bootstrapping).

When I wrote about how to add support for ERX in IKEv2 -- I have never 
thought about that before -- I found it to be surprisingly easy.  I am 
planning now to write a draft or simply ask text to be included in 
ikev2bis.  Does that sound like a good idea?

>  > > specifications.
> Assuming that every existing EAP lower layer will change to accomodate ERX
> seems somewhat optimistic, no?  Wouldn't it be more likely that 
> solutions will
> be adopted which don't require changes to RFC 3748?

It turns out some changes to lower layer are in fact necessary to 
accommodate efficient reauthentication.  The exception, if we have a 
bigger delay budget, is method-based reauthentication, but that does 
imply doing it for every method; operation with the home server and 
multiple roundtrips.

So, whereas it would be great if we could do it without changes to 3748 
and lower layers, I don't think that is possible.  We could do it with 
substantial changes to each lower layer, including a key hierarchy 
specification, for instance as in case of 11r.  But that implies 
substantial changes to all lower layers.

regards,
Lakshminath

>  
>  > > If I were adding ERX to IKEv2 -- I'd send
> I'd agree that dependencies on lower layer changes (and incompatibilities
> with existing lower layers) needs to be documented.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 17:31:08 -0800

Hi Bernard,

I have reviewed draft-ohba-eap-kde-01 before and it does not meet fast 
reauthentication goals.  Please see below:

On 2/25/2008 3:24 PM, Bernard Aboba wrote:
> 
> [BA] I've recently seen a draft (from Yoshi, submitted today) that  seems
> to provide similar functionality with no changes to RFC 3748.  Although
> I haven't reviewed the document in depth, it did seem to provide
> method-independent re-authentication without multiple round-trips
> (at least for case of a local ERX server, which is the most important
> one from a performance point of view). 

The number of roundtrips on the access link is 3, if we take connection 
open or an equivalent into account.  With ERP, the peer can start 
sending authenticated data after 1 RT.

> 
> This document will probably be discussed in IEEE 802, which could adopt
> it as their approach to EAP re-authentication going forward.

In other access technologies, the handover latency requirements are more 
stringent and they have already adopted ERP and waiting for publication 
of the ERP RFC.  Without further optimizations, 802.11 with 3 RTs or 
more for connection setup and EAP-KDE and 2 more for the 4-way exchange 
has little to no hope of really achieving low handover latency.

That model does not fit for voice call continuity.

regards,
Lakshminath

> 
> If possible, it would be good to have a single standard for this, as opposed
> to multiple competing ones.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 17:43:02 -0800

Hi Bernard,

I am confused about EAP-KDE.  The call flow is listed as follows:

  Peer    Authenticator/Server         KDE Server/AAA Server
        <-- EAP-Request/KDE{KDE0}
        --> EAP-Response/KDE{KDE1}   --> AAA{KDE2}
        <-- EAP-Request/KDE{KDE4}    <-- AAA{KDE3, authorization data}
        --> EAP-Response/KDE{}
        <-- EAP-Success

Without modifications to 3748 and authenticators, why would an 
authenticator start by sending EAP-Response/KDE{KDE0}?

The omission of the Identity exchange may work as follows:

Step 1.  peer --> authenticator: Connection Setup(Identity)
Step 2. Authenticator extracts the identity and sends it to backend and 
receives EAP-Request/KDE{KDE0}.

The call flow above follows from there.

That's an additional round trip to the backend as part of Step 2 above. 
  What am I missing?

regards,
Lakshminath

On 2/25/2008 3:24 PM, Bernard Aboba wrote:
> Comments below.
> 
>  > Date: Mon, 25 Feb 2008 14:15:47 -0800
>  > From: [email-masked]
>  > To: [email-masked]
>  > CC: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
>  > Subject: Re: [HOKEY] ERX-12 -- Please review changes
>  >
> [BA] OK.  Might be useful to make this clear (e.g. that local domain id
> support is optional).
> 
>  >
> [BA] I'd talk to Pasi and Paul Hoffman about this.
> 
>  >
>  > >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 25 Feb 2008 22:11:56 -0500

> receives EAP-Request/KDE{KDE0}.

No.  KDE0 is sent before knowing peer identity.

> That's an additional round trip to the backend as part of Step 2 above. 

That is not correct as explained above.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 25 Feb 2008 22:26:11 -0500

Roundtrips between EAP peer and EAP authenticator on the access link
are not major part of signaling latency compared to AAA roundtrips.  I
have not heard a complaint on 802.11i 4-way handshake latency.

Although it would be a nice thing to reduce any kind of roundtrips as
much as possible, I am not sure, after reading the IETF Last Call
comments, people outside the HOKEY WG seem to wonder if the expected
benefit for more optimization with ERX pays to its deployment cost
especially for existing lower-layers.  This is my main motivation to
come up with EAP-KDE method.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 20:29:32 -0800

> No.  KDE0 is sent before knowing peer identity.

Hi Yoshi,

Can that be done without modifying authenticators?

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 20:32:17 -0800

> have not heard a complaint on 802.11i 4-way handshake latency.

Consider that not to be the case any more.  I am complaining. :)  More 
seriously, handover latency of 10-20ms is a target in some networks.

If there is a sufficient budget for handover, we probably need to do 
nothing for reauthentication.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Feb 2008 00:39:19 -0500

> Can that be done without modifying authenticators?

That's a different issue, but modification to EAP method layer of
authenticator implementation is needed because an authenticator for
this method is implemented as a stand-alone authenticator.  However,
no modification to EAP-layer and lower-layer of both authenticator and
peer implementations is needed.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Feb 2008 00:42:42 -0500

> seriously, handover latency of 10-20ms is a target in some networks.

I have not heard of 10-20ms handover latency requirement.  If we
assume there is such a requirement, then none of ERX and EAP-KDE will
satisfy the requirement because one AAA roundtrip can be even more
than 20ms even with local AAA servers.  Note that pre-authentication
can eliminate such a post-handover AAA roundtrip.

Yoshihiro Ohba

>>> I have reviewed draft-ohba-eap-kde-01 before and it does not meet 
>>> fast reauthentication goals.  Please see below:
>>>
>>> The number of roundtrips on the access link is 3, if we take 
>>> connection open or an equivalent into account.  With ERP, the peer 
>>> can start sending authenticated data after 1 RT.
>>>
>>> In other access technologies, the handover latency requirements are 
>>> more stringent and they have already adopted ERP and waiting for 
>>> publication of the ERP RFC.  Without further optimizations, 802.11 
>>> with 3 RTs or more for connection setup and EAP-KDE and 2 more for 
>>> the 4-way exchange has little to no hope of really achieving low 
>>> handover latency.
>>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 25 Feb 2008 22:12:27 -0800

Thanks for your response Yoshi.

regards,
Lakshminath

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 25 Feb 2008 23:55:18 -0800

Yoshihiro Ohba <> scribbled on Tuesday, February 26, 2008 10:12 AM:

>>         <-- EAP-Request/KDE{KDE4}    <-- AAA{KDE3, authorization
>>         data} --> EAP-Response/KDE{}
>>         <-- EAP-Success
>> 
>> Step 1.  peer --> authenticator: Connection Setup(Identity) Step 2.
>> Authenticator extracts the identity and sends it to backend and

The peer identity is typically used for AAA routing & determination of
the EAP method(s) to be used with the peer.  It appears that this
protocol requires that KDE be the default EAP method for all peers on a
hokey-enabled network.  However, there is a little problem here: in KDE,
the server S is necessarily a "home" server, since it is assumed that
the peer has a pre-established SA with S, which would not be true in the
case of a visited domain. In KDE, message KDE0 is optional but if
included must contain the identity of S (the SID).  KDE0 is not optional
in EAP-KDE; therefore, the authenticator (or "third-party" in KDE terms)
must know the identity of the peer's home server (in order to construct
KDE0) _before_ it knows the identity of the peer.  Maybe it's just me
but I really think that requiring machine clairvoyance in IETF protocols
is a bit much ;-).

...

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Feb 2008 19:18:06 -0500

>>>>> "Lakshminath" == Lakshminath Dondeti <[email-masked]> writes:

    Lakshminath> Sam and I talked about adding more text in the
    Lakshminath> security considerations saying that the home ER
    Lakshminath> server may choose to include this TLV when it knows
    Lakshminath> that it has delivered a specific DSRK to one and only
    Lakshminath> server (in addition to the secure channel case, which
    Lakshminath> is more of a direct indication of an authorized
    Lakshminath> delivery).  I have not yet added that claim. I plan
    Lakshminath> to add that to the next revision (hope to submit that
    Lakshminath> before tomorrow's deadline).

Hmm.  That's not what I remember at all.

I remember discussing that the home ER server needed to make sure that
a DSRK was not given out to two different domains.  So, a given DSRK
MUST NOT be handed out if that DSRK has already been handed out unless
the home ER server can guarantee that the entity receiving the two
DSRKs is the same.  For this to work, we need to make sure that a home
ER server declining to hand out a DSRK creates a performance but *not*
a correctness problem.  Lakshminath and I walked through the
situations where this comes up and under normal operation you don't
run into a need to hand out a DSRK more than once unless a cache
expires somewhere.

This requirement is not really the same or related to the
authorization requirement.  It may be the case that whenever you can
authorize a domain it would be safe to hand out the DSRK to that
domain more than once.  However it may well be easier to prove that
you are handing a key to the same entity than to prove that entity is
particularly authorized for anything.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 26 Feb 2008 10:53:16 +0100

Hi Glen,
> hokey-enabled network.
correct.
>   However, there is a little problem here: in KDE,
> case of a visited domain.
Not in the case of EAP-KDE. As the I-D states:

"EAP-KDE creates a new usage of KDE to distribute a per-authenticator
key from a HOKEY server to an authenticator."

Morever, please read section 4 about visited domain.

>  In KDE, message KDE0 is optional but if
> in EAP-KDE; 
EAP-KDE is a method to transport KDE. KDE0 is optional in KDE.
why are you assuming KDE0 may not be optional in EAP-KDE?.
> therefore, the authenticator (or "third-party" in KDE terms)
> KDE0) _before_ it knows the identity of the peer.  
No, from the above.

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 26 Feb 2008 12:35:18 +0100

Hi Lakshminath,

Lakshminath Dondeti wrote:
> reauthentication goals. 
Please see my comments inline.

>  Please see below:

The reality is EAP-KDE is only adding a roundtrip in the ACCESS LINK 
(between peer and authenticator) with respect to ERP,
and NOT between authenticator and server, which is actually the bottleneck.

EAP-KDE:

ERP:

<-- EAP Initiate/Re-auth-Start
--> EAP Initiate/Re-auth --> AAA{EAP Initiate/Re-auth}
<-- EAP Finish/Re-auth <-- AAA{EAP Finish/Re-auth}

As you may observe, this additional roundtrip is exchanged between peer 
and authenticator. Furthermore, EAP-Response/KDE{} and EAP Success are 
very simple messages, so i would expect a really low processing time. So 
my question is how many ms do you expect in that exchange in order to 
affirm it does not meet a fast re-authentication goal?.

Furthermore, as Yoshi mentioned pre-authentication is also possible 
(e.g. based on EAP-KDE) and that time would not affect at all.

In any case, the situation is that ERP would require modifications in 
EAP-layer and existing EAP lower-layers to operate, but EAP-KDE avoids 
those modifications (at the cost of an additional single roundtrip in 
the access link which, to me, it should not be a major problem).

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 26 Feb 2008 04:45:49 -0800

Rafa Marin Lopez <> scribbled on Tuesday, February 26, 2008 6:35 PM:

...

> As you may observe, this additional roundtrip is exchanged between
> peer and authenticator. Furthermore, EAP-Response/KDE{} and EAP
> Success are very simple messages, so i would expect a really low
> processing time. So my question is how many ms do you expect in that
> exchange in order to affirm it does not meet a fast re-authentication
> goal?. 
> 

Leaving aside the fact that EAP-KDE simply doesn't work without the
assumption of magic (as I pointed out earlier), it also requires the
creation and maintenance of a huge new infrastructure to enable the
pair-wise SAs required between the "third-parties" (what are they,
anyway?) and KDE servers.  I guess that you don't see that as a major
problem, either; the folks who would be creating and maintaining it
might disagree...

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Feb 2008 08:46:10 -0500

Glen,

> problem, either; the folks who would be creating and maintaining it

In the latest version of KDE draft (draft-ietf-hokey-key-mgm-03.txt),
end-to-end security is NOT mandatory between third party and server,
reflecting the recent consensus on allowing hop-by-hop security.
So EAP-KDE works with hop-by-hop security.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Feb 2008 09:40:26 -0500

(Let me change the subject)

Glen,

The KDE server does not have to be located in the home domain.  It can
be located in a visited domain as well.

The KDE server can be discovered during EAP-KDE bootstrapping
procedure by using DNS or DHCP, as specified in Section 4.  So while
Server ID (SID) in KDE0 would only be able to carry the identity of a
KDE server in the visited domain (because the authenticator will not
know about the home domain of the peer before obtaining the identity
of the peer), the SID in KDE0 is not really needed since the peer
already knows the KDE server before running EAP-KDE.

Hope this helps,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 26 Feb 2008 10:15:22 -0800

On 2/26/2008 3:35 AM, Rafa Marin Lopez wrote:
>> The number of roundtrips on the access link is 3,
>>  if we take connection open or an equivalent into account.  With ERP, 
>> the peer can start sending authenticated data after 1 RT.
>>
>> with 3 RTs or more for connection setup and EAP-KDE and 2 more for the 
>> 4-way exchange has little to no hope of really achieving low handover 
>> latency.
> 

Hi Rafa,

Not according to people who design fast handover schemes.  I understand 
the issues with the backhaul, but in addition to that if the idea is to 
provide voice call continuity and if we want to budget for less than 
favorable radio conditions, cell density etc., we don't have the luxury 
of as many round trips as we want even in the access link.

> affirm it does not meet a fast re-authentication goal?.

Simple is good, but not sufficient; how soon can the data packets be 
transmitted after handover is the issue.  It helps me to think about 
voice call continuity.

> the access link which, to me, it should not be a major problem).

It turns out modifications to authenticators was the issue and EAP-KDE 
would also require modifications to the authenticators.  As I noted 
elsewhere, any modifications to lower layers are quite minimal.

Finally, if a link layer is to provide fast reauthentication, they need 
to do some work; EAP is just one aspect.  So, the idea that somehow we 
can drop in a new IETF protocol would be everything that needs to be 
done for fast reauthentication is somewhat sophomoric.  Last I checked, 
the 11r specification has more than 100 pages.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 27 Feb 2008 19:01:50 -0800

Sam,

Sorry about the disconnect.  I might be using the word authorized in a 
different way than you mean to use it.

Below is the new text:

If the home ER server can directly verify the local ER server's	
			authenticity and knows that only the local ER server gets	
			access to the DSRK, it MAY include the Authorization Indication	
			TLV. This is typically possible when there is end-to-end	
			authentication between the home ER server and the local ER	
			server.

Next, a description of the new TLV:

Authorization Indication: This is a TLV payload. The Type is	
			6. This attribute MAY be included when a DSRK is delivered to	
			a local ER server and if the home ER server can directly	
			authenticate the local ER server and can assure to the peer	
			that only the authorized local ER server shall receive the	
			DSRK. The value contains an authentication tag computed over	
			the entire packet, starting from the first bit of the code	
			field to the last bit of the crypto-suite field, with the value	
			field filled with all 0s for the computation. The key used for	
			the computation MUST be derived from the EMSK with key label	
			"DSRK Delivery Authorized [email-masked]" and optional data	
			containing an ASCII string representing the key management	
			domain that the DSRK is being derived for.

Text in Security Considerations:

When the server can directly verify the authenticity of the	
			entity that receives the DSRK and if it knows that no other	
			entity can receive the DSRK, it includes the Authorization	
			Indication TLV to assure the peer that DSRK delivery is secure.	
			If the Authorization Indication TLV is not present, the peer	
			has no such assurance and assumes that DSRK misuse might be	
			plausible.

If the wording is incorrect, please suggest changes.  As per our 
conversation, we agree in principle.  Additional notes inline:

> Hmm.  That's not what I remember at all.

Let me walk through line by line to see where the disconnect might be.

> a DSRK was not given out to two different domains.  

Agreed.

>So, a given DSRK
> DSRKs is the same.  

To ensure this, the home ER server needs to identify that the entity 
receiving the two DSRKs is the same.  When it can, it may want to 
indicate that fact to the peer and that is what the new mechanism supports.

> For this to work, we need to make sure that a home
> domain more than once.  

Perhaps here is the disconnect.  If the home ER server can identify that 
the entities asking for a DSRK at different points in time are the same, 
it can hand out DSRK more than once.  Are you saying that the 
"authorized domain case" is different?

> However it may well be easier to prove that
Agreed.  So, perhaps my wording is incorrect.  I used the phrase "one 
and only" server to imply that entity receiving the DSRK is the same 
across multiple runs of the protocol.

regards,
Lakshminath
_______________________________________________
HOKEY mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hokey

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 28 Feb 2008 14:14:28 -0500

We might want to compare "luxury" to allow an additional single
roundtrip within access network vs. "luxury" to require changes to
existing lower layers and eliminate the additional single roundtrip
within access network.

The motivation of EAP-KDE is mostly based on the concern on the latter
luxury.

Yoshihiro Ohba