Subject: Re: [mobile-ip] key exchange between MN and MAP in HMIPv6

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Feb 2003 17:29:32 +0100

According to RFC2409, IKE Phase 1 allows the following
   authentication methods: digital signature, authentication with
   public key encryption, or pre-shared key. Which authentication
   method is used to establish ISAKMP-SA in HMIPv6?
   
=> this should not be specified in a mobile-ip document but
IMHO you should avoid aggressive mode (too easy attacks) and
pre-shared key (which needs a pre-shared key bound to a transient
address in main mode). Digital signature or public keys are fine
but on digital signature with X.509 certificates is widely implemented.
Last detail, don't put an IP address in the [alternate] subjectname
of the MN's certificate.

Regards

[email-masked]

PS: you should support the "revised identity" proposal in the ipsec list
(the "you" is for everybody, it stands for the French "vous", not "tu").

---

From: "James Kempf" <[email-masked]>
Date: Mon, 3 Feb 2003 08:52:20 -0800

Hi Francis,

> Last detail, don't put an IP address in the [alternate] subjectname

Sorry, but could you explain in a bit more detail why an IP address shouldn't be
put in the alternate subjectname? What would the problem be with the home
address?

Also, wouldn't it be necessary to re-establish the SA on every movement, if it
is based on the local care of address, which it would need to be, because the
incoming packets would have that as the source address?

            jak

---

From: Francis Dupont <[email-masked]>
Date: Mon, 03 Feb 2003 18:33:02 +0100

In your previous mail you wrote:

   Hi Francis,

   > Last detail, don't put an IP address in the [alternate] subjectname
   
   Sorry, but could you explain in a bit more detail why an IP address
   shouldn't be put in the alternate subjectname? What would the problem
   be with the home address?
   
=> this is a side effect of the loose semantics of certificates in IKEv1
(something we'd like to see fixed in IKEv2 with Paul Hoffman's revised
identity proposal).
References are :
 draft-ietf-ipsec-pki-profile-XX.txt (IKEv1 & certificate mess)
 draft-ietf-ipsec-revised-identity-XX.txt (proposed fix for IKEv2)
 draft-dupont-ipsec-mipv6-XX.txt (IPsec vs. MIPv6)
The issue is simple: many implementations verify that the peer source address
(the address IKE runs over, in our case this is the care-of address) is
in the [alternate] subjectname of the certificate. This is a natural extension
of these two sanity rules:
 - when the IP address identity doesn't match the peer source address -> reject
 - when the identity doesn't match the certificate (i.e., is not in
   the subjectname or in an alternate subjectname) -> reject
There are many ways to solve this issue, the easiest is my recommendation.

   Also, wouldn't it be necessary to re-establish the SA on every
  movement, if it is based on the local care of address, which it would
  need to be, because the incoming packets would have that as the source
  address?
   
=> (According to old messages, the SA is the ISAKMP-SA.)  If the
implementation (some already do this) lookups the ISAKMP-SA with the
SPI then the peer source address doesn't need to be the same and it is
no more necessary to re-establish the ISAKMP-SA on every movement.

Thanks

PS: I proposed an address management for IKEv2, both in order to
fix some shortcomings in the current draft and to improve the support
for NAT traversal, multi-homing and mobility. Its name is
draft-dupont-ikev2-addrmgmt-00.txt and I need comments and support
in the ipsec mailing list...