[Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa-00.txt

[Narayanan Vidya-CVN065 <vidya at motorola.com>]

James,
Thanks for the detailed review comments. First, let me try to respond to your comment on the architecture below. Please see inline for other comments. 

Regarding the architecture, you guessed right about the motivation for decoupling this protocol from network access authentication. It was to allow this protocol to work over heterogeneous L2 protocols. The HMK derivation itself, as you say, can be tied to network access and derived using extensions to EAP (which was the point of Appendix A). However, tying the derivation of the HK itself every time the MN roams to a new AR to network access seems a little restrictive to me. The thought is that the protocol should be usable when the MN hands off among any of these technologies - 802.11, 802.16, GPRS, and even say proprietary L2 protocols. 

Now, you mentioned tying this to PANA. The point I struggle with is this - do we believe that there is reason for PANA support to be ubiquitous? When there is a lower layer protocol that carries EAP, why would there be a need to support PANA in the network? I see PANA being used when the lower layer protocol is unable to carry EAP. Is this not true? Tying handover key derivation to PANA implies every AR that supports FMIP is required to support PANA - is this necessarily true? 

The actual protocol for deriving the HK itself (once the HMK is available) is very simple and is a single roundtrip protocol. ARs that support FMIP will need to support this protocol. By tying this to PANA, are we not creating dependency on a protocol that is not really required to support secure FMIP? Please correct me if I'm wrong, but to me, that seems to complicate the protocol. Also, the thought was this protocol could be used for any MN-AR communication that must be secured (such as CxTP, for instance and also IPv4 fast handoffs), although the draft currently is only detailed with FMIP in mind. 

Prior to writing the draft, we (the authors) had discussions on the protocol's dependency on network access authentication and for simplicity, decided to decouple the actual HK derivation from it. I do, however, agree that the HMK derivation based on EAP should be integrated into the main document - it was left as an Appendix mainly to allow someone to use pre-shared HMKs if need be - but, it would make sense for that to be part of the main spec. 

Thoughts on this? 

> 
> For example, since the protocol description in Section 3 does 
> not mention an encryption security association between the 
> AAA server and the MN, the nonce sent by the AAA server to 
> the MN seems to be sent in the clear, which gives an 
> eavesdropper one piece of information that it could use in 
> some fashion to compromise. If you read further (in 
> particular into the Appendix) you see that, in fact, EAP can 
> be used for this transaction, and so one of the EAP methods 
> that support secure MN-AAA server communication could be used 
> to maintain confidentiality on this transaction (though the 
> document provides no details on what the EAP extension is). 
> But if EAP isn't used, then what?
> 

I am trying to understand the need for the nonce to be encrypted - there is nothing that an eavesdropper can do with the nonce without knowing the HMK - and the HMK is never sent out. Also, the HK, when sent to the AR is encrypted - so, what does encrypting the nonce really achieve? The nonces are usually sent in the clear in other protocols as well (for e.g. Mobile IP when used with MIP-AAA to generate dynamic keys, etc.) - so, that seemed okay. Are we missing something? 


> My (somewhat radical) suggestion to the authors would be to 
> redesign the protocol to couple it tightly with EAP-based 
> network access authentication protocol. This would mean:
> 
>             - Incorporating the derivation of the HMK from 
> the EAP key hiearchy which is now in Appendix A into the 
> protocol directly


Agreed. This makes sense - we can revise the draft to include this. 



>             - Using EAP within the network access 
> authentication transaction to exchange parameters to derive 
> the HMK, by defining an EAP extension for one of the 
> extensible EAP methods. This will ensure that the transaction 
> between the MN and AAA server is properly confidential, 
> protecting MN anonymity and the parameters of the key derivation


Protecting MN anonymity makes sense and as we detail the contents of Appendix A and integrate it with the main document, this should be ironed out. I am still, however, wondering about the need to encrypt the nonce. 


>             - Instead of defining a separate protocol for 
> preauthentication and reauthentication upon handover (Section 
> 4), couple the derivation of new HKs via preauthentication or 
> reauthentication on handover to PANA pre- and 
> reauthentication. This will allow the protocol to leverage 
> off of the PANA work, so that the deep thinking about how to 
> get pre- and reauthentication on handover right only needs to 
> be done once, for PANA (where it needs to be done anyway).
> 

As I mentioned earlier, this is the part that I am not sure about - PANA defines pre- and reauth for the link layer and I see this being used when the lower layer doesn't already do EAP - does it really make sense to extend it to be used for L3 handovers as well? 


> Incidently, if one of the reasons why this protocol was 
> decoupled from network access authentication was to allow 
> IEEE 802.1x or other Layer 2 protocols to be used, then this 
> needs some rethinking. EAP is used in 802.1x anyway so it 
> could still be used for the initial HMK derivation. And the 
> 802.1x reauthentication isn't going to be useful for handover 
> key reauthentication, because it only deals with APs, which 
> are layer 2 devices, whereas this protocol must deal with 
> ARs, which are layer 3 devices, so PANA is probably the right vehicle.
> 
> Detailed Editorial and Technical Comments:
> 
> Section 3, paragraph 2: This paragraph seems to be specifying 
> use of the HMK for calculating a MAC. It might be a good idea 
> to keep the HMK private, and use a derived key for this 
> purpose, to avoid exposing material calculated with the HMK 
> to attackers.
> 


Yes, this makes sense. We will correct this in v01. 


> Section 3, paragraph 2: As mentioned above, the nounce looks 
> to be sent in the clear. Might be better from a 
> confidentiality standpoint to encrypt. Similarly for the NAI.
> 


Same question as before for the nonce. For the NAI, would it not be sufficient to provide a means of deriving an identity (or even multiple identities) to use as part of HMK derivation, so that MN privacy is protected? Encryption of these parameters should be simple enough - so, if you think that it will be better to do so, that can certainly be done. 


> Section 3, paragraph 4 and 6: What is PRF here?


That was a miss on our part - should have stated HMAC-SHA1 as the pseudo-random function to be used. Will add this. 

> 
> Section 3.1, paragraph 2: Note that if the nounce is 
> encrypted, it need only be exchanged once, during the initial 
> HMK derivation. After that, fresh nounces can be derived by 
> forward hashing from the original. Alternatively, the AAA 
> server and MN can generate a hash chain and move backward (at 
> the expense of having to store the hashes). This eliminates 
> the need to send a hash out over the air each time a 
> reauthentication is performed. The AAA server can push the 
> appropriate nounce to the AR.


Interesting thought on forward hashing. Regarding pushing the nonce to the AR - the AR does not have the HMK and hence, cannot derive the HK; so, the AAA server really needs to give the AR the HK - am I misunderstanding you here? 

> 
> Section 3.1: It is unclear to me how the MN manages keys 
> generated by preauthentication. Essentially, the MN is 
> setting up soft state in the network that it must manage. 
> Yet, the specification only briefly mentions key lifetimes, 
> and does not specify any suggested defaults, nor how the AR 
> knows what the lifetime of the key should be.
> 


The AAA server does send a recommended lifetime to the AR (and the AR forwards that to the MN). However, the AAA server does not maintain any state about the lifetime itself and hence, it is up to the MN and AR to enforce the lifetime. Perhaps, the text can add more clarity on this. 


> Section 4.1, v Flag - Is the MN sharing a key with itself here?


Oops. Good catch - it is an error. The "MN" at the end of that sentence should be "AR". 

> 
> Section 4.1, Seq. number - What if the message is 
> retransmitted on a new AR? Should the MN use the same Seq. 
> number or new?
> 

For a given message ID, the sequence number is never repeated. Retransmissions are identified by the use of the same message ID (sequence number must be incremented though). A HKReq message is always sent to the AR with which the MN desires to share a HK. It may be sent via an old AR while the MN is attached to that oAR (note that the IP destination of that packet will still be the target AR with which it expects to share the HK). So, if the MN attaches to a new AR and does a retransmission, it should still use the same message ID - for a HKReq sent to ARn, a retransmission to the same ARn should always use the same message ID. Did I answer your question here? 


> Section 5.1: This section seemed to be saying that the MN 
> needs a key on the new AR when it hands over before it can do 
> the FMIP signaling, is that correct? If so, I'd like to know 
> why? The primary security issue in FMIP is not security with 
> the new AR, but security with the old AR. The old AR is being 
> asked by the FBU to change routing for the old CoA (i.e. set 
> up a tunnel from the old CoA to the new), and for that 
> purpose, it must have some indication that the entity sending 
> the FBU is authorized to claim the CoA. The new AR gets the 
> FNA which is typically piggybacked on the FBU, but that needs 
> to be secured using IP address configuration security, and it 
> can even be eliminated entirely if the MN used oDAD since its 
> only purpose is to allow the AR to confirm whether the 
> address is not a duplicate. For example, if the new CoA is 
> autoconfigured, then RFC 3971 and 3972 can be used to secure 
> the address. If the address in DHCP configured, other 
> mechanisms are to be used. Or are the authors intending here 
> to define a new way of performing IP address configuration security?
> 
> With this comment in mind, I fail to see the urgency of 
> having to perform the key exchange with surrounding routers 
> immediately coupled to the handover signaling. The issue 
> becomes ensuring the MN has a key on the router it currently 
> is, so that when it hands over it can properly change 
> routing. For that purpose, the MN may want to perform 
> preauthentication in order to avoid having to establish the 
> key once it moves to the new router, but there is no need to 
> couple preauthentication tightly to the handover.
> 


No, it is not mandated to derive a key with a new AR before the MN hands over. We used a "SHOULD" there, since deriving a key prior to handoff will be good practice for an MN that moves quickly between ARs on different subnets. The HK is only used with the FBU (so, you are right - it is needed only with the oAR, so the MN could potentially derive the key after it handsoff). This also becomes useful when this protocol is used to support MN-AR security for other protocols that may need the key to be present sooner for any communication (not within the scope of description in v00). 


> Section 5.1, paragraph 5: The last sentence is somewhat 
> gratuitous and can be dropped.
> 

Ok. 

> Section 5.2, paragraph 1: Pick whether to include the Alt CoA 
> or not. Why have two choices here?
> 

Most of the time, the source address of the packet should be sufficient in determining the CoA of the MN. However, the Alt CoA was included as a means for the MN to convey its CoA, if the source IP address is subject to change enroute - in IPv4, I can think of NATs causing this problem - but then, Alt CoA won't solve that anyway. So, maybe this is not required? 

The CoA itself is required to be bound to the HK mainly so that when the AR receives the FBU, it is able to locate the correct key to use for that MN. Having a provision for an SPI in the FBU will make this very clean and remove the need for this. In fact, the protocol itself can be simplified further if the FBU had a means of carrying an SPI. This is something we would like to discuss with you and Rajeev at Paris. I will send out a separate email on this topic, so that this email doesn't get out of control. 


> Section 5.2, paragraph 2: If the MN retransmits on the new 
> router, does it use the same seq number? If so, how does the 
> router/AAA server distinguish whether this is a replay attack or not?
> 

A HKReq that was transmitted earlier to the AR (via an oAR) would have had the same message ID, if the MN is trying to retransmit a message. If an AR receives a HKReq with the same message ID and same sequence number, the packet is dropped. The sequence number must always start at 1 for a new message ID and then be incremented for every retransmission. A new HKReq (that is not a retransmission) must have a new message ID. If the text in the document is not clear on this, we can try to clarify it better. 


> Section 5.3: It seems here that the AAA-Local must perform 
> the key decapsulation and distribution to ARs in a roaming 
> scenario, because it is not realistic to expect the AAA-Home 
> to have security associations with all the ARs in a roaming 
> partner's access network. Perhaps this could be made more clear.
> 

Yes, in a roaming case, this will be true. We can add some text to make that clear. 


> Section 6.2, Replay Protection, last sentence: Shouldn't this 
> be the HMK?

No, it is really the HK. The sequence number must be unique for every retransmission (i.e., when the message ID is the same). Unless the MN is involved in a lot of retransmissions, a new HKReq must typically result in a new HK. Even when the MN is trying to verify the HKReq, it must be using a different message ID. Does that make sense? 

> 
> Section 6.2, Denial of Service, second paragraph: I am not a 
> big fan of puzzles, because their effectiveness depends on 
> the attacker co-operating and actually trying to solve the 
> puzzle. A dedicated attacker will simply pump packets out at 
> the victim, and ignore a puzzle response. This is especially 
> an issue with DDoS, where the attacking nodes are only 
> loosely co-ordinated and the effectivenes depends on volume.
> 


You are right. DoS attacks are really impossible to eliminate completely - the question is whether this approach may mitigate it. 


> Section 6.2, Fragmentation: This statement is highly 
> dependent on the radio layer frame size. For a small enough 
> frame size, fragementation could still be an issue.

It does not seem like this protocol may need to solve this, right? Perhaps, this section can be removed? 

> 
> Appendix D: Some of these suggestions involve having the ARs 
> perform key distribution. Since the ARs are not authenticated 
> directly to the MN, this may compromise security.
> 

Yes, this is true. This is among the reasons why we didn't consider any of these approaches for the protocol. We may have missed stating that. We included this appendix to essentially explain why some of the other seemingly simple approaches were not so desirable. 

> Appendix E: It is heartening to see the use of formal methods 
> for the security proof, but in the absence of a deep study of 
> the specific syntax of the method used, I wonder how useful 
> this section is to a reader. Also, there seem to have been 
> some simplifications of the protocol done for the analysis. 
> How realistic is the result as a consequence?
> 

I agree with you here. It was hard to do a comprehensive analysis at this early stage of the document. So, a minimal analysis was included. Hannes, would you like to add something here? 

Thanks,
Vidya

_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop