Subject: [CGA-EXT] Next steps

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 18 Nov 2009 10:56:23 +0100

Hi,

In the meeting, the following next steps for our charter items were 
proposed:

draft-ietf-csi-hash-threat will be shipped to the IESG

draft-ietf-csi-proxy-send: we will issue the WGLC right away

draft-ietf-csi-send-cert will be updated and the message format for 
getting the CRL information will be removed, only the default URI based 
method will be kept in the document. The WG can discuss separatelly 
whether we want to define the send messages to obtain CRL information.

draft-rgaglian-csi-send-name-type-registry-01 will be adopted as WG 
document, so authors should submit this as draft-ietf-csi-...

draft-ietf-csi-dhcpv6-cga-ps needs to address S. Kent comments about the 
security achieved by using CGGAs to authorize the DHCP server (i.e. 
relies on haivingt he dhcp address configured and not very different 
from having a shared  secret configured, and describe the leap of faith 
approach as well. In addition, should cover the privacy issues with 
storing the CGA information in a central repository)

In addition, we need to continue the discussion on PK agility support in 
SeND.

The goal of this mail is to confirm the agreement in the ml. so if 
people have issues with the proposed next steps please speak up before 
dec 1st. If no objections are presented, i would ask the editors to 
update the document to reflect this.

Regards, marcelo

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 18 Nov 2009 16:05:44 +0200

Marcelo,

I would like to start the discussion on how the host should fetch the CRLs. This will serve as a base for a future I-D.

We have at least three options:

1) To specify the  "Certificate Revocation Solicitation /  Certificate Revocation Advertisement" messages just like in SEND to request certificates.

	Advantages:
		- The router could cache the CRLs, which will be the same ones for most of the hosts. More-over the certs and the CRL may be pre-loaded by the router which only needs to check for a new CRL before the "next update".
		- Lightweight implementation at the hosts.
	
	Disadvantages:
		- Need specification, probable changes to RFC 3971.

2) To use the default fetching mechanism at the CRL Distribution Points extension for each CA. Today the only mandatory fetching mechanism is RSYNC.
	Advantages:
		- no changes in the current specifications.

	Disadvantages:
		- need to implement RSYNC client in hosts.
		- no cache, the same CRL will be fetch by every host from the source. 

3) To modify the Certification Path Advertisement Message in the sense that every time a certificate is sent to the host, it will also include the CRL shown in its  CRL Distribution Points extension. So, you asked for a CERT, I send you both the CERT and the CRL (for signed with the same key).

What does the WG think?

Roque.

-------------------------------------------------------------
Roque Gagliano
LACNIC
[email-masked]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE

---

From: Tony Cheneau <[email-masked]>
Date: Wed, 18 Nov 2009 17:15:40 +0100 (CET)

Hello Rogue,

I have no opinion to express yet. However, can you clarify your third
proposal ? You propose to modify RFC 3971 so a CPA message contains
both a Cert AND the corresponding CRL ? This is somehow an optimization of 
your first proposal ?

Another advantage of solution 1 and 3 is that the node can verify the
validity of a prefix during the Stateless Address Autoconfiguraton
procedure, before assigning any addresses corresponding to this prefix to
an interface. This, IMHO, is an important feature.

Thanks for starting this discussion Rogue.

Regards,
 	Tony

On Wed, 18 Nov 2009, Roque Gagliano wrote:

> _______________________________________________
> CGA-EXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cga-ext
>

---

From: Tony Cheneau <[email-masked]>
Date: Sun, 22 Nov 2009 23:13:13 +0100 (CET)

Hi Rogue,

>> both a Cert AND the corresponding CRL ? This is somehow an optimization of your first proposal ?
>
> What I though that could be theoretically possible is that when a host request a certificate, the router could send the certificate and the CRL in the Certification Path Advertisement Message. However, if you have a host that is connected for several hours, you will need to go back to fetch the new version of the CRL from time to time without needing to request the Cert because those are long living. For this reason, option 3 may not be such a good idea.
Sending an extra certificates every few hours to keep the protocol
"simple" (reusing the same CPS/CPA messages) does not sound too bad for
me. Moreover, you could multicast the message to the All-Node
address, so all the node on the link can know that a certificate is
still valid. What is the opinion of the other people on the list ?

> It is true that with option 2 you probably would need global unicast addresses to access the repositories that are outside of the local network while with option 1 you could send CRL request messages to the router using link local addresses. Is this what you meant?
Not exactly what I meant. I meant, you could send CPS/CRS message with the 
unspecified source address and receive a CPA/CRA from the router destined 
to the All-Nodes Multicast Address. Hence, you do not need to assign any 
addresses to our interfaces until you are sure that router's certificate 
has not been revoked.

Regards,
 	Tony