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

Hi james,

 thanks for your comments,

 I answer here to your basic architectural comment.

On Wed, Jul 06, 2005 at 04:05:04PM -0700, James Kempf wrote:
> All and all, an interesting document . Comments below.
> 
>             jak
> 
> ---------------------
> 
> Basic Architectural Comment:
> 
> I got the feeling while reading through this that the authors decided for
> some reason to keep the base protocol completely decoupled from any
> dependence upon network access authentication. If so, I wonder why? In
> essence, the basic architectural function this protocol is trying to
> accomplish is to derive and distribute another set of keys as part of the
> host to access network AAA association, and therefore it would seem to have
> a natural dependence on the access network authentication protocol. The
> result was kind of unsatisfying, as it left the protocol somewhat ungrounded
> and lacking a concrete connection with a straightforward path toward
> implementation and deployment, when, in fact, one of the stated reasons for
> doing an AAA-based protocol in the first place was to make implementation
> and deployment simpler by leveraging off of the existing AAA infrastructure.
> 
> 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?
> 
> 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
>             - 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
>             - 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).
> 
> 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.

 You raise an interesting issue here. Basically, we have 2 options to
 define a solution based on AAA:

 1/ Integrate the solution to network access authentication as you
 propose. This imply two things: first we'll need an interface between
 the authenticator (NAS) and AR and second we'll need to add a mechanism
 to know wether or not the MN wants some keying material for FMIPv6 and
 to add a way to derive and carry the keying material.
 This mechanism could be add either at the EAP layer (implying to modify
 some EAP methods such as it is done in
 draft-giaretta-mipv6-eap-authorization-02.txt) or at layers carrying EAP
 packets (EAP lower-layer + AAA). In the latter case, it implies some
 modifications to both protocols (EAP lower -layer e.g. PANA and the AAA
 protocol).

 2/ Define a decoupled solution as we currently propose. It is more or
 less what has been done for Mobile IPv4 (cf.
 draft-ietf-aaa-diameter-mobileip-20.txt). This solution can be used in
 more environments (even if http-based redirect authentication is used)
 but is maybe less efficient.

 At the moment, we have chosen the second option. However, I think that
 it is an interesting discussion to have. 

 Julien

> 
> 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.

> 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.
> 
> Section 3, paragraph 4 and 6: What is PRF here?
> 
> 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.
> 
> 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.
> 
> Section 4.1, v Flag - Is the MN sharing a key with itself here?
> 
> 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?
> 
> 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.
> 
> Section 5.1, paragraph 5: The last sentence is somewhat gratuitous and can
> be dropped.
> 
> Section 5.2, paragraph 1: Pick whether to include the Alt CoA or not. Why
> have two choices here?
> 
> 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?
> 
> 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.
> 
> Section 6.2, Replay Protection, last sentence: Shouldn't this be the HMK?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 
> 
> 
> 
> 

-- 
julien.bournelle at int-evry.fr

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