Subject: [mobile-ip] About authorization and security policies

From: Pekka Nikander <[email-masked]>
Date: Wed, 08 Aug 2001 13:25:31 +0100

If I understood correctly the discussion on Monday at the mobileip
WG meeting, people seem to agree that we can and we should 
separate the problem of authenticating individual BUs and
and the problem creating keying material for authenticating BUs.

I think considering the problems separately is a good thing.
However, based on the discussions I've had with some people,
there seems to be some tendency to forget the authorization and
security policy issue when we do this separation.  In this message
I try to (once again) clarify the issue.

Now, independent on whether the actual BUs are authenticated
and integrity protected with AH (or ESP if you will) or using
separate authentication data in the BU itself (a la current -14
draft), care must be taken that the keying material used to
create and verify the protection has been _created_ in a suitable
way.  That is, the SA used to protect the BU must be _authorized_
to protect BUs _for_the_specific_Home_Address_.  

Please note that I am leaving some implementation details aside
(like how to use IPsec SDP to differentiate BUs from other traffic).
My point really is try to clarify the need for a proper security
policy and for making sure that the key management protocol takes
care of checking that the security policy requirements are fulfilled
when the SA is created.

Let me consider four combinations: 
a) using IKE and AH/ESP and 
b) using BAKE and -14 authentication data
c) using IKE and -14 authentication data
d) using BAKE and AH/ESP

Case A.  IKE and AH/ESP

Let us assume that AH (or ESP with integrity protection) is used to
protect the BUs.  In that case, there must be an entry in the
IPsec SPD specifying at the receiving host (CN) that if the
BU is protected with the given SA, then the BU can be accepted
and the corresponding Binding Cache entry can be created.
Otherwise, if the SDP databased does not allow Binding Cache
entry creation, such an entry MUST NOT be created even if the
packet integrity and authenticity was correctly verified.

In other words, the SPD makes sure that the SA is _authorized_
to protect BUs for that specific Home Address.  It is important 
to note that it is _not_ enough that the BU is protected with
_some_ SA, but that the SA used for protection MUST be created
in such a way that it is known to be properly authorized.

[Side note: Some people have pointed out that if we get a
separate next header number for BUs and discontinue
piggypacking, current IPsec SPD implementations and key
management protocols do have enough of granularity to 
define and create such a policy.  However, that is not the 
point of this message.]

What is important to note here is that even if you use a (local) PKI 
so that you know who your peer is, you DO have the danger of creating
not-properly-authorized SPD entries.  That is, when running a key
management protocol and checking the certificates, you 

  a) either must know (or at least believe) that all hosts 
     certified by your PKI are fully honest and competent, or 

  b) your PKI must explicitly contain information specifying 
     the home addresses of the hosts.

Furthermore, in the latter case, even if the PKI contains the home 
addresses, you must somehow know that the CAs in the PKI are either 
fully honest and competent, or that they are otherwise authorized to 
specify the home addresses given.

[Site note:  Since X.509 certificates may specify IP addresses
as identifiers, you can establish b).  However, you still have
to trust in the competence of your CAs checking the IP addresses
when creating certificates.  Note also that if you have a local
PKI, you may well essume a).  You just need to be aware that you
are making such an assumption (if you are), and the dangers created.
Again, however, that's not the point.] 

Case B.  BAKE and -14 authentication

Let us now assume that -14 authentication is used to protect
the authenticity and the integrity of the BUs.  Now, the
implementation itself implicitly takes care of part of the policy, 
since the -14 authentication cannot be used for anything else but 
authenticating BUs.  However, care must still be made to make sure 
that the SA used is authorized for creating Binding Cache Entries 
for the specific Home Address.  

Thus, from the policy point of view, the most important thing for
BAKE is to make sure that when an SA is created (as a result of
running BAKE), there is a reasonable amount of assurance that the
peer node (who shares the SA) is really authorized to create
Binding Cache entries for its (claimed) Home Address.  Basically,
BAKE achieves this by checking that the peer node is reachable 
through the Home Address.

Case C.  IKE and -14 authentication

If we want to use IKE with -14 authentication, we basically need
a new DOI (or extension to the Internet DOI), specifying how 
authentication data for -14 BU authentication is created.
That is certainly some amount of work, but doable.

On the other hand, however, care must still be made that when
the SAs are created, IKE checks that the peer node is indeed
authorized to create Binding Cache entries for the given Home
Address.  Thus, in this sense the situation is similar to Case A.

Case D.  BAKE and AH/ESP authentication

There is no fundamental reason why BAKE could not be used for
creating AH or ESP SAs.  The only restriction is that such
AH or ESP SA __MAY_NOT__ be used for any other purpose but
protecting BUs.  In this sense, we come back to the Case A
SPD discussion, where I noted that the IPsec SPD MUST be able
differentiate BUs from other packets.  In this case, however,
the SA is valid ONLY for BU authentication, i.e., in a way
reverse to the Case A situation where a generic IPsec SA 
is NOT good for BU authentication unless the peer authorization
has been positively checked during the IKE negotiation.

I hope this helps to clarify the situation.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 10 Aug 2001 11:36:26 +0200 (CEST)

> I hope this helps to clarify the situation.

Yes. Thank you very much!

In case A (IKE and AH/ESP) I think one way of getting the
authroization is to have the SA be created between the home address and the
correspondent. Thus in this case the routability to the home address can
be used implicitly by IKE in the key exchange.

Thus as long as there is a way for iked to tell IP to ignore 
the binding cache when sending the IKE packets this should fall out
pretty easy unless I'm confused. (Of course, my confusion increases 
assympotically during the IETF week :-)

Such an approach would mean that you would need to do something
different with respect to IKE for the MN to HA exchanges since
in that case you can't rely on the HA reaching the MN as a way
to establish authorization. Thus in this case you want to associate
a something (shared secret, certificate) with the authority to "be"
a certain MN. But this is a local issue contained within the HA
as far as I can tell.

  Erik

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 10 Aug 2001 15:03:37 -0700 (PDT)

> assympotically during the IETF week :-)
This is discussed in section 10.2 of the ipv6 draft. It specifically
says that IKE must use only CoA as the source address. If you want
to use the Home Address, then i think you should setup the SA with
Home Agent first (so that it has the right binding cache) using the
CoA as the source address. Then, while setting up the SA with CN use
the home address (and possibly a socket option on the other end to
avoid using the binding cache), i think there should not be any
problem.

-mohan

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Aug 2001 11:06:46 -0700 (PDT)

> in such a way that it is known to be properly authorized.

Pekka,

This is really no different than saying that _ANY_
service which relies on IPsec layer
integrity/confidentiality MUST cross check which
credentials were supplied to create that SA to
perform an authorization check. This is really no
different than using transport/ESP for SIP traffic
and then making the rash assumption that it will
also protect you from forgery attacks in the
inside payload (eg, IPsec says [email-masked], but
SIP From: [email-masked]). There are obviously
other attacks (authorization attacks too), but
what is pertinent is that the cross checking must
be performed at upper layers as appropriate.

 >      the home addresses of the hosts.

Correct. However, in a lot of situations (a)
brings acceptible risks. In particular, enterprise
like situations make all kinds of assumptions that
insiders will be basically honest which greatly
simplifies security policy (whether this is
misguided is a different discussion). Also: even
in situations where users are not fully trusted,
policing may be able to provide an adequate risk
if the penalty is high enough (ie, lose service if
you hack, etc.)

 > That is certainly some amount of work, but doable.

Except for the fact that there's a long standing
and now very public moratorium on new IKE development.

 > protecting BUs.  

I could be, but I would think that opportunistic 
encryption would be a better way to achieve the
same ends.

	Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 21:34:51 +0200 (CEST)

> and now very public moratorium on new IKE development.

Before assuming that a new DOI is subject to the moratorium it would
make sense to check with the security ADs - I don't know the answer.

  Erik

---

From: Dan Harkins <[email-masked]>
Date: Mon, 13 Aug 2001 19:52:21 -0700

On Wed, 08 Aug 2001 13:25:31 BST you wrote
> authentication data for -14 BU authentication is created.

Why? The DOI does not specify how authentication data is created.
That is done in AH (2402) or ESP (2406) RFC. 

  Dan.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Aug 2001 09:39:04 +0300

> That is done in AH (2402) or ESP (2406) RFC. 

The use of IKE with -14 authentication doesn't
require a full DoI. It requires an _extension_
to the current DoI. Such extensions are regurlarly
done to add algorithms. This extension would be
a bit bigger perhaps -- adding a new protocol --
but still basically a number allocation in some
defined place.

However, one drawback of using IKE with -14
authentication is that other key management
protocols would have to be updated also. For
instance, the possible Son-of-IKE protocol
would also be affected. (It may be that
all these protocols share the same DoI and
algorithm numbers, but I'm not sure if this
would be the case always.)

Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 14 Aug 2001 08:21:43 -0700 (PDT)

> That is done in AH (2402) or ESP (2406) RFC. 

   Are you implying that if I wanted to use the current IPsec
   DOI to key, oh say, SNMPV3 USM entries that would be OK
   with IKE as-is? If nothing else, how would the quick mode
   exchange know which to stuff the keying material in?

	    Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Aug 2001 18:59:03 +0200

> I hope this helps to clarify the situation.
   
=> as we are not beginning from scratch, I'd like to add some comments
about IKE.
There are three important peer properties for IKE in this context:
 - the IPv6 address used for IKE exchanges
 - the phase one identity which can be an address or a name or other thing
 - the phase two identity which is not an identity but the peer address
   of the SA pair.
 The only restriction on the first (transport) address is the transport
must work, so with a common correspondent both the home and the care-of
addresses are right (with a lot of pros/cons) but with the home agent
for the (first?) home registration from visit only the care-of address works.
This last point gives a MUST in I-D 14 but in fact the MUST should not be
for all cases (cf previous threads in this list about it).
 The phase one identity is very important because this gives th
authentication. There is a special complexity with shared secrets so
I assume X.509 certificates are used (and a PKI is available).
The subjectName or an alternate subjectName of a valid certificate must
match the identity (or certicates are not useful, cf a thread in IPsec
list if this is not obvious). If the identity is an address most
implementation checks it against the transport address.
 The phase two identity (i.e. the SA source address selector) must be
the home address because of the home address option processing rules
and because a new SA pair per hand-off (the rationale for the rules)
would be too expensive. If the identities between the two phases are
different then there is an authorization constraint. IKE documents
don't explain how to express this authorization, nor implementation
examination... There is only one case where a good solution (i.e.
something which already runs) is the home agent which already knows
all the potential mobile nodes.
 I can resume choices:
  - care-of for transport, phase one address identity => doesn't work
  - care-of for transport, phase one name identity => authorization issue
  - home for transport => works but not for home registration
   
   In case A (IKE and AH/ESP) I think one way of getting the
   authorization is to have the SA be created between the home address and the
   correspondent. Thus in this case the routability to the home address can
   be used implicitly by IKE in the key exchange.
   
=> this is the simple solution but there is an important exception...

=> throw away this binding cache consideration...

   Such an approach would mean that you would need to do something
   different with respect to IKE for the MN to HA exchanges since
   in that case you can't rely on the HA reaching the MN as a way
   to establish authorization.

=> the MN to HA is special but we can assume many things too!

   Thus in this case you want to associate
   a something (shared secret, certificate) with the authority to "be"
   a certain MN. But this is a local issue contained within the HA
   as far as I can tell.
   
=> any local ad hoc mechanism works. The only trouble with IKE
in this (MN-HA) case is with IKE performance (cf proposals to use AAA
in an opportunistic way, KINK or HIP will be great too).

Regards

[email-masked]

PS: two other ideas (results of authentication/authorization brain storming):
 - a "home address" identity
 - lookups for key or cert RRs in the DNSSEC reverse (i.e. ip6.arpa) map.