Subject: [mobile-ip] Mipv6 issue #195: More details on IKE processing

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Jan 2003 14:42:59 +0200

I'm trying to fulfill Cheryl's request to have more
details on IKE processing. I believe the movement discussion, issue
#194, has already answered some of the question marks about IKE. (Or
at least they are being discussed, we have not yet concluded what to
do about moving IKE endpoints.)

I'm trying to answer the remaining unclear points here.

First, the requirements section has been vague about "dynamic establishment".
We'll change the requirement

    - Manual configuration of security associations MUST be supported
      and dynamic establishment MAY be supported.

to

    - Manual configuration of security associations MUST be
      supported. Dynamic keying of security associations through IKE
      [ref] MAY be supported.

Also, there are certain limitations on how we can run IKE, given our
existing requirement on using the care-of address in IKE. My proposal
is to add the following new requirements:

    - If IKE is used, either preshared secrets or signatures MUST be
      used as the authentication method.

    - If preshared secret authentication is used in IKE, aggressive
      mode MUST be used. When preshared secrets are used in main mode,
      IKE needs to determine the shared secret to use from the IP
      address of the peer. With Mobile IPv6, however, this is a care-of
      address and does not indicate which mobile node attempts to
      contact the home agent.

Then to your question about granularity of users vs. MNs... I think I
replied earlier that in theory we could support multiple users on a
single mobile node, but that it would imply e.g. extensions to the
IPv6 source address selection rules: "Pick this address only if it is
owned by the user running the application." So, I'd really like to do
that as a later extension to Mobile IPv6, if it proves necessary. If
we can agree about this then it makes sense to restrict the current
draft to a single-user situation. My proposal is to add the following
requirement:

    - IP layer implementations are, in general, unable to ensure that a
      particular address of the machine is only used by the user
      authorized to use that address. Therefore, this specification
      requires that mobile nodes and home agents SHOULD use credentials
      that are authorized to control all addresses given to the node.

In summary the IKE-related requirements should be as follows (merging
also preliminary issue #194 results here):

General:

    - Manual configuration of security associations MUST be
      supported. Dynamic keying of security associations through IKE
      [ref] MAY be supported.

Both home agents and mobile nodes:

    - If replay protection is required, dynamic keying MUST be used.
      IPsec can easily provide replay protection only if dynamic keying
      is used. This may not always be possible, and manual keying would
      be preferred in some cases. IPsec also does not guarantee correct
      ordering of packets, only that they have not been
      replayed. Because of this, sequence numbers within the Mobile
      IPv6 messages ensure correct ordering. However, if a home agent
      reboots and loses its state regarding the sequence numbers,
      replay attacks become possible. The use of a key management
      mechanism together with IPsec can be used to prevent such replay
      attacks.

    - If IKE is used, either preshared secrets or signatures MUST be
      used as the authentication method.

    - If preshared secret authentication is used in IKE, aggressive
      mode MUST be used. When preshared secrets are used in main mode,
      IKE needs to determine the shared secret to use from the IP
      address of the peer. With Mobile IPv6, however, this is a care-of
      address and does not indicate which mobile node attempts to
      contact the home agent.

    - IP layer implementations are, in general, unable to ensure that a
      particular address of the machine is only used by the user
      authorized to use that address. Therefore, this specification
      requires that mobile nodes and home agents SHOULD use credentials
      that are authorized to control all addresses given to the node.

Only mobile nodes:

    - Where dynamic keying is used, the key management protocol MUST
      use the care-of address as the source address in the protocol
      exchanges.

    - If the mobile node has used IKE to establish security
      associations with its home agent, it SHOULD delete all IKE Phase
      1 connections run on top of the previous care-of address when the
      previous care-of address is no longer usable or is about to
      become unusable.

    - If the mobile node has used IKE to establish security
      associations with its home agent and wishes to receive
      notifications from the home agent, it MUST re-establish IKE Phase
      1 connection after movements. It SHOULD do this in parallel with
      other tasks related to movements, such as sending Binding
      Updates, as the use of existing IPsec security associations does
      not require IKE.

Only home agents:

    - If the home agent has used IKE to establish security associations
      with the mobile node, it SHOULD delete all IKE Phase 1
      connections run on top of the previous care-of address upon
      making a modification to the care-of address in a binding.

    - We need to avoid the possibility that a mobile node could use its
      security association to send a Binding Update on behalf of
      another mobile node using the same home agent. In order to do
      this, the security policy database entries MUST unequivocally
      identify a single SA for any given home address and home agent
      when manual keying is used. When dynamic keying is used, the
      security policy database entries MUST unequivocally identify the
      IKE phase 1 credentials which can be used to create security
      associations for a particular home address.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Jan 2003 11:56:50 +0100

First, the requirements section has been vague about "dynamic
   establishment".

=> it is not vague, it is open.

   
   to

=> I disagree, we should not mandate IKE.

   Also, there are certain limitations on how we can run IKE, given our
   existing requirement on using the care-of address in IKE.

=> don't forget the actual text in the draft 19 about this.

   My proposal

=> I disagree, even I've never used one of the two public key
authentication method, I can't see a reason to forbid them.

=> aggressive mode has many problems (for instance it is not widely
implemented) and IMHO it is better to discourage preshared secrets
than to mandate such things (i.e., a SHOULD NOT with explainations?)

   owned by the user running the application."

=> this is easily supported if the address selection is controlled from
the context...

   So, I'd really like to do
   that as a later extension to Mobile IPv6, if it proves necessary. If
   we can agree about this then it makes sense to restrict the current
   draft to a single-user situation.

=> IMHO the user/node concern has far deeper consequences and
should get more attention.

   My proposal is to add the following requirement:

=> I disagree. This is a global IPsec issue and we should not try to
solve it here. But it is a good idea to raise the problem in the
security area, not only the IPsec WG because the possible use of AAA
will, for instance, give exactly the other side of the spectrum.

   General:

=> this MAY is far too weak.

=> but replay protection is required (MIPv6 sequence numbers only
give ordering)? So dynamic keying is mandatory?? (I want it is
but clearly!)

=> remove "easily".

=> IMHO it is clear we need both anti-replay and ordering, so
dynamic keying and sequence numbers.

   Only mobile nodes:

=> I disagree:
 - this is true only with the home agent
 - this should be explained (in order to make things cristal clear).

=> see my comments to #194

=> idem

   Only home agents:

=> idem

=> idem

Regards

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Jan 2003 14:03:18 +0200

> authentication method, I can't see a reason to forbid them.

In this, our disagreement appears to be how open vs. strict we
make our specifications. I prefer to be pretty strict, and leave
as small number of options as possible. Good for interoperability.
You prefer open specifications, which has its advantages as well.

The thing is, as far as I know, almost no one uses the other authentication
methods beyond shared secrets and RSA/DSA signatures.

Would a SHOULD be an acceptable compromise?

Roughly the same discussion applies to leaving key management protocol
open vs. saying IKE explicitly.

> than to mandate such things (i.e., a SHOULD NOT with explainations?)

The main reason for this piece of text is a technical problem. A problem
that IMHO needs to documented and told to the reader. That is, main
mode and shared secrets don't work with MIPv6.

The other part of this issue is what to put in the SHOULDs and MUSTs.
Given the technical problem, we have only two realistic choices:

   - Forbid preshared secrets
   - Allow them, but require aggressive mode to be used

I'm not sure I'm willing to go as far as the first alternative.
We could perhaps find a compromise in signatures a MUST implement
and preshared secrets a MAY.

> should get more attention.

Yes, it is a big issue. Are you saying it needs to be done now,
or deserves its own future work item in ipv6/ipsec/mip wgs? My
proposal is to deal with it separately, and just restrict
the current spec so that we don't get ourselves to trouble.

> will, for instance, give exactly the other side of the spectrum.

I believe we should raise the issue in this document just to warn folks
of the problems.

> give ordering)? So dynamic keying is mandatory?? (I want it is

No, MNs might in fact run without IPsec replay protection. Depending
on whether the HA can reboot and lose state, they may become vulnerable
to replay attacks.

We debate this a long time ago and reached this as a solution.

>          IPsec can easily provide replay protection only if dynamic keying

Ok.

>  - this should be explained (in order to make things cristal clear).

Ok.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Jan 2003 19:02:01 +0100

=> yes, IMHO we should not abuse of "MUSTs" and we should not specify
things in the IPsec WG scope. For this special point, I don't understand
why you'd like to forbid public keys and not preshared secrets...

=> FreeS/WAN?

   
=> yes, my position is this has nothing to do in a standard track document.

=> I agree but this is not a requirement matter.

=> nowhere. If you believe we need a common profile, write a BCP.

   

=> I am afraid you have a MUST use in your proposal.

   
   Yes, it is a big issue. Are you saying it needs to be done now,
   or deserves its own future work item in ipv6/ipsec/mip wgs?

=> we should ask the IESG what to do. This issue cannot be ignored
but we should continue the MIPv6 standardization...

   My proposal is to deal with it separately, and just restrict
   the current spec so that we don't get ourselves to trouble.
   
=> if this is acceptable it is a good solution (:-).

Thanks