Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak
Zhen Cao <zehn.cao@gmail.com> Wed, 11 January 2012 02:59 UTC
Return-Path: <zehn.cao@gmail.com>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FD621F85DF for <hokey@ietfa.amsl.com>; Tue, 10 Jan 2012 18:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level:
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIyt0OJnlm+8 for <hokey@ietfa.amsl.com>; Tue, 10 Jan 2012 18:59:07 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8DBB21F85DD for <hokey@ietf.org>; Tue, 10 Jan 2012 18:59:07 -0800 (PST)
Received: by iakl21 with SMTP id l21so457712iak.31 for <hokey@ietf.org>; Tue, 10 Jan 2012 18:59:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=msDS2n/OzFzucMcJ+C7LXRTbFmURs/kHXvnZtuXhfUY=; b=HpORDsGd8AtAwC+GgaUWSpH5uO1DfHUl41IKDbHA5AlCe+ohHihf1RjS5sL6Ia8reh n4QvqHGO9uNhKdkYsNvyO12/PFwkZEGbWMtjtB1E35ix8rJQ1tymB0ySeTH4mNkxvgJQ rBSHYdI1CF0PDWmCcURTfvHDWjC/LlZBNV7J0=
MIME-Version: 1.0
Received: by 10.50.10.225 with SMTP id l1mr5156355igb.9.1326250747347; Tue, 10 Jan 2012 18:59:07 -0800 (PST)
Received: by 10.42.174.67 with HTTP; Tue, 10 Jan 2012 18:59:07 -0800 (PST)
In-Reply-To: <4ECE4300.8070901@cs.tcd.ie>
References: <4ECA9AD5.3050409@cs.tcd.ie> <B5D72BE948614EB6BA4D5DCDD907074C@china.huawei.com> <4ECE2EC9.6040408@cs.tcd.ie> <03FB617435B7413D8F0381C5D4689806@china.huawei.com> <4ECE4300.8070901@cs.tcd.ie>
Date: Wed, 11 Jan 2012 10:59:07 +0800
Message-ID: <CAProHAT4dSpfeAqbDcH7YNiZC6N0bQ9Wgnq3EqzpvXkHoTAx6g@mail.gmail.com>
From: Zhen Cao <zehn.cao@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: Glen Zorn <glenzorn@gmail.com>, "Cao, Zhen" <caozhen@chinamobile.com>, hokey@ietf.org
Subject: Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2012 02:59:09 -0000
Hi, Stephen: Sorry for late reply. I have skipped the comments that have already been addressed on the list. Please see my replies inline. #1, p4 - Figure 1 - should that be "CAP authorized"? [CZ]: Yes.CAP needs to be authorized rather than authenticated. Will fix this in the new version. #2, p4 - I can see why you might not want to make figure 1 longer, but it seems to stop short - shouldn't it end with the Peer and CAP doing stuff together? Maybe add another figure that shows the latter exchange? [CZ]: That’s a good suggestion. We will remove interaction between CAP and the server in the figure1 and add another figure to show such process. #3, p5 - if you could tie the various actions described back to figure 1, that'd help the reader I think. (I'm not insisting on that, just asking:-) [CZ]: Reasonable. #4, p5 - Would this entire description benefit from more 2119 language? (As above:-) [CZ]: Okay. #5, p5 - "If either the peer or the SAP does not support ERP/AAK, it should fall back to full EAP authentication." Is that right? I guess I wondered if the first fallback might be ERP without AAK and then "full" EAP but maybe I'm confused. [CZ]: No, you can not fall back to ERP since you as the peer are still not leaving the previous attachment point. ERP should only be used when you are connecting to the new attachment point. #6, p5, 2nd para - s/The SAP may/The SAP MAY/ or s/may/can/? And in that same para s/it is silently/it MUST be silently/ (if that's a new MUST I guess?) [CZ]: Okay. #9, p5 - Does the SAP need to verify the integrity of the message at step 2? You don't say. If it doesn't then bad things might be enabled... [CZ]: You are right, will add this in the update. #10, p5/6 - the key hierarchy text is dense (like me:-) It'd have helped me to know which keys are new and which KDFs are used. How come rIK isn't mentioned? What does "can be used to derive" mean? That's probably all just my ignorance of ERP though but there's not enough here to understand what's going on. I suspect best will be to fix whatever else needs fixing and then return to this at the end. [CZ]: The key hierarchy is quite similar to one defined in the ERP (i.e.,RFC5296)What is new in the key hierarchy is pRK, pIK, pMSK. They have different usage from rRK, rIK,rMSK. You are right, KDF needs to specified for pRK, pIK, pMSK rather than just say “can be used to derive”. #11, p7 - I assume that the 'E' flag is set (value 1) to indicate early-authentication and unser (valule 0) to indicate that early-authentication is not in use. That may be a general EAP or ERP convention or it may be worth saying, I dunno. (There are a few occurrences of this.) [CZ]: Good suggestion, will add them in the update. #12, p7 - In 5.2 you say reserved bits MUST be set to zero and ignored on reception, but in 5.1 you don't say "ignored on reception." Is there a real difference or is that just an editorial glitch? [CZ]: That’s one nits we need to fix. Thank for catching this. #13, p7 - Are there any I18N considerations applying to the CAP-Identifier or keyName-NAI TLVs? I seem to recall hearing recent discussion about that somewhere else but can't recall if that'd apply here or not. (And so I don't know if something ought be said about I18N here.) [CZ]: I18N consider may apply to KeyName-NAI since KeyName-NAI has realm part. We can add a note to say realm part of KeyName-NAI follows the use of internationalized domain names defined in the RFC5890, is that what you say? #14, p7 - In 5.2 is the behavior for handling the SEQ field well defined? If that's done elsewhere, a reference to that would seem needed or else someone might do something different here. [CZ]: Yes, SEQ is defined in ERP. We can add a reference to RFC5296. #17, p8 - Is the sequence number TLV called "Sequence"? If not, then are you allowed spaces in TLV names? [CZ]: In this draft, the sequence number is defined as TV format rather than TLV format. In the sequence number TV format, 8 bit type for sequence number will be followed by 16 bit Sequence number value. #19, p8 - cryptosuite - do you really need all three? Why not just make one mandatory to implement? [CZ]: HMAC-SHA256-128 is mandatory to implement, this has been described in the draft. #21, p8 - authentication tag, I think you need to say what to do if this doesn't verify - just ditch the packet? [CZ]: You are right. Actually the peer uses authentication tag to determine the validity of the EAP-Finish/Re-auth message originates at a server. If this doesn’t verify or authentication tag is not included in the response message, the message will be seen as invalid. The peer may fall back to full EAP authentication. #24, p9/10 - a bunch of the message field comments from 5.2 apply also to 5.3 [CZ]: Okay and will check for consistency. #25, p9 - Maybe I'm misreading the diameter notation - is it clear how many sub-TLVs are allowed to be in the ERP/AAK-Key TLV? Are they just presented and read in the order given? Do all four sub-TLVs need to be present each time? [CZ]: In the request (i.e.,EAP-Initiate/Re-auth) message to the server, only CAP-Identifier needs to be present In the response (i.e.,EAP-Finish/Re-auth) message from the server, all the sub TLV including CAP-Identifier and pMSK-lifetime and Cryptosuit should be present in the message. #26, p10 - From when is the lifetime of the pMSK calculated? (Same for the pRK-lifetime field.) Are these signed or unsigned 32-bit values? [CZ]: Upon receiving EAP-Initiate message from the peer, the server begin to calculate pRK,pMSK. Upon receiving EAP-Finish message, the peer begin to calculate PMSK,pRK. #27, p10 - Use one of "foo-lifetime" or "foo Lifetime" consistently. [CZ]: Okay. #28, p10 - I'm guessing that the lifetimes of some keys are related (maybe pIK and pMSK?) but you need to say so if that's the case. [CZ]: pIK and pMSK are both derived from the same root key(i.e.,pRK), therefore rIK and pMSK can share the same lifetime. That is to say, if the child keys share the same father, the child key can has the same lifetime, but the lifetime for father key should be set longer than child key. #29, p10 - What's an example of when the foo-lifetime sub-TLVs don't need to be present (i.e. why is this SHOULD and not MUST) [CZ]: One example is in the request message to the server, the foo-lifetime don’t need to be present. #30, p10 - Can there be zero elements in the list of cryptosuites? Is there a MAX number of elements? [CZ]: we think at least one element should be included in the cryptosuit list. The cryptosuit list is used to negotiate the right cryptosuit both the peer and the server use. #31, p10 - The list of cryptosuites desription says "The server SHOULD include this if the...was not acceptable and is being rejected." That's pretty ambiguous. What's the exception to the SHOULD? Does "is being rejected" mean that this MUST NOT be present when things worked ok? [CZ]: No. You have some misunderstanding to the cryptosuite descrption. We define Cryptosuite field in both EAP-initiate message and EAP-Finish message, We also allow carry Crytosuite List TLV( Type is 5) in both EAP-Initiate message and EAP-Finish message. If Cryptosuite included in the Cryptosuite field of EAP-Initiate message is rejected by the server, the server can indicate to the peer the cryptosuit list the server supports using cryptosuite list TLV. Does this clarify? #32, p10 - 5.4 talks about the "rRK Lifetime" but earlier you had a "pRK Lifetime" (or "pRK-lifetime") - what's up with the change there? [CZ]: is that your misunderstanding? rRK lifetime TV is not allowed here. #33, p11 - Section 7 says a new message "should" be defined - who's gonna do that where? Seems odd that its not here. [CZ]: Could be removed if you think odd. #34, p11 - section 8, 1st bullet says "*The* algorithm..." I think you mean the algorithm for calculating the authentication tag, but you need to say that. [CZ]: Okay. #35, p11 - How are KDFs named/replaced? [CZ]: KDF is abbreviation of Key Derivation Function which is specified in RFC5295. #37, p11 - Its not clear to me how the replay detection scheme works. [CZ]: The replay protection is quite similar to ERP, i.e., “ The peer increments the sequence number by one after it sends an ERP message The server sets the expected sequence number to the received sequence number plus one after verifying the validity of the received message and responds to the message. ” The different to ERP is the server and the peer may generate multiple pMSK for each CAP, therefore they should allocate different Sequence number for each PMSK. On Thu, Nov 24, 2011 at 9:13 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Hiya, > > Good stuff. I'd say there's enough there already to push out another > revision. Not sure if you want to wait on responses to the > other issues or not. You can figure that out with your co-authors > and WG chairs I guess. > > Cheers, > S. > > > On 11/24/2011 01:06 PM, Qin Wu wrote: >> >> Hi, >> ----- Original Message ----- >> From: "Stephen Farrell"<stephen.farrell@cs.tcd.ie> >> To: "Qin Wu"<bill.wu@huawei.com> >> Cc:<hokey@ietf.org>; "Glen Zorn"<glenzorn@gmail.com>; >> "Cao,Zhen"<caozhen@chinamobile.com> >> Sent: Thursday, November 24, 2011 7:47 PM >> Subject: Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak >> >> >>> >>> Hiya, >>> >>> On 11/24/2011 06:08 AM, Qin Wu wrote: >>>> >>>> Hi, Stephen: >>>> Thank for your valuable review. >>>> Here is my answer to the main issues I think and I skip most of >>>> editorial issues or nits issues. >>>> My coauthors will address the remaining issues. >>> >>> >>> Fine thanks. >>> >>>> ---------------------------------------- >>>> #7, p5 - "The rIK is used to protect this message." Is that right? >>>> How is rIK used to protect the message when the message contain >>>> rIK? I also wondered what "protect" means exactly - are the flags >>>> etc. all protected and how? >>>> >>>> [Qin] I think rIK should be corrected as pIK. pIK is used to protect the >>>> ERP message >>>> exchanged between the peer and the EA server. MSK used for normal EAP >>>> exchange should be further derived into >>>> other child keys. Alternatively, the pMSK can be derived into child >>>> keys. These child keys protect the ERP >>>> message exchanged between the peer and SAP. >>> >>> >>> Alternatively? Isn't it a bit late in the day (just before >>> IETF LC) to be considering such alternatives? >>> >>> If you do replace rIK with pIK please send the chaged paragraph >>> to the list before posting the draft to make sure its ok? >> >> >> [Qin]: I just explain how the message is protected between the peer and >> authenticator using >> the existing key derived from regular EAP exchange, however this is not >> the focus of this document. >> We more focus on how message is protected between the peer and the server >> using pIK. >> protect here means integrity protection or prevent the message sent over >> inscure channel being tampered. >> >>> >>>> #8, p5 - If I'm an authenticated user and I send the message at >>>> step 2 to the SAP, then can I get the SAP to forward the message to >>>> anything on the Internet? If not, where does it say how that's >>>> controlled? I guess the SAP knows based on its config and/or the >>>> authentication state of the peer but if so you should probably say >>>> that? >>>> >>>> [Qin]: SAP plays the role of authenticator should encapsulate the ERP >>>> message >>>> into AAA message and route the AAA message based on Realm part of >>>> KeyName-NAI. >>> >>> >>> That's misses the point. The Realm part of the KeyName-NAI is >>> supplied by the peer (the user). Is the SAP supposed to check >>> that its an ok Realm before encapsulating and sending the AAA >>> message? If so, you need to say so. If not, then that might >>> allow attack attempts and should be noted. >> >> >> [Qin]: Okay. >> >>> >>>> #15, p8 - You can only have one keyName-NAI in the message and that >>>> MAY have either the home domain name or the domain name to which >>>> the peer is currently attached for ite realm part. How does anyone >>>> know which to include when? Seems underspecified or missing a >>>> reference? >>>> >>>> [Qin]: This was discussed on the list many times. Based on the >>>> discussion, >>>> we take the following way: >>>> The peer should know where to send the message? If the peer >>>> communicate with the home server, the peer should carry home domain name >>>> in the keyName-NAI. If the peer communicate with the local server, the >>>> peer >>>> should carry local domain name in the keyName-NAI. >>>> The authenticator or local ER server in the path can know if the >>>> KeyName-NAI carry >>>> local domain name by comparing the domain name carried in KeyName-NAI >>>> with local >>>> domain name it has already known. >>> >>> >>> So perhaps its clear in your mind and on the list, but its >>> not clear in the document and it needs to be. >> >> >> [Qin]: Okay. we need to revise the document to reflect this. >> >>> >>>> #16, p8 - How are CAP-Identifier and "Sequence number" TLVs >>>> "associated"? >>>> >>>> [Qin]: Suppose multiple CAP-identifiers are carried in the ERP message, >>>> the same number of Sequence number TLVs should be carried with >>>> associated CAP-identifier. >>>> We can rely on the order to associate each other. >>> >>> >>> "rely on the order" is what you need to put in the document >>> then and you need to say what's ok and what's not. E.g. the >>> message field ordering for 3 of both could be >>> >>> capid1, capid2, capid3, seq1, seq2, seq3 >>> OR >>> capid1, seq1, capid2, seq2, capid3, seq3 >>> >>> Are both ok? What about: >>> >>> capid1, capid2, seq1, seq2, capid3, seq3 >>> >>> You need to say what's ok I think. >> >> >> [Qin]: Good point, we need to fix this. >> >>> >>>> #18, p8 - Exactly how is the sequence number used in the >>>> calculation of the pMSK for each CAP? Can these be re-used? (Across >>>> reboots?) Do they need to be random? That all needs stating I >>>> think. >>>> >>>> [Qin]: This was discussed on the list before. The results is: >>>> If we carry three CAP-Identifiers, we should also send three Sequence >>>> number TLVs >>>> with associated CAP-Identifiers. The Sequence number for each CAP MUST >>>> not be reused. >>> >>> >>> MJST NOT be re-used is fine but needs to be stated. >>> >>> Your response doesn't answer the question though. >> >> >> [Qin]: if there are multiple CAPs, the EA server can not send the same >> pMSK to all the CAPs. >> The pMSK is derived as follows. >> >> pMSK = KDF (K, S), where >> >> K = pRK and >> >> S = pMSK label | "\0" | Sequence number | length >> If the sequence number is set to the same value for each CAP, all the CAP >> will get the same pMSK. >> That's not secure. >> >> >>> *How* (exactly) is the sequence number used when calculating >>> the pMSK? Maybe that's specified in ERP, but it has to be >>> specified somewhere so you need more text or a reference. >> >> >> >> [Qin]: Yes, see above. >> >>>> #20, p8 - authentication tag - where is the input to the HMAC >>>> function specified? (Its not here anyway.) I think someone needs to >>>> say how this is calculated. That means both the plaintext (message) >>>> input (e.g. are any header bits in/excluded?) and the key input >>>> (which key?). It could be that this just needs a reference if its >>>> done the same as some other RFC. An example would be great to give. >>>> >>>> [Qin]: We should base on HMAC mechanims specified in RFC2104, >>> >>> >>> I think you want RFC 4868 which defines HMAC with SHA256. But >>> that doesn't define a 64 bit output I now notice so I think you >>> need to define that or drop it or find a place where it's defined. >>> The 128 and 256 bit output variants are defined in 4686. >> >> >> >> [Qin]: Good point, we need to add a reference to RFC4868 and RFC2104. >> As for 64 bit output, we need to find out or drop it. >> >>>> Use the integrity algorithm indicated in the Cryptosuite field to >>>> calculate authentication tag value. rIK will be used for calculation. >>>> The message used to calculate authentication tag should exclude >>>> authentication >>>> tag field and but not exclude header bits. >>> >>> >>> So you need to say that. >> >> >> [Qin]: Okay. >> >>>> >>>> #22, p8 - You need references for the HMAC functions. >>>> >>>> [Qin] It should be RFC2104. >>> >>> >>> Nope. See above. >>> >>>> >>>> #23, p8 - Should/are the choices for cryptosuites in some IANA >>>> registry? If not, why not? If so, where? >>>> >>>> [Qin] RFC5296 has already created registries for'Re-authentication >>>> Cryptosuites'. These crytosuites can be reused for ERP-AAK. >>> >>> >>> So use that then and say you're doing so. >> >> >> [Qin]: Okay. >>> >>> >>>> #36, p11 - Is it ok for "different sequence numbers" to mean "just >>>> increment" or not? Is it ok for sequence numbers to be re-used say >>>> after the peer reboots? I think you need to say. >>>> >>>> [Qin] See the above answer to #16, #18. >>> >>> >>> I looked. I still don't know the answer. >>> >>> S >>> >>>> >>>> >>>> Regards! >>>> -Qin >>>> ----- Original Message ----- >>>> From: "Stephen Farrell"<stephen.farrell@cs.tcd.ie> >>>> To:<hokey@ietf.org> >>>> Sent: Tuesday, November 22, 2011 2:39 AM >>>> Subject: [HOKEY] AD review of draft-ietf-hokey-erp-aak >>>> >>>> >>>>> >>>>> Hi all, >>>>> >>>>> Here's my review of this. There are a lot of comments, >>>>> but quite a few are very nitty or are things where I >>>>> probably just need to be told that I don't know enough >>>>> about ERP. (Which is true of course:-) >>>>> >>>>> Some are non trivial however, and there are a lot of nits, >>>>> so I've put this into the revised-ID-needed state. >>>>> >>>>> Probably best is to handle any easy ones via email and >>>>> then setup a skype chat for whatever's left. Let me >>>>> know... >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> >>>>> _______________________________________________ >>>>> HOKEY mailing list >>>>> HOKEY@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/hokey >>>>> >>>> >> > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www.ietf.org/mailman/listinfo/hokey -- Best regards, Zhen
- [HOKEY] AD review of draft-ietf-hokey-erp-aak Stephen Farrell
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Qin Wu
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Stephen Farrell
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Qin Wu
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Stephen Farrell
- [HOKEY] 答复: Re: AD review of draft-ietf-hokey-erp… zhou.sujing
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Qin Wu
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Zhen Cao
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Stephen Farrell
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Zhen Cao
- Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak Qin Wu