Thanks for your quick response, comments inline: > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx] > Sent: Wednesday, February 06, 2008 1:03 AM > To: Joseph Salowey (jsalowey) > Cc: hokey@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP > Extensions for EAP Re-authentication Protocol (ERP)) to > Proposed Standard > > Thanks for the review Joe. > > On 2/5/2008 11:26 PM, Joseph Salowey (jsalowey) wrote: > > 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. > > 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 - > > > > 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? > > 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). > > > > > Why such a long key label? > > Which one? > "EAP Re-authentication Root Key@xxxxxxxx"? 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. > > 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. > > 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. > > > > Is the integrity checksum a keyed hash or MAC (if so why > use another > > 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 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. > > > > Why must the authenticator rely upon the information cached > from the EAP > > 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 > > 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? > > 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. > [Joe] Isn't the r1Kname alone a valid NAI? > Perhaps there is scope for simplification here. Please see below ... > > > > > 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? > > 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. > > > > Section 5.2 > > > > 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). > > > > > 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). > > > > > 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 > > > > > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@xxxxxxxx] > > Sent: Thursday, January 24, 2008 8:13 AM > > To: IETF-Announce > > Cc: hokey@xxxxxxxx > > 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 ietf@xxxxxxxx mailing lists by 2008-02-07. > Exceptionally, comments > > may be sent to iesg@xxxxxxxx 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&dTa > > g= > > 15997&rfc_flag=0 > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > > HOKEY mailing list > > HOKEY@xxxxxxxx > > http://www.ietf.org/mailman/listinfo/hokey > > > _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf