Subject: RE: [mobile-ip] IKE question

From: "Jimmy Zhang" <[email-masked]>
Date: Mon, 19 May 2003 15:37:15 -0700

Hi, Francis,

Thanks for your email.

I didn't realize that "many implementations check if the peer address
and the address ID matches" If this is the case, then I agree that we
have to use ID other than ID_IPV6_ADDR. 

Anyway, I didn't see the reason they should check this in Aggressive
mode and when using preshared key. (we are not talking about subject
name in a certificate). In aggressive mode, all IKE messages of Phase I
are clear, not-encrypted, nor authenticated. A hacker will always do the
same damage no matter you are using a IPV6_ADDR ID or USER_FQDN ID. We
may hide the home address, but we have to release another ID instead,
can we tell which ID is more important ?

Thanks,
Jimmy

> -----Original Message-----
> From: [email-masked] [mailto:Francis.Dupont@enst-
> bretagne.fr]
> Sent: Monday, May 19, 2003 2:09 PM
> To: [email-masked]
> Cc: 'Mobile-Ip'
> Subject: Re: [mobile-ip] IKE question
> 
>  In your previous mail you wrote:
> 
>        "When IKE version 1 is used with preshared secret
authentication
>    between the mobile node and the home agent, aggressive mode MUST be
>    used. Similarly, the ID_IPV6_ADDR Identity Payload MUST NOT be used
in
>    IKEv1 phase 1. "
> 
>    I couldn't understand the second sentence.
> 
> => the identity is used to look up the right preshared secret, IKE
runs
> over the care-of address and an address identity is supposed to match
> the peer address hence:
>  - main mode can't be used because it gives no choice for the key of
>    preshared secret look up (it must be the address).
>  - address IDs can't be used.
> 
>    IMO, it is very natural for
>    MN to use its H@ as the ID payload in IKEv1 phase 1.
> 
> => it is natural but IKE runs over the care-of address, not the home
> address.
> Note that a proposed but not available solution is to add a new "home
> address"
> identity type (and subject alternative name type in PKIX).
> 
>    It uses CO@ to negotiate with its Home Agent, it also uses its H@
>    as the ID so that the HA can get the preshared key.
> 
> => many implementations check the peer address (the address IKE runs
over)
> and the address ID (and an address subject alternate name with
> signature based authentication) matches. This is the defense against
> some attacks because IKE doesn't protect the peer addresses at all
> (a known security flaw which should be fixed in IKEv2). Of course
> it doesn't work with NAT traversal (which can be considered
intrinsicly
> insecure) or with an initiator using a dynamic address (a road
warrior)
> but fortunately other ID types can (should in these cases) be used.
> 
>    If ID_IPV6_ADDR ID MUST NOT be used, then the HA must think of a
name
>    (like in FQDN format) for each of its mobile nodes.
> 
> => yes, each MN should use a name (FQDN or user_FQDN aka NAI) or
> a keyID. What is the issue?
> 
>    Similarly, in draft mipv6haipsec pre 5, section 4.4
> 
>        " Note also that care needs to be taken with phase 1 identity
>    selection. Where the ID_IPV6_ADDR Identity Payloads is used,
> unambiguous
>    mapping of identities to keys is not possible. (The next version of
IKE
>    may not have these limitations.)"
> 
>    I couldn't see why it is not possible for unambiguous maping of
>    identities to keys, given the ID payload is the HO@.
> 
> => the problem is your assumption (the home address can be used in
> the ID) is false...
> 
> Regards
> 
> [email-masked]
> 
> PS: note that in IKEv2 the ID should be a simple policy pointer and
> the peer address should be protected, so the issue is very
different...
> And of course IKEv2 will support "legacy authentication" and should be
> very close to current real world IKE deployment in mobile VPNs, IMHO
> enough to be a dangerous competitor to mobile IPv6 without routing
> optimization.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 May 2003 09:12:09 +0200

=> I am afraid that we don't need argument to convince IPsec people that
aggressive mode is not very secure and main mode is too heavy (:-)...

Regards