Subject: RE: Policy lookups (Was: [Ipsec] Reauthentication in IKEv2)

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Nov 2004 12:31:00 -0500

At 2:38 PM +0300 10/28/04, [email-masked] wrote:
>Jari Arkko writes:
>>
>>  Hi Pasi,
>>
>>  > For policy lookups, it's very important to use the identity
>>  > (identifier) that was actually authenticated by the EAP method,
>>  > and this is not necessarily the same as IDi. Many EAP methods
>>  > have an internal identity exchange, and the initial identity
>>  > (e.g., IDi or EAP Identity Response) is used only for AAA
>>  > routing and selecting which method to use (see RFC 3748,
>>  > sections 5.1 and 7.3). "Reauthentication identities" in some
>>  > EAP methods are an obvious example where using IDi for policy
>>  > lookups fails, but that's not the main reason.
>>
>>  I agree, but is this specified somewhere? RFC2401bis-04 has
>>  this text:
>>
>>    1. A named SPD entry is used by a responder (not an
>>       initiator) in support of access control when an IP
>>       address would not be appropriate for the Remote IP
>>       address selector, e.g., for "road warriors."  The name
>>       used to match this field is communicated during the IKE
>>       negotiation in the ID payload.  In this context, the
>>       initiator's Source IP address (inner IP header in tunnel
>>       mode) is bound to the Remote IP address in the SAD entry
>>       created by the IKE negotiation. This address overrides
>>       the Remote IP address value in the SPD, when the SPD
>>       entry is selected in this fashion.  All IPsec
>>       implementations MUST support this use of names.
>>
>>  This seems to talk about the ID payload, not the value
>>  communicated from the AAA server. Does the text need to be
>>  updated, or am I missing something?
>>
>>  Secondly, the remote (inner) IP address presumably may
>>  come from RADIUS too?
>
>Clearly it's already possible to e.g. use some value from the
>certificate for policy lookup (instead of the IDi payload),
>so in that sense, EAP doesn't change anything.
>
>And I don't think it matters whether the IP address comes from
>RADIUS server or an internal pool maintained by the gateway: in
>either case, it comes from somewhere "outside" the functionality
>described in 2401bis.
>
>I guess the confusion is mostly because even with the addition
>of PAD, 2401bis does not very clearly separate which parts of
>SPD are used during per-packet processing in the kernel, and
>which are only used during IKE negotiation. And the parts used
>only by IKE are not that close to what actual implementations
>do...

I think 2401bis does address this issue. The original SPD entry (not 
decorrelated) is used for IKE negotiation. With the introduction of 
caching, it is explicit that outbound packets are matched against 
cache entries, which consist of decorrelated SPD entries. A cache 
entry may be qualified relative to the SPD entry from which it was 
derived, if the PFP feature is used.

>(Of course, it's not even the intention of 2401bis to document
>actual implementations, and it is explained that e.g. the
>databases are only nominal, and not the way the information
>has to be stored.)
>
>>  Finally, I wonder how the named SPD entry setup should be
>>  administered.  Lets assume there are a million potential users
>>  in the service provider's RADIUS (or Diameter) database. Is
>>  there going to have to be a million SPD entries too in the
>>  gateway, or an the RADIUS responses point to a "class" entry
>>  for a particular type of a user (e.g., "subscriber" and
>>  "administrator")?
>
>Fortunately, no; this is one part where the real implementations
>don't match the "nominal SPD" that closely..

Unless each of the million users has different requirements for SAs, 
there would never be a need to create a million SPD entries. After 
all, we support use of names and structured names can have wildcard 
elements. So I don't think the cited example really requires 
deviation from the SPD model.

Steve

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Nov 2004 16:28:58 -0500

At 12:54 PM +0300 10/28/04, Jari Arkko wrote:
>>sections 5.1 and 7.3). "Reauthentication identities" in some EAP 
>>methods are an obvious example where using IDi for policy lookups 
>>fails, but that's not the main reason.
>
>          1. A named SPD entry is used by a responder (not an initiator)
>             in support of access control when an IP address would not be
>             appropriate for the Remote IP address selector, e.g., for
>             "road warriors."  The name used to match this field is
>             communicated during the IKE negotiation in the ID payload.
>             In this context, the initiator's Source IP address (inner IP
>             header in tunnel mode) is bound to the Remote IP address in
>             the SAD entry created by the IKE negotiation. This address
>             overrides the Remote IP address value in the SPD, when the
>             SPD entry is selected in this fashion.  All IPsec
>This seems to talk about the ID payload, not the value communicated
>from the AAA server. Does the text need to be updated, or am I
>missing something?

We were trying to provide a description of how to relate an 
authenticated ID from IKE to an SPD entry. We did not want to become 
tied to any specific ancillary authentication method used by IKE, 
hence no reference to cert fields here. For the same reason, I would 
not want to talk in EAP-specific terms.

>Secondly, the remote (inner) IP address presumably
>may come from RADIUS too?

Again, to be uniform in the description we talks in terms of what KE 
passes over to IPsec. If IKE interacts with a RADIUS server to 
acquire the inner address, I'd like IKE to do that invisible to IPsec.

>Finally, I wonder how the named SPD entry setup should be administered.
>Lets assume there are a million potential users in the service
>provider's RADIUS (or Diameter) database. Is there going to have to
>be a million SPD entries too in the gateway, or an the RADIUS responses
>point to a "class" entry for a particular type of a user (e.g.,
>"subscriber" and "administrator")?

No, no need for a million SPD entries, unless each individual needs 
to have a distinct security policy applied to his/her traffic. For 
example, imagine a context in which the users are named via FQDNs. 
One could create a single entry in an SG for *.foo.com, and it would 
match all the folks who work at foo.com. In the PAD, one could assert 
that the CA for foo.com is authorized to issue certs for entities 
with names of the form *.foo.com.  An IKE exchange with an ID payload 
that has a name that matches *.foo.com, and which is authenticated 
using a cert issued to the same, named entity, and which is verified 
using the foo.com CA as a trust anchor, would be acceptable under 
this PAD entry.   The single SPD entry noted above applies to ALL 
users/laptops certified by that CA. So IF they are all supposed to be 
covered under the same policy, you could get by with just one SPD 
entry, which might result in multiple SAs, depending on the details 
of the entry.

Steve