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. 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 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). > > 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. > > 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. > > 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. 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. > > 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&dTag= > 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