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: On 2/6/2008 10:00 PM, Joseph Salowey (jsalowey) wrote: > 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. 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. > >> 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. Yeah, I tend to agree. I am talking to Alan soon and after that propose a direction here. > >> 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. 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. > >>> 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. Ok, will check and clarify as necessary in the next revision. > >>> 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? 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. > >> 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. 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 > >>> 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