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

[Julien Bournelle <julien.bournelle at int-evry.fr>]

Hi james,

On Tue, Jul 19, 2005 at 03:15:29PM -0700, James Kempf wrote:
> Vidya,
> 
> > 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?
> >
> 
> We've just been going through a similar discussion on the MIP6 list about
> SEND and HA list security.
> 
> I think the meta-problem you're having is the following:
> 
>     "If I make my protocol dependent on X, Y, and Z, then people who don't
> deploy X, Y, and Z won't use my protocol and so it won't get as widely
> deployed as if I did not make it dependent on X, Y, and Z."
> 
> I believe this is a misconception. I believe that it is more important to
> have a well designed wireless Internet protocol architecture, with
> functionality cleanly partitioned between various protocols. Because if the
> protocol architecture is clean and well designed, then people will have a
> stronger incentive to deploy it than if the architecture is messy with lots
> of duplicated functionality. If your protocol is excessively complex because
> is incorporates a lot of stuff that other protocols do more elegantly,
> nobody is going to deploy it even if they don't deploy X, Y, and Z, and they
> certainly won't deploy it if they do deploy X, Y, and Z because they already
> have the bits and pieces that your protocol incorporates. They will write
> their own extensions that do what's needed without incorporating the
> duplicated bits.
> 
> So I think it is more in the interests of getting your protocol deployed to
> actually make it depend on well designed base protocols like EAP, to keep
> the wireless Internet architecture protocol suite well designed.
> 
> Regarding EAP specifically, EAP runs over multiple link layers. It now is
> available on 802.11, 802.16 and GPRS. I don't know about proprietary L2 but
> I'd say that if the L2 is proprietary, then interoperability probably isn't
> important since there is only one company involved, so an IETF standard
> isn't needed (and if the vendor owning the protocol really is interested in
> interoperability, they will use EAP because that is the IETF standard). I
> think it is safe to say that, going forward, EAP will be available on future
> L2 protocols except for maybe 802.15-style protocols that are more of an ad
> hoc nature.

 We could certainly define a way to provide a key both for MN and AR
 during the network authentication phase.  EAP provides a way to create
 key for application (AMSK) (Appendix A of our draft). 
 Thus we need to define a key specific for
 FMIPv6 and a way for the EAP authenticator to push the keying material
 to appropriate AR (not defined in the current draft).

 The problem that I can see is after IP handover, how do the MN get a
 new key ? If we continue to rely on EAP, it will imply a
 reauthentication from scratch. 

 Any comments ?

 Julien
> 
> Regarding PANA, again, I don't know that it will be ubiquitous, but I don't
> think it matters. Even if PANA is not used for network access
> authentication, there's no reason why people can't deploy a subset for
> handover key derivation.
> 
> Does this make sense?
> 
> > 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.
> >
> 
> Well, some protocol is required to do this, right? So whether FMIP depends
> on some new protocol or PANA really doesn't matter. Since PANA is well along
> in the standardization process, why not use it?
> 
> > 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?
> >
> 
> As I mentioned, the attraction of this protocol is that it can leverage off
> the AAA infrastructure for network access authentication. So by not doing
> that, I think you are undercutting your strongest argument. I also don't see
> this particular key derivation as being contrary to EAP's stated goal of
> only supporting network access authentication (this is an argument that
> people have made against, for example, using EAP to configure MIP6 HA
> addresses).
> 
> > >
> > > 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?
> >
> 
> See below on the hashing.
> 
> >
> > > 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.
> >
> >
> 
> OK.
> 
> >
> > >             - 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.
> >
> 
> OK.
> 
> >
> > >             - 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?
> >
> 
> I think PANA uses EAP too, right? It is basically a container for carrying
> EAP, like EAPoL or IKEv2 is.
> 
> >
> > > 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.
> >
> >
> 
> OK.
> 
> > > 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.
> >
> 
> Protecting the NAI is primarily a privacy/anonymity problem.
> 
> >
> > > 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.
> >
> 
> OK.
> 
> > >
> > > 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?
> >
> 
> Sorry, I meant the AAA server.
> 
> > >
> > > 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.
> >
> 
> Yes. But why should the MN trust the AR on the lifetime? There is no
> authenticated relationship between the AR and MN.
> 
> >
> > > 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".
> >
> 
> OK.
> 
> > >
> > > 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?
> >
> 
> Yes but I think you need to make it clearer in the draft how retransmissions
> work.
> 
> >
> > > 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).
> >
> 
> Again, I think the draft could be clearer on this. It needs to emphasize
> that preauthentication is primarily an optimization.
> 
> >
> > > 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?
> >
> 
> I can't see any place in MIP6 that it would be 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.
> >
> 
> OK.
> 
> >
> > > 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.
> >
> 
> Yes, as above, it needs to be clarified. I did not get this from reading the
> draft.
> 
> >
> > > 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.
> >
> >
> 
> OK.
> 
> > > 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?
> >
> 
> OK, I understand now. Again, I think the draft needs to be clearer about how
> the sequence number is used in retransmission.
> 
> > >
> > > 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.
> >
> >
> 
> Puzzles are fashionable, so I can understand why you might want to keep them
> in. But, again, I don't see that they will really provide any help against a
> dedidated attacker (and, in fact, against the most common type of DoS attack
> on the Internet today).
> 
> 
> > > 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?
> >
> 
> Yes.
> 
> > >
> > > 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.
> >
> 
> OK. I think this could be dropped from the draft, since it does not
> contribute to explaining the protocol.
> 
>             jak
> 
> 
> 

-- 
julien.bournelle at int-evry.fr

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