Re: [HOKEY] AD review of draft-ietf-hokey-erp-aak

[Qin Wu <[e-mail]>]

Hi,
----- Original Message ----- 
From: "Stephen Farrell" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>; "Glen Zorn" <[e-mail]>; "Cao,Zhen" <[e-mail]>
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"<[e-mail]>
>> To:<[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hokey
>>>
>>