Subject: Re: [IPsec] IPsec maintenance/extensions WG?

From: Ana Kukec <[email-masked]>
Date: Wed, 07 May 2008 15:02:24 +0200

Hi Steve,

Sorry for the delay with replay.

We agree that LoF is useful mechanism in IKEv2 context and could be 
supported in different manners, as you pointed out. The advantage of CGA 
over others is easy deployment, since CGAs require minimal overhead to 
existing IKEv2 implementations. With certificates (even self-signed), 
IKEv2 payloads and verification mechanisms, as well as initial 
pre-arrangements and configuration are more complicated.

We also agree that CGAs or bare public keys are not the only way to 
avoid centralized trust architecture. But, since CGAs are widely 
accepted and deployed in IPv6, from the deployment point of view and 
from the user point of view, it is more appropriate to use CGAs than 
bare public keys or self signed certificates (traditional CERT/CERTREQ 
fields).

Regarding the PAD complexity, IMHO, a new PAD column (for CGA support) 
is minimal overhead to PAD. After all, PAD needs some extensions in any 
event. AFAIU, it is designed to be extensible.

And regarding the secure initial authentication and SPD constraints, i 
agree, we don't need new column to support CGA constraints, since we can 
use SPD constraints in both cases.

Ana

Stephen Kent wrote:
>
> OK, I'm happy to hear you agree that, by itself, CGA would also just 
> be an LoF mechanism like BTNS.
>
> First, I want to observe that If one had the ability to store a public 
> key in the PAD for authorization, then one can also store a cert. The 
> cert can be a self-signed CA cert, under which the EE cert for the 
> peer is issued. So the argument that one needs to use bare keys to 
> avoid a centralized infrastructure is simply not true, even if it is 
> often cited :-). RFC 4301 has a requirement that the PAD support X.509 
> certs and pre-shared secrets, but not for bare public keys. In part 
> this is because mandating support for bare public keys would be 
> redundant given the above analysis, and thus would only add to the 
> complexity of the PAD.
>
> Second, once you have a PAD entry, you can use either an address or a 
> name as the basis for SPD entry constraints. If you use name-based 
> constraints, then no new mechanisms are needed when CGAs are employed, 
> and the CGA can even change over time (as originally envisioned) 
> without needing to change the PAD or SPD entries.
>
> If the CGA remains constant, then it becomes equivalent to a 
> traditional IP (v6) address re access control, and the PAD could be 
> configured with that address as a trivial address range for traffic 
> selectors, and one can use the address in SPD entries. So I'm not sure 
> why one needs new IKE payloads and new PAD entry values to accommodate 
> CGAs.
>
> Steve
>

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