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

["James Kempf" <Kempf at docomolabs-usa.com>]

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.

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




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