Subject: [Mip6] more confusion

From: Frank Quick <[email-masked]>
Date: Mon, 06 Oct 2003 10:03:34 -0700

Sorry for being a pest, but I have another issue with v24 of the I-D.  If 
it's too late to change the I-D, some other means of clarification should 
be found.

Section 11.3.2, page 115 says:

    o  In addition, for all security associations bound to the mobile
       node's home address established by IKE, the mobile node MUST
       include an ISAKMP Identification Payload [8] in the IKE exchange,
       giving the mobile node's home address as the initiator of the
       Security Association [7].

 From the email threads on this subject that I have seen, the mobile should 
not do this.  Section 5.1, page 21 says:

    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.

It's hard to see what identity type other than ID_IPV6_ADDR might be used 
to comply with 11.3.2.  I think the spirit of the email threads is that 
mobile must provide an Identification Payload that maps to the home address 
within the home agent, but it can't be the home address itself.

If this holds, then Section 11.3.2 should be changed to reflect it.

Further, given the spirit of the email threads, I would think Section 5.1 
should be modified to make it clear that this prohibition is not restricted 
to preshared secret authentication.

I believe that use of any ID type that includes one or more IP addresses or 
prefixes should similarly be discouraged.

-----

The reasoning behind this, if I understand it correctly, is:  IKE phase I 
doesn't protect the Source Address.  This is believed to be a security flaw 
that may be fixed in IKEv2.  Meanwhile, implementers have installed a 
poor-man's authentication by checking the Identification payload against 
the Source Address, and rejecting messages where they do not match.  Thus, 
while it would seem that the certificate ID should match the Identification 
payload but the Source Address should be the care-of address, in practice 
this will fail.

Can anyone point out email threads and/or an internet-drafts that discuss 
this issue?

Frank Quick
office   +1-858-658-3608 fax +1-858-651-1940
portable +1-619-890-5749
paging   [email-masked]
RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 06 Oct 2003 10:23:49 -0700

I am not sure you have read the companion draft

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt

I think sections 4.4 and 6.17 of this draft should answer your questions.

Vijay

> Sorry for being a pest, but I have another issue with v24 of the I-D.  
> If it's too late to change the I-D, some other means of clarification 
> should be found.
>
> From the email threads on this subject that I have seen, the mobile 
> should not do this.  Section 5.1, page 21 says:
>
> It's hard to see what identity type other than ID_IPV6_ADDR might be 
> used to comply with 11.3.2.  I think the spirit of the email threads 
> is that mobile must provide an Identification Payload that maps to the 
> home address within the home agent, but it can't be the home address 
> itself.
>
> Further, given the spirit of the email threads, I would think Section 
> 5.1 should be modified to make it clear that this prohibition is not 
> restricted to preshared secret authentication.
>
> I believe that use of any ID type that includes one or more IP 
> addresses or prefixes should similarly be discouraged.
>
> -----
>
> The reasoning behind this, if I understand it correctly, is:  IKE 
> phase I doesn't protect the Source Address.  This is believed to be a 
> security flaw that may be fixed in IKEv2.  Meanwhile, implementers 
> have installed a poor-man's authentication by checking the 
> Identification payload against the Source Address, and rejecting 
> messages where they do not match.  Thus, while it would seem that the 
> certificate ID should match the Identification payload but the Source 
> Address should be the care-of address, in practice this will fail.
>
> Can anyone point out email threads and/or an internet-drafts that 
> discuss this issue?
>
>
>
> Frank Quick

---

From: Frank Quick <[email-masked]>
Date: Mon, 06 Oct 2003 10:59:28 -0700

>I think sections 4.4 and 6.17 of this draft should answer your questions.

Thanks, I was aware if the other draft but I do appreciate the specific 
pointers.

4.4 says that the problem is that "unambiguous mapping of identities to 
keys is not possible" if the Identification payload is the ID_IPV6_ADDR 
type.  This is a slightly different slant, but it seems the bottom line is 
the same: having two different addresses will confuse the implementations.

The apparent conflict in the MIPv6 draft remains... unless I interpret all 
of this to mean the prohibition of the use of ID_IPV6_ADDR indeed applies 
*only* to the case of preshared secrets.  The wording "security 
associations ... established by IKE" could mean that the paragraph of 
11.3.2 of the MIPv6 draft applies only to dynamic keying.  Is that the 
intent?  If so, I'll withdraw my comments.

>>mobile must provide an Identification Payload that maps to the home 
>>address within the home agent, but it can't be the home address itself.
>>
>>should be modified to make it clear that this prohibition is not 
>>I believe that use of any ID type that includes one or more IP addresses 
>>or prefixes should similarly be discouraged.
>>
>>-----
>>
>>doesn't protect the Source Address.  This is believed to be a security 
>>flaw that may be fixed in IKEv2.  Meanwhile, implementers have installed 
>>a poor-man's authentication by checking the Identification payload 
>>against the Source Address, and rejecting messages where they do not 
>>match.  Thus, while it would seem that the certificate ID should match 
>>the Identification payload but the Source Address should be the care-of 
>>address, in practice this will fail.
>>

Frank Quick

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 06 Oct 2003 11:31:26 -0700

the main goal is to associate whatever security association created with the
home address of the mobile node and not the CoA. the CoA changes and you
have to re-key everytime the mobile node moves.

in case of preshared secrets, the source address in phase 1 is used to look
up the secret. the source address in phase 1 is CoA, therefore aggresive 
mode
should be used.

there is a more detailed response from Francis Dupont to a similar question
at http://www.piuha.net/~jarkko/publications/mipv6/issues/issue305.txt

Frank Quick wrote:

> Thanks, I was aware if the other draft but I do appreciate the 
> specific pointers.
>
> 4.4 says that the problem is that "unambiguous mapping of identities 
> to keys is not possible" if the Identification payload is the 
> ID_IPV6_ADDR type.  This is a slightly different slant, but it seems 
> the bottom line is the same: having two different addresses will 
> confuse the implementations.
>
> The apparent conflict in the MIPv6 draft remains... unless I interpret 
> all of this to mean the prohibition of the use of ID_IPV6_ADDR indeed 
> applies *only* to the case of preshared secrets.  The wording 
> "security associations ... established by IKE" could mean that the 
> paragraph of 11.3.2 of the MIPv6 draft applies only to dynamic 
> keying.  Is that the intent?  If so, I'll withdraw my comments.

yup.

Vijay

---

From: Frank Quick <[email-masked]>
Date: Mon, 06 Oct 2003 12:06:54 -0700

Thanks again.  I was aware of Dupont's answer cited below.  However, 
Dupont's answer adds to the confusion:

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

This was the source of my thinking that the use of ID_IPV6_ADDR was 
prohibited in all cases including dynamic key agreement.  However, the 
question in the email thread does seem to be related to preshared secrets, 
and perhaps the reply is in that context.

Still looking for a definitive response:  Can ID_IPV6_ADDR be used (and set 
to the home address) in phase I if dynamic key agreement is used (no 
preshared secret)?

At 11:31 AM 10/6/2003 -0700, Vijay Devarapalli wrote:
>up the secret. the source address in phase 1 is CoA, therefore aggresive mode
>should be used.
>
>>type.  This is a slightly different slant, but it seems the bottom line 
>>is the same: having two different addresses will confuse the implementations.
>>
>>applies *only* to the case of preshared secrets.  The wording "security 

Frank Quick

---

From: Francis Dupont <[email-masked]>
Date: Tue, 07 Oct 2003 10:17:01 +0200

In your previous mail you wrote:

=> it seems some context lacks: there are two cases: IPsec between
the mobile and its home agent, where the mobile should not use
one of its addresses as an ID, and IPsec between the mobile and
a correspondent node, where the mobile may use its home address
as an ID. And all this discussion is about phase 1 IDs, not phase 2
IDs aka traffic selectors where a care-of address must never be used.

   
=> preshared secrets have some additional issues with address based phase 1
ID payloads.

=> only when the responder is not a home agent or with other words only
when the apparent peer address of the mobile is its home address.

Regards

[email-masked]

---

From: Frank Quick <[email-masked]>
Date: Tue, 07 Oct 2003 10:58:41 -0700

>IDs aka traffic selectors where a care-of address must never be used.

Agreed that the context is very important.  The particular context that I 
would like to address is phase 1, MN performing a Binding Update with its 
home agent.  There seem to be two sub-contexts within that:

1.  Where a preshared secret exists
2.  Where public-key methods are used (typically via exchange of certificates)

The water is muddied a bit by the use of terms like "IKE phase 1" at some 
places in the I-D, while in other places IKE appears alone and the context 
seems to be phase 2 only.

1.  Where a preshared secret exists, the argument is that in phase 1:

- aggressive mode must be used.

In messages from the MN:

- the Source Address must be the CoA because the phase 1 SA is with the CoA.
- the Identification payload must uniquely identify the home address; but 
it can't be of type ID_IPV6_ADDR set to the home address because IPsec 
implementations will reject it (not equal to Source Address).

In principle it would be possible to specify behavior for a home agent that 
would allow the ID payload to be the home address.  My guess is that we do 
not do this because we want MIPv6 to run on IPsec from existing OS kernels 
without modification, and some/most/all of those perform the deadly 
consistency check.

2.  For public-key-based phase 1 (presumably main mode?), the question is 
whether this same restriction on the ID payload exists.  If it is truly an 
implementation issue, it would seem equally applicable to this case.  Your 
response below suggests that this is a general problem, not specific to 
preshared keys.  Yet both I-Ds seem to limit the requirement against use of 
ID-IPV6_ADDR to the preshared case.

Frank Quick

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Oct 2003 10:15:33 +0200

=> this sub-case only adds some complexity but the recommended solution
works for all kinds of authentication.

   
=> phase 2 is easy: only address based ID payloads make sense and
a care-of address is never used in phase 2. The only possible bad
choices are in phase 1.

   
=> this is for an IKE reason: this stands as soon as the peer address
is dynamic, i.e., the context is far larger than mobility.

   In messages from the MN:
   
=> you can remove the preshared secret context from here.

=> because only a CoA is usable before the home registration.

=> exactly

=> yes, we don't want to change IKE.

   2.  For public-key-based phase 1 (presumably main mode?)

=> this doesn't matter: aggressive mode is more efficient but less
flexible and less secure. Both work so there is no reason to specify one.

   the question is whether this same restriction on the ID payload exists.

=> the same reasoning applies so there are the same two restrictions.

   If it is truly an implementation issue, it would seem equally
   applicable to this case.

=> yes

   Your response below suggests that this is a general problem, not
   specific to preshared keys.  Yet both I-Ds seem to limit the
   requirement against use of ID-IPV6_ADDR to the preshared case.
   
=> do you ask for a new wording or this thread in the mailing list
is enough?

Regards

---

From: Frank Quick <[email-masked]>
Date: Wed, 08 Oct 2003 12:18:31 -0700

>=> do you ask for a new wording or this thread in the mailing list

If new wording is possible at this late hour it would be preferable as a 
means of avoiding future confusion.

The sections I have identified that should be considered for change are:

In MIPv6 -24:

1.  Section 5.1, page 21:

might be revised to separate the sentences, as follows:

    used.

    The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 
1.  [a reference to the ipsec
    i-d would be useful here if appropriate]

2.  Section 11.3.2, page 113:

It is not critical, but I would suggest that "the IKE exchange" read "the 
IKE phase 2 exchange".

In the ipsec-06 draft, section 4.4:

There is no mention of any problem related to the use of ID_IPV6_ADDR 
except in the context of preshared keys, where it points out that the 
different addresses make the key lookup ambiguous.  I think another 
paragraph about the implementation issue, applicable to all phase 1 
exchanges, should be added.  If this is done, a section reference might be 
added in the MIPv6 document as noted above.

I am probably not the best qualified to write this new section, but here is 
a cut at it, hoping that it will be of some use:

    o  During IKEv1 phase 1, the ISAKMP Identification payload cannot be
       of type ID_IPV6_ADDR.  Since IKEv1 does not protect the Source
       Address, IKE implementations typically compare an ID_IPV6_ADDR
       Identification payload to the Source Address, and abort if the
       contents do not match.  In IKEv1 phase 1, the Source Address must
       be the care-of address and the Identification payload must indicate
       the home address, therefore another Identification payload type
       must be used.

This should follow the current paragraph related to the preshared key issue.

Frank Quick