Subject: Re: Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 5 Feb 2008 23:26:53 -0800

In reading this draft (-09 version) I came up with a few questions and
comments:

Section 3 -

Section 3 is a bit confusing it seems that much of the text is section
3.1 (detailed description of exchanges) should go into section 3.0
because it seems that much of the process should be the same for local
or remote cases.  Currently it is difficult to really tell what pertains
to local, remote and both.  

It does not appear to be clear how the peer knows if it is in the "home"
case or the "local" case, whether the network is capable of ERX (and
vice versa) or how the peer knows what key to use.  Perhaps I missed
this elsewhere in the document.  

Section 4 - 

Section 4.1.1 duplicates text in
internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt.   It really
should not.  It should reference KDF functions instead of PRFs.  I
believe if you replace prf+ with KDF it would be fine.  Do you want to
use the naming defined in
internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt or are you
specifying your own?  Are these key names really necessary?  They do no
appear to be used anywhere? 

Why such a long key label?

Section 5 - 

Section 5.1

What state are you referencing here? I don't think the CalledStation-ID
is what you want to reference, I believe RADIUS routing is typically
done with the username when EAP is used.  Why is it only RECOMMENDED to
maintain this state?  It seems either it is a MUST or it doesn't matter.
In general authenticators do not do routing, AAA does routing.
Authenticators copy the correct attributes from EAP into the correct
attributes in the AAA message.  This seems much more complicated
(routing, multiple attributes TLVs etc).   Its not clear if the 3
sub-bullets of the first bullet refer to what the authenticator needs to
do or the peer needs to do.   It seems that the authenticator should be
able to extract a single field from the peer message to determine what
to do with it.  Either it will handle it locally or it will pass the
message within the AAA protocol copying the appropriate field into the
message. 

Is the integrity checksum a keyed hash or MAC (if so why use another
term?)?  If so what key is used?  If a key is used in the context in the
packet enough to determine the key?  Is it possible that more that one
EMSK has been generated by the same peer?  

Why must the authenticator rely upon the information cached from the EAP
exchange, isn't there enough information in ERX messages?   The whole
routing section is complex and is not something that authenticators
generally do now.  Why do you need an alternate to R1KName-NAI?  Why is
the peer name necessary?  Why isn't a R1KName an NAI? Should the R1Kname
sent by the server match the one sent by the client?

Section 5.1.1

It seems there is another option other than obtaining a DSRK from the
home domain, you may retrieve the rRK derived from the DSRK.  There are
also key distribuiton attributes for RADIUS defined in
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt and
http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-08.txt.
Is there a reason why we need to diverge? 

Section 5.2

Ditto of most of the concerns in 5.1/5.1.1. Do we need two sections?

Section 5.3

It would be helpful if the identity field  (R1Kname-NAI) was in a
deterministic place within the packet so the authenticator has less work
to do to extract it.  I don't see why peer name is useful (or
R1Kname-TLV). 

-----Original Message-----
From: The IESG [mailto:[email-masked]] 
Sent: Thursday, January 24, 2008 8:13 AM
To: IETF-Announce
Cc: [email-masked]
Subject: Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP
Re-authentication Protocol (ERP)) to Proposed Standard 

The IESG has received a request from the Handover Keying WG (hokey) to
consider the following document:

- 'EAP Extensions for EAP Re-authentication Protocol (ERP) '
   <draft-ietf-hokey-erx-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-02-07. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-08.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15997&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

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

Thanks for the review Joe.

> this elsewhere in the document.  

We worked to clarify this in the last revision.  I will make another 
pass at it while preparing v10 and run it by you (probably sometime 
tomorrow).

> appear to be used anywhere? 

This is true.  I think we were trying overly hard to name everything 
(one of 4962 things?) and I realized earlier that we have a procedure to 
even name the rMSKs.  But, it is not clear whether the rMSK names will 
be used anywhere.

I just sent that email about naming and so we should be able to clean 
this stuff up now if that is acceptable to everyone.

On duplication, it seems we have two strong opinions here.  You are 
suggesting less duplication and Alan is suggesting more :).  I guess we 
may have actually achieved the (un)happy medium!

My opinion is that we should have less duplication, perhaps to the 
extent you are suggesting, so the idea is to not have to update (when we 
need) text in two different drafts.  That said, there are some usage 
specific properties to consider, specifically we are trying to specify 
crypto-agility in case of ERP and for those reasons, the derivations may 
need to be spelled out again.

In the next revision, I'll see what I can do to reduce the duplication 
(but before that I will talk to Alan to see what he wants).

> Why such a long key label?

Which one?
"EAP Re-authentication Root [email-masked]"?  I guess we could call it 
"EAP rRK" but that might be an abbreviation for something else in the 
future.  Please suggest another name :), but hopefully one that does not 
involve changing the entire document (I don't want to introduce errors 
with too many global changes).

> message within the AAA protocol copying the appropriate field into the

I see.  I will make it clear and separate as to what the peer must and 
what the authenticator must do.  I think we have done that in the 
sections after that, but I can see the ambiguity.

On the AAA stuff and the reference to state, could you please suggest 
text?  Thanks.  We should say the AAA client in the ER authenticator to 
be more precise.  I was going to talk to Alan about the AAA stuff later 
this week, but in the meanwhile, please suggest text in this case and 
that'll help clean up that text.  Thanks.

> term?)?  

Integrity checksum is the most generic term (I would think that keyed 
hash would not be sufficiently generic; I guess MAC might work, but 
people have had problems with that word, especially folks with L2 
background).  I do see that there are references to authentication tags 
and integrity checksums.  There is no need for multiple terms (or at 
least we should say they mean the same thing).

> If so what key is used?  If a key is used in the context in the

The key is rIK and there is an rIKname to refer to it.  With the new 
proposal, the rIKname or keyname, it should be called now, will be the 
emskname and in the context of ERP we use either the DS-rIK or an rIK in 
the integrity checksum calculation; whether it is the rIK or the DS-rIK 
is determined by the NAI used.  If that is ambiguous, we need to work on 
fixing the ambiguity :).  Please let me know.

> exchange, isn't there enough information in ERX messages?   

Good question.  I will try and dig up information on why this is necessary.

> The whole

There are some options here.  In fact, we used to have the option of 
server-ID and we got rid of that to remove some of the complexity (that 
was introduced at some point because someone suggested it, but later no 
one in the WG cared for it).

So, now there are three combinations really.
The first is rIKname, Peer ID and
the second is rIKname-NAI
we also support rIKname alone, but that works only if authenticator have 
a default ER server to send all ER messages to.

Perhaps there is scope for simplification here.  Please see below ...

> Is there a reason why we need to diverge? 

No reason to diverge.  In fact, we do intend to use keywrap.  Charles 
has some ideas about how to bring that all together.  I am waiting to 
hear from him.  I have spoken to Glen before and he gave some pointers 
too.  I am going to talk to Alan as well and get his thoughts from his 
DTLS draft perspective.  The idea is to specify attributes for 
requesting the DSRK and an attribute to send the DSRK, the keyname and 
lifetime.  Either keywrap or dtls can be used protect such request and 
response.

> Ditto of most of the concerns in 5.1/5.1.1. Do we need two sections?

5.1 is bootstrapping and 5.2 is the protocol run.  Two sections are 
better to clarify the distinction.  I will look for any obvious 
duplication and try to get rid of it.  But here again we get into 
duplication vs. too little detail (perhaps we can get rid of the 
duplication here since it's all in one document).

> to do to extract it.  I don't see why peer name is useful (or
Yeah, as I noted earlier, there may be scope for further simplification 
here.  To the extent I care, I am happier with fewer options (I guess I 
have said it many times already that I want this simple, and efficient).

If we adopt the root key name scheme we discussed a little while ago, 
perhaps the peer-ID is not necessary.  Either the ER server pointed to 
by the NAI in the keyname-NAI (instead of rIKname-NAI) can identify the 
keyname or not.  If it does not have keys corresponding to the key 
referred to by "keyname" all bets are off anyway.

I will think some more to make sure.  In the meanwhile, other folks can 
try and see if we are simplifying too much (i.e., losing functionality).

We were thinking of privacy considerations at some point and noted that 
the server could send encrypted rIKnames in the EAP-Finish/Re-auth 
messages.  If there is loss of synchronization, then the peer ID can be 
used to resync.  That is one case where the peer ID would be useful.  A 
few meetings ago, the WG didn't care about privacy considerations.  I 
guess we can drop the peer ID now.  Like I said, I will think some more, 
and see if there are any other corner cases.

Thanks again Joe.

regards,
Lakshminath

> HOKEY mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/hokey
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 6 Feb 2008 22:00:09 -0800

Thanks for your quick response, comments inline: 

> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Wednesday, February 06, 2008 1:03 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP 
> Extensions for EAP Re-authentication Protocol (ERP)) to 
> Proposed Standard
> 
> > or remote cases.  Currently it is difficult to really tell what 
> > pertains to local, remote and both.
> > 
> We worked to clarify this in the last revision.  I will make 
> another pass at it while preparing v10 and run it by you 
> (probably sometime tomorrow).
> 
> > 
> > Section 4 -
> > 
> > specifying your own?  Are these key names really necessary? 
>  They do 
> > no appear to be used anywhere?
> 
> This is true.  I think we were trying overly hard to name 
> everything (one of 4962 things?) and I realized earlier that 
> we have a procedure to even name the rMSKs.  But, it is not 
> clear whether the rMSK names will be used anywhere.
> 
> I just sent that email about naming and so we should be able 
> to clean this stuff up now if that is acceptable to everyone.
> 
[Joe] If this is what we discussed I believe it will help, I will take a
look at that. 

> On duplication, it seems we have two strong opinions here.  
> You are suggesting less duplication and Alan is suggesting 
> more :).  I guess we may have actually achieved the (un)happy medium!
> 
> My opinion is that we should have less duplication, perhaps 
> to the extent you are suggesting, so the idea is to not have 
> to update (when we
> need) text in two different drafts.  That said, there are 
> some usage specific properties to consider, specifically we 
> are trying to specify crypto-agility in case of ERP and for 
> those reasons, the derivations may need to be spelled out again.
> 
[Joe] I think if we need to spell out the derivations in this document
there is a problem.  This would indicate there is something wrong with
the EMSK document that needs to be fixed. 

> In the next revision, I'll see what I can do to reduce the 
> duplication (but before that I will talk to Alan to see what 
> he wants).
> 
> > 
> "EAP Re-authentication Root [email-masked]"?  I guess we could 
> call it "EAP rRK" but that might be an abbreviation for 
> something else in the future.  Please suggest another name 
> :), but hopefully one that does not involve changing the 
> entire document (I don't want to introduce errors with too 
> many global changes).
> 
[Joe] I suppose it doesn't matter much, it just seems that name is
unnecessarily long.  The point of registering the labels with IANA is to
avoid conflicts. 

> > 
> > Section 5 -
> > 
> > Section 5.1
> > 
> > What state are you referencing here? I don't think the 
> > CalledStation-ID is what you want to reference, I believe RADIUS 
> > routing is typically done with the username when EAP is 
> used.  Why is 
> > it only RECOMMENDED to maintain this state?  It seems 
> either it is a MUST or it doesn't matter.
> I see.  I will make it clear and separate as to what the peer 
> must and what the authenticator must do.  I think we have 
> done that in the sections after that, but I can see the ambiguity.
> 
> On the AAA stuff and the reference to state, could you please 
> suggest text?  Thanks.  We should say the AAA client in the 
> ER authenticator to be more precise.  I was going to talk to 
> Alan about the AAA stuff later this week, but in the 
> meanwhile, please suggest text in this case and that'll help 
> clean up that text.  Thanks.
> 
[Joe] I think the draft prescribes a bit too much about the back end AAA
operation.  AAA routing etc should work pretty much as it does to day if
this is going to be at all deployable.  I'll try to put some more
specific text together. 

> Integrity checksum is the most generic term (I would think 
> that keyed hash would not be sufficiently generic; I guess 
> MAC might work, but people have had problems with that word, 
> especially folks with L2 background).  I do see that there 
> are references to authentication tags and integrity 
> checksums.  There is no need for multiple terms (or at least 
> we should say they mean the same thing).
> 
> > If so what key is used?  If a key is used in the context in 
> the packet 
> > enough to determine the key?  Is it possible that more that 
> one EMSK 
> > has been generated by the same peer?
> 
> The key is rIK and there is an rIKname to refer to it.  With 
> the new proposal, the rIKname or keyname, it should be called 
> now, will be the emskname and in the context of ERP we use 
> either the DS-rIK or an rIK in the integrity checksum 
> calculation; whether it is the rIK or the DS-rIK is 
> determined by the NAI used.  If that is ambiguous, we need to 
> work on fixing the ambiguity :).  Please let me know.
> 
[Joe] I found it confusing in this section, it was not clear that if the
domain is not communicated in the lower layer how the peer decided to
use which key to use.  I think it is that if they are using their home
NAI then they use the rIK.  I'm not sure this is spelled out in the
document. 

> > generally do now.  Why do you need an alternate to 
> R1KName-NAI?  Why 
> > is the peer name necessary?  Why isn't a R1KName an NAI? Should the 
> > R1Kname sent by the server match the one sent by the client?
> 
> There are some options here.  In fact, we used to have the 
> option of server-ID and we got rid of that to remove some of 
> the complexity (that was introduced at some point because 
> someone suggested it, but later no one in the WG cared for it).
> 
> we also support rIKname alone, but that works only if 
> authenticator have a default ER server to send all ER messages to.
> 
[Joe] Isn't the r1Kname alone a valid NAI?

> > home domain, you may retrieve the rRK derived from the DSRK.  There 
> > are also key distribuiton attributes for RADIUS defined in 
> > 
> No reason to diverge.  In fact, we do intend to use keywrap.  
> Charles has some ideas about how to bring that all together.  
> I am waiting to hear from him.  I have spoken to Glen before 
> and he gave some pointers too.  I am going to talk to Alan as 
> well and get his thoughts from his DTLS draft perspective.  
> The idea is to specify attributes for requesting the DSRK and 
> an attribute to send the DSRK, the keyname and lifetime.  
> Either keywrap or dtls can be used protect such request and response.
> 
[Joe] Neither of these are referenced in the draft instead the draft
references another set of documents.  It would be good to use a
consistent set of attributes to carry keys.  

> 5.1 is bootstrapping and 5.2 is the protocol run.  Two 
> sections are better to clarify the distinction.  I will look 
> for any obvious duplication and try to get rid of it.  But 
> here again we get into duplication vs. too little detail 
> (perhaps we can get rid of the duplication here since it's 
> all in one document).
> 
> > 
> > Section 5.3
> > 
> > deterministic place within the packet so the authenticator has less 
> > work to do to extract it.  I don't see why peer name is useful (or 
> > R1Kname-TLV).
> > 
> > 
> Yeah, as I noted earlier, there may be scope for further 
> simplification here.  To the extent I care, I am happier with 
> fewer options (I guess I have said it many times already that 
> I want this simple, and efficient).
> 
> If we adopt the root key name scheme we discussed a little 
> while ago, perhaps the peer-ID is not necessary.  Either the 
> ER server pointed to by the NAI in the keyname-NAI (instead 
> of rIKname-NAI) can identify the keyname or not.  If it does 
> not have keys corresponding to the key referred to by 
> "keyname" all bets are off anyway.
> 
> I will think some more to make sure.  In the meanwhile, other 
> folks can try and see if we are simplifying too much (i.e., 
> losing functionality).
> 
> We were thinking of privacy considerations at some point and 
> noted that the server could send encrypted rIKnames in the 
> EAP-Finish/Re-auth messages.  If there is loss of 
> synchronization, then the peer ID can be used to resync.  
> That is one case where the peer ID would be useful.  A few 
> meetings ago, the WG didn't care about privacy 
> considerations.  I guess we can drop the peer ID now.  Like I 
> said, I will think some more, and see if there are any other 
> corner cases.
> 
> Thanks again Joe.
> 
> regards,
> Lakshminath
> 
> 
> > 
> > 
> > final comments on this action.  Please send substantive comments to 
> > the [email-masked] mailing lists by 2008-02-07. 
> Exceptionally, comments 
> > may be sent to [email-masked] instead. In either case, please retain 
> > the beginning of the Subject line to allow automated sorting.
> >

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 08 Feb 2008 00:56:30 -0800

Hi Joe,

Sorry for the delayed response.  I was without a functional laptop for 
the better part of the last 30 or so hours and so I am behind on a few 
things here.

Please see inline:

> [Joe] If this is what we discussed I believe it will help, I will take a

Yes, and I am going to poll some folks to make sure that is ok with them 
too.  Please review; if you want I can provide details (might ask Dan 
for some help) for your review.

> the EMSK document that needs to be fixed. 

Yeah, I tend to agree.  I am talking to Alan soon and after that propose 
a direction here.

> this is going to be at all deployable.  I'll try to put some more

Thanks.  In fact, with the simplification you proposed -- use 
keyname/rIKname-NAI as the only attribute -- we can probably get rid of 
the references to the stored state etc.

> NAI then they use the rIK.  I'm not sure this is spelled out in the

Ok, will check and clarify as necessary in the next revision.

> [Joe] Isn't the r1Kname alone a valid NAI?

We differentiate between rIKname and rIKname-NAI, but if I understand 
your point, you are suggesting using rIKname-NAI and that's that.  That 
kind of simplification is being suggested by a few folks and so that is 
what we'll do.

> consistent set of attributes to carry keys.  

It is a chain of references.  I have spoken to Glen about this a few 
times and the intent is definitely to reuse the work already in progress :).

I will writeup a brief note on the attributes and propose changes to the 
WG and ask if there are objections for the simplification.

regards,
Lakshminath