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

From: [email-masked]
Date: Thu, 28 Oct 2004 14:38:33 +0300

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

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

Best regards,
Pasi

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 16:26:29 +0300

> so in that sense, EAP doesn't change anything. 

Agreed.

> databases are only nominal, and not the way the information 

I agree with all of the above.

But I still have a feeling that maybe we are missing
something that the specifications should be saying.
I think it is fine that implementations do not have
to follow the nominal database implementation. And
its great that implementations can do things beyond
what has been stated in the RFCs. However, for the
purposes of using IKEv2/2401bis for the FOO application
one might wish to have a guarantee that implementations
indeed are cabable of doing the things needed by FOO,
and that the things are done in the same way by all
implementations. For instance, that the same AAA protocol
attributes are used in policy lookup; otherwise you would
have to get the gateway and AAA server from the same
vendor. An IKEv2 AAA Considerations RFC might be useful
at some point in time.

--Jari