Subject: [Mipshop] Paris meeting

From: gabriel montenegro <[email-masked]>
Date: Fri, 1 Jul 2005 17:31:46 -0700 (PDT)

Folks,

I just submitted a request for a slot to meet in Paris. In our tentative list we had
identified enough items that I asked for a 2-hour slot. However, I want to ask for
commitments from draft authors.

Below, please find the list of next milestones we had come up with, along with the
status regarding the corresponding draft. Remember, deadline for initial (rev 00) drafts
is July 11. 

Please respond with your commitment to:

1. have a draft in place
2. present in Paris

HMIPv6 MN-MAP security 
	No draft. Hesham?

FMIPv6 MN-AR security: AAA-based Keys
	submitted: draft-vidya-mipshop-handover-keys-aaa-00.txt
        Anybody presenting? Narayanan Vidya?

FMIPv6 MN-AR security: SeND-based keys
	expired: draft-kempf-mobopts-handover-key-00
        Rajeev and James?

Common Information Elements for Use in Mobility Protocols
	No draft. MIHEP BoF overlap? 
	Is IEEE 802.21 an acceptable starting point?

FMIPv6 bis (Local Repair and Information Element Transport)
	No draft. Depends on above item. Rajeev and James?

CGA-OMIP & CBA
	Draft apparently in the making.
        Jari, Wassim and Christian? Any news?

-gabriel

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 05 Jul 2005 09:23:35 -0700

James Kempf wrote:

>Regarding the Infoelements draft, Rajeev and I have something but we have
>been waiting for comment from Vijay and Mike. I will be submitting prior to
>  
>

It's Ajay Rajkumar and Michael Williams from 802.21 that is..

>the July 11 deadline. It is as yet unclear if the MIHEP BOF will take place.
>
>  
>
In any case, we will submit the draft to MIPSHOP.

-Rajeev

>            jak
>
>----- Original Message ----- 
>From: "gabriel montenegro" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
>"Rajeev Koodli" <[email-masked]>; "James Kempf"
><[email-masked]>; "Greg Daley" <[email-masked]>;
><[email-masked]>; <[email-masked]>; "Jari Arkko"
><[email-masked]>; <[email-masked]>; <[email-masked]>; "Marco
>Liebsch" <[email-masked]>; <[email-masked]>
>Sent: Friday, July 01, 2005 5:31 PM
>Subject: Paris meeting
>
>
>  
>
>>Folks,
>>
>>I just submitted a request for a slot to meet in Paris. In our tentative
>>    
>>
>list we had
>  
>
>>identified enough items that I asked for a 2-hour slot. However, I want to
>>    
>>
>ask for
>  
>
>>Below, please find the list of next milestones we had come up with, along
>>    
>>
>with the
>  
>
>>status regarding the corresponding draft. Remember, deadline for initial
>>    
>>
>(rev 00) drafts
>  
>
>>is July 11.
>>

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 5 Jul 2005 15:40:23 -0700 (PDT)

Ok. And yes, please try to coordinate with the MIHEP folks (cc-ed).

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Wed, 6 Jul 2005 16:05:04 -0700

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.

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?

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 11 Jul 2005 12:37:20 +0200

Hi james,

 thanks for your comments,

 I answer here to your basic architectural comment.

> All and all, an interesting document . Comments below.

 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

-- 
julien.bournelle at int-evry.fr