Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-erx-00

[Yoav Nir <[e-mail]>]

On May 5, 2011, at 11:41 PM, Yaron Sheffer wrote:

Hi,

I think we are going down a rathole on the issue of "authenticated identity". Most IKE gateways, like many other security devices, normally make policy decisions based on groups. I will provide secure connectivity to [e-mail]<mailto:[e-mail]>, but not to [e-mail]<mailto:[e-mail]>. But I don't want to differentiate [e-mail]<mailto:[e-mail]> from [e-mail]<mailto:[e-mail]>.

True, but often we cut the groups finer than that. If John works in sales and Jane works in R&D, they may have different authorizations (John does not go near the source control, Jane does not get to see the financial statement to be published next week). To negotiate the appropriate selectors, the gateway needs some group information. This can be done by abusing some RADIUS attribute to convey policy information, or else by querying a directory with the username received in EAP.

With ephemeral identities I don't see how this could work, unless we assume that there is a way for the gateway to query the AAA about some attributes of the user behind the EMSKNAme.


It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to http://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com".com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names.

So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions.

I'm not even sure of that. Qin, does ERP give us the domain name of the original authenticating server?  Do we even know if the user came from this-isp or that-isp?


Thanks,
    Yaron