Subject: [MOBILE-IP] authorization to issue a Binding Update for a Home Address

From: Richard Draves <[email-masked]>
Date: Thu, 14 Dec 2000 10:42:38 -0800

I'd like to suggest some text for one issue in
draft-ietf-mobileip-ipv6-13.txt, which is the mobile node's authorization to
issue a Binding Update for a Home Address.

I think a new sentence or two in section 4.4 can make this more explicit.
The new text requires authorization to use a Home Address, but it doesn't go
into detail about what kind of certificate or other infrastructure might
meaningfully provide this authorization.

4.4. IPsec Requirements for New Destination Options

   Any packet that includes a Binding Update or Binding Acknowledgement
   option MUST be protected by IPsec [13] to guard against malicious
   Binding Updates or Acknowledgements.  Specifically, any packet that
   includes a Binding Update or Binding Acknowledgement option MUST
   utilize IPsec sender authentication, data integrity protection, and
   replay protection. *New:* The security association protecting a
   Binding Update MUST explictly authorize the mobile node to use the
affected
   Home Address. Simply authenticating the mobile node to the correspondent
   node is not sufficient.

   Mobile IPv6 requires that this protection covering a Binding Update
   or Binding Acknowledgement MUST be provided by use of AH [11].  If
   another Security Association applied to the packet for other reasons
   requires use of ESP [12], for example to encrypt the transport layer
   data carried in the packet, this use of ESP is not sufficient to
   satisfy the authentication requirements of Mobile IPv6; instead,
   the packet MUST use both AH and ESP.  Use of ESP for protecting the
   Binding Update or Binding Acknowledgement is not currently defined in
   this document, since ESP does not protect the portion of the packet
   above the ESP header itself [12].

---

From: Dave Johnson <[email-masked]>
Date: Thu, 14 Dec 2000 12:52:16 -0600

Rich,

Thanks very much for the text.  I think something like this certainly
should (MUST? :-) be added.  I would reword it slightly, though, as
follows:

  However, simply authenticating the mobile node to the correspondent
  node is not sufficient; the security association protecting a Binding
  Update MUST explictly authorize the mobile node to use the affected
  Home Address.

                                        Dave

---

From: Francis Dupont <[email-masked]>
Date: Thu, 14 Dec 2000 22:33:07 +0100

In your previous mail you wrote:

=> I agree. I have talked with Christian Huitema about this and the key
(missing) word is authorization. This is what I adviced to Thierry Ernst
about mobile router draft...

=> yes, the specifications should not mandate a way to provide authorization.
The best which can be done is to give some hints (like using certificate
policies).

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 14 Dec 2000 22:48:44 +0100

I would reword it slightly, though, as follows:

=> in fact the security association doesn't authorize something, its setup
(ie. IKE) MUST verify the authorization...
I propose (Richard should find a very good wording to express this) to add
a statement/paragraph at the end of IKE considerations explaining the
policy associated to the identity verified by the  authentication function
of the phase one of IKE MUST permit the use of this Home Address (both
for BUs and the setup of SAs in phase two, BTW RFC 2409 explains a proxy
Identity payload MUST be accepted only if the policy authorizes it:
(whole paragraph from RFC 2409)

   The identities of the SAs negotiated in Quick Mode are implicitly
   assumed to be the IP addresses of the ISAKMP peers, without any
   implied constraints on the protocol or port numbers allowed, unless
   client identifiers are specified in Quick Mode.  If ISAKMP is acting
   as a client negotiator on behalf of another party, the identities of
   the parties MUST be passed as IDci and then IDcr.  Local policy will
   dictate whether the proposals are acceptable for the identities
   specified.  If the client identities are not acceptable to the Quick
   Mode responder (due to policy or other reasons), a Notify payload
   with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.

Thanks

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 14 Dec 2000 15:26:13 -0800

I suggest we should have an informational draft on mobility and
IPsec interactions. I am  ready to start one and would happy
to join with anyone who is interested in this.

This one sentence does not seem sufficient to me after yesterdays
discussion. But if agree on a separate informational draft,
we can put the details there. I would assume that the potential
problem of using a wrong identity in phase II SA should be
explained also. This will make sure that no new issues will
be raised in the future hopefully.

-mohan

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 14 Dec 2000 15:35:35 -0800

> (whole paragraph from RFC 2409)
Agreed. It will be good if we can say to the effect of :

1) Phase I SA should use certificate identities
2) Phase II SA should use client identifiers to specify the HOME address.
   This would establish a Phase II IPsec SA to use HOME address as the
   source selector.

Other details about the potential problem of using somebody elses HOME
address in Phase II can be specified in a separate document if it
would help the implementors. I personally think it would help.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Fri, 15 Dec 2000 01:05:09 +0100

=> you mean name identifies (FQDN, user_FQDN (my favorite because
it is compatible with NAI), ...) with authentication by signatures
and X.509v3 certificates? This is the best (less worse :-) solution
today IMHO.

=> address identity payload for the home address?

=> this should not be necessary because the ID clearly specifies
SAs MUST use the home address (a care-of address needs to rebuild
SAs after each movement).
I like the current text, only authorization should be added.

Thanks

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 14 Dec 2000 18:08:52 -0800

> and X.509v3 certificates? This is the best (less worse :-) solution
Agreed.

> => address identity payload for the home address?
Yes.

> I like the current text, only authorization should be added.
But the question is how does one prevent the MN from using somebody
else's home address during the phase II SA ? I agree that this
is a difficult problem but it would be good to mention this somewhere.

I really don't want to argue at this stage. But this is an important
detail which should be recorded somewhere without which route
optimization is questionable as was discussed yesterday.

-mohan

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Dec 2000 12:37:08 -0800

> and X.509v3 certificates? This is the best (less worse :-) solution

Just a note. Most IPSEC implementations today can only handle machine
authentication, not user authentication. So User_FQDN probably can only
be a MAY. Also, if you use FQDN you need a way to bind the FQDN securely
to an IP address of some sort (could be the home address).

>       This would establish a Phase II IPsec SA to use HOME address as the

If you do this, you need a way of binding the home address to the identity
used in IKE MM.

>is a difficult problem but it would be good to mention this somewhere.

I think you need to think this through now. It's not as simple as you
might think. There are a number of security vulnerabilities that have
resulted in the need to sanity check the source IP address, not just use
the SPI and destination IP address. To my mind, the proposal isn't really
complete -- IPSEC doesn't provide the necessary
bindings by itself, and you haven't specified how they are accomplished.

For example, think about the following issues:

a) How is the FQDN/User_FQDN securely bound to the home address? Merely
convincing someone that I'm fred.bigco.com doesn't tell them anything about
what home address I'm allowed to use. Are we going to require DNSSEC to
provide the binding? And is it possible to bind [email-masked] to a
home address? Here DNSSEC won't even necessarily help you.

b) If you can't accomplish this binding, what use is using the home
address as the identifier in QM? Any user able to authentication in MM
can then send in a bogus binding update for another authenticated user.

c) How do the IPSEC correspondents sanity check the source IP addresses?

To be able to do this it seems that you'd need to be able to validate
the binding between FQDN/USER_FQDN and home address. By the way, if you
can do this, I don't see the difference between AH and ESP in terms of
security. If you can't, then neither is really secure. Can someone provide
a counter example of an attack that could succeed against one and not the
other?

d) How is "authorization" performed?

I think that this is a code name for FQDN/User_FQDN - home agent binding,
but I'm not sure.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Dec 2000 11:21:43 +0100

Just a note. Most IPSEC implementations today can only handle machine
   authentication, not user authentication.

=> Mobile IPv6 needs only the node authentication which is provided by IPsec
(user authentication and AAA is another issue). The user_FQDN is my favorite
because it is in fact a NAI, ie. something which is common to mobile IP,
PPP extended authentication, AAA, IPsec, ... This does not imply that
we should to authenticate the user in place of the node, it is only an
open door between user and node levels.

   So User_FQDN probably can only be a MAY.

=> hum, there is no list of legal identities (identity payload types)
for phase 1 and 2... We are very far from a SHOULD.

   Also, if you use FQDN you need a way to bind the FQDN securely
   to an IP address of some sort (could be the home address).

=> this is again the authorization problem. I don't understand why
this is so hard for mobile IPv6 when the problem exists for VPN too
(a security gateway will give a subnet identity in phase two, this
should be accepted only if the peer is authorized to be a security
gateway for this subnet. The text in RFC 2409 is (near) clear about this:

Then if the IDci or IDcr are not the address identities of the peers
then local policy must authorize or not authorize them.)
I can't see a real difference between mobility (different address) and
VPNs (subnet), both need authorization. BTW I'd like to know how
this is implemented in current IKEs (ask IPsec people?)

=> I believe we need a bit more than a binding: an authorization.
The good thing here is that we have a higher level identity and the
static well-known address (ie. it will be far harder to "bind" the
identity with a random care-of address).

   I think you need to think this through now. It's not as simple as you
   might think. There are a number of security vulnerabilities that have
   resulted in the need to sanity check the source IP address, not just use
   the SPI and destination IP address.

=> I agree, IPsec specifies the protected traffic MUST be between the
negociated (in phase two) entities and mandates a check for the source
address (which one and when to do the check is unfortunately implementation
dependent, most implementations are compliant, many are not interoperable).

   To my mind, the proposal isn't really complete -- IPSEC doesn't provide
   the necessary bindings by itself, and you haven't specified how
   they are accomplished.

=> I agree. IPsec provides only the strong authentication, not the
authorization itself. What are the IETF WGs in charge of the authorization?
AAA can do it but AAA is for users, not nodes, and we wouldn't like
to restrict mobility to mono-user nodes only, even this case is very common.

=> DNSSEC and AAA are two obvious answers but none is a complete answer,
ie. they can work in some (important) cases but not in all cases.
They are not deployed/usable today too... (but you can answer mobility
will be a good reason to deploy them quicky :-).

=> we already agree about the need to add authorization.

=> the mobile node source address is the care-of address and is nearly
random. The only available sanity checks are trivial (for instance the
mobile node should not use one of my addresses, should use an address
with the proper scope, ...).

   security.

=> you need to protect both the care-of and the home addresses. If you do
that with an ESP it is more expensive (you have to repeat the care-of in
an alternate care-of suboption) and the source address check will fail
if you have not hacked your implementation in order to support this
particular case.
There is a common situation where you'd like to use an ESP: you already
have an ESP tunnel between the mobile node and the correspondent.
I am writing a draft with Richard Draves about this important case.

   If you can't, then neither is really secure. Can someone provide
   a counter example of an attack that could succeed against one and not the
   other?

=> the choice between AH and ESP was not done according to security
requirements (both can provide authentication, integrity check and
anti-replay for the critical elements) but because AH is simpler
(just because it was designed for this kind of applications :-)
and has no known issue with compliant IPsec implementations.

=> this is a bit more, in (poor) English this is something like
"a node with this (proved) identity can use mobility with this home address".
Of course the authorization between the mobile node and its home agent
is critical (and easier to do, a (unscalable) static configuration works,
DNSSEC or AAA or ... are simpler to setup too in this case).

Thanks

PS: if nobody explains how to provide authorization before the end of the year
I'll put a message about the issu in the IPsec mailing list. VPN is an
enough important market to get a detailed answer, isn't it?