Jimmy Zhang writes: I have a question regarding IKE part. 

In Draft 21, section 5.1:

    "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. IMO, it is very natural for
MN to use its H@ as the ID payload in IKEv1 phase 1. 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. 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, is that what we are going to do? I guess I miss something here.

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@.

--------------

Francis Dupont responds to Jimmy Zhang:

> "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...

--------------

Jimmy Zhang responds to Francis Dupont: 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 ?

--------------

--------------

--------------

--------------