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

From: "Ana Kukec" <[email-masked]>
Date: Thu, 24 Apr 2008 16:31:12 +0200

Hi Steve,

Yes, CGA enabled IKEv2 ensures "only" LoF. What we need besides CGA + IKEv2 
is a PAD extension, something similar to SA constraints field. We could
specify additional field for each PAD element, eg. a raw public key used
in CGA generation or complete CGA, to identify with which peers 
implementation is allowed to talk to. In such a way we would ensure secure 
initial authentication. And what is the most important, we wouldn't be
less secure than pure IKEv2, while in the same time we will have IKEv2
implementation wihout centralized trust infrastructure.

Ana    

>Stephen Kent wrote:

Thanks for the quick response.  I'm afraid I am puzzled by your 
answer; let me explain.

My understanding of the procedure is that first time a host uses a 
CGA in an IKE SA, the peer would not have any basis for mapping that 
CGA to another form of ID. Thus this seems like LoF to me. 
(Moreover, an initial motivation for CGAs was to enable a host to use 
different addresses, either serially over time or in parallel, e.g., 
to hinder traffic analysis. If one adopts that use model, a CGA is 
not a persistent ID, and thus would be worse than a BTNS-based LoF 
model.)

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Apr 2008 11:55:18 -0400

>implementation wihout centralized trust infrastructure.

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