Subject: [mobile-ip] draft-montenegro-mobileip-mipv6-seceval-00.txt

From: "Le Franck (NRC/Dallas)" <[email-masked]>
Date: Tue, 27 Nov 2001 13:40:47 -0600

Hello,

Unfortunately we did not have the time to work on the assessment of
proposals yet, and we were thinking to submit a new version of the
[DHMIPv6] to improve some aspects of the mechanism; but we noticed that
some concerns (e.g. the heavy computation required by the Diffie Hellman
exchanges), that we wanted to address in the new version, have already
been raised in the "MIPv6 Security: Assessment of proposals" internet
draft.

Therefore please find below some comments about these issues: 

1)"1.3:P: DHMIPv6 does not rely on IKE but it relies optionally on AAA
as a key distribution infrastructure."

[DHMIPv6] describes a way to establish a security association between
the MN and the CN without requiring the presence of any AAA
infrastructure nor PKI.

2)"2.5:P: The cryptographic part of DHMIPv6 is exclusively based on
Diffie-Hellman algorithm.  No other algorithms that could be used to
securely generate the key are presented."

That is correct: DHMIPv6 suggests a way to establish the security
association based on the Diffie Hellman mechanism but if another
protocol/mechanism is preferred, DHMIPv6 does not prevent it.
We just need to make sure in the definition of the message format that
if the MN and the CN wish to use another mechanism, they can indicate
it.

3) "2.9:I: The number of message exchanges is somewhat large for setting
up a security association."
   
The internet draft [DHMIPv6] may not be clear but the mechanism only
requires 4 messages for the first authenticated binding update:
- one message from the MN to the CN to request to set up a SA
- one message from the CN to the MN (via the HA)
- the authenticated BU from the MN to the CN
- the authenticated binding acknowledgement from the CN to the MN

and then, for subsequent BU, the MN which has the session key can
directly authenticate the binding update.

4) "2.11:I: The method makes heavy use of DH exchanges."

That was one of the points we wanted to improve: We agree that the
current version may be vunerable to denial of service attacks, but there
are ways to solve it. E.g. the CN can use Cookie to prevent that. When
receiving the first message from the MN, the CN would respond with a
cookie the MN should re-send in the third message.
The CN should not reserve any memory state nor make any computation
before making sure the cookie is valid. The cookie could e.g. be
computed the same way as suggested in JFK
(http://search.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-00.txt).
This would solve this issue.

Thank you,

Franck

---

From: Alexandru Petrescu <[email-masked]>
Date: 29 Nov 2001 16:53:05 +0100

Hi Frank and thanks for the message,

"Le Franck (NRC/Dallas)" <[email-masked]> writes:
> [DHMIPv6] to improve some aspects of the mechanism;

If you have a new version of the draft, please don't hesitate to send
it for evaluation.  Thank you.

> the MN and the CN without requiring the presence of any AAA

The evaluation contains the word "optionally" to reflect what's in the
DHMIPv6 draft.  In my understanding, if DHMIPv6 relies on AAA (section
3 "A Diffie Hellman based key distribution relying on AAA servers")
then it provides a "stronger" form of authentication.

> if the MN and the CN wish to use another mechanism, they can indicate

Yes, this is correct.  I think this another mechanism should be
described in the draft.  Or at least leave place for it.

> - the authenticated binding acknowledgement from the CN to the MN

This is actually 5 messages (4 plus the one to HA).  The DH that
relies on AAA (section 3) has 6 messages.  Here's how others perform:

PBK:     3
SAP:     3
BUSEC:   5
BAKE:    4
SUCV:    3
CAM-DH:  1 to 2
BU3WAY:  3 to 5

There are small variations wheter you take Binding Acknowledgments
into account or not.

Alex

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Nov 2001 08:24:25 -0800 (PST)

Alexandru Petrescu writes:
 > [about message counts for secure binding updates]
 > 
 > BUSEC:   5

   ??? I don't understand how you're counting this. It's
   always 3 messages to update a CN.

	    Mike

---

From: Alexandru Petrescu <[email-masked]>
Date: 29 Nov 2001 17:53:11 +0100

>    always 3 messages to update a CN.

As I said, depending if you count the Binding Acknowldegment or not
your mileage may vary.  Also, as with DHMIPv6, I counted the CN to MN
via HA message as 2 messages (hop limits decremented).

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Nov 2001 18:42:26 +0100 (CET)

> via HA message as 2 messages (hop limits decremented).

That explains the numbers - but it is a really odd definition of
"number of messages".
E.g. for BU3WAY between two MNs (the CN is also mobile) you need to
multiple the 3 messages (4 if BAck) with 3 since they all travel
	MN1->HA1->HA2->MN2
resulting in 9 (12 if BAck) of your number of messages.

But why are those hops different that a router forwarding the packets?
Answer for BU3WAY is that they aren't - the HAs are just forwarding packets
in and out of IPsec tunnels.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Nov 2001 09:44:25 -0800 (PST)

> via HA message as 2 messages (hop limits decremented).

At the very least, your table was inconsistant
since many of the others had ranges.  Secondly,
it's not very accurate to call a trip through the
home agent a separate message; it's different,
and should be accounted for separately. 

I think such a table is actually useful for 
discussion, but it should be more comprehensive
and use consistant language. Let's say "ha" is
a trip through the home agent. Thus
For example

[BUSEC]

First BU:    3+ha
With ACK:    4+ha	
Next BU:     3+ha
With ACK:    4+ha

[PBK]

First BU:    3+ha
With ACK:    4+ha (? I don't think they outlined ACK's...)
Next BU:     1
With ACK:    2 (?)

etc.

		Mike

---

From: Alexandru Petrescu <[email-masked]>
Date: 29 Nov 2001 19:09:48 +0100

> That explains the numbers - but it is a really odd definition of

Some proposals go CN-HA-MN while others go CN-MN so it looks that
those that go CN-MN are somehow "faster".  Quantified how?  I was
thinking "number of messages" would be a good start.

> resulting in 9 (12 if BAck) of your number of messages.

Aha, this too should be taken into account when counting the messages.
I think Michael's table is a good start.

> But why are those hops different that a router forwarding the
> packets?  Answer for BU3WAY is that they aren't - the HAs are just
> forwarding packets in and out of IPsec tunnels.

I gave a lot of thought to this since our last Router-HomeAgent
discussion.  It's such an enormous design space.

Alex