5 Nov 2009 11:22
11 Nov 2009 10:54
Adoption of draft-rgaglian-csi-send-name-type-registry-01
Dear WG, I issued version 01 of the draft with some typos from version 00. As discussed during the WG meeting, I would like to request the submission of the draft as a WG item. Referring to the question from the chairs about the use of SHA-1 in the SKI extension, AFAIK it is the current possible definition of the SKI in RFC 5280 and in the cert profile for SIDR. This is not a security issue per-say as the SKI is an identifier and not the signature of the certificate. Regards, Roque. ------------------------------------------------------------- Roque Gagliano LACNIC roque@... GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE
11 Nov 2009 14:02
Re: DHCP Solution work.
Hi Marcelo, As per our conversation today, I would like to inform CSI folks that my presentation (as mentioned in your agenda): - DHC&CGA solution document draft-xia-dhc-host-gen-id-02.txt Frank - 10 min somehow got skipped. The presentation I sent to you is nowhere to be found. In the proceedings, http://www.ietf.org/proceedings/09nov/slides/csi-3.ppt and http://www.ietf.org/proceedings/09nov/slides/csi-4.ppt point to the same file on the open source work. Based on the above confusion, it seems to me that a wrong conclusion of no interest in the working group to do solution work on CGA-DHCP interaction has been reached. I am hoping that you will take some steps to correct this. Regards, Behcet ----- Original Message ---- > From: marcelo bagnulo braun <marcelo@...> > To: "cga-ext@..." <cga-ext@...> > Sent: Thu, November 5, 2009 4:22:52 AM > Subject: [CGA-EXT] slides, notetakers. > > Hi, > > I would ask people presenting if they could send me the slides by monday > 1300hrs.(Continue reading)
12 Nov 2009 08:41
Fw: DHCP Solution work.
Hi all, After further discussion with Marcelo it became clear that what I wrote below needs to be disregarded. Please disregard my previous mail. Apologies for the confusion. Behcet ----- Forwarded Message ---- > From: Behcet Sarikaya <behcetsarikaya@...> > To: marcelo bagnulo braun <marcelo@...>; "cga-ext@..." <cga-ext@...> > Sent: Wed, November 11, 2009 7:02:40 AM > Subject: Re: [CGA-EXT] DHCP Solution work. > > Hi Marcelo, > As per our conversation today, I would like to inform CSI folks that my > presentation (as mentioned in your agenda): > - DHC&CGA solution document > draft-xia-dhc-host-gen-id-02.txt > Frank - 10 min > > somehow got skipped. The presentation I sent to you is nowhere to be found. In > the proceedings, http://www.ietf.org/proceedings/09nov/slides/csi-3.ppt > and http://www.ietf.org/proceedings/09nov/slides/csi-4.ppt > > point to the same file on the open source work. > > Based on the above confusion, it seems to me that a wrong conclusion of no > interest in the working group to do solution work on CGA-DHCP interaction has > been reached.(Continue reading)
18 Nov 2009 10:56
Next steps
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-(Continue reading)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
18 Nov 2009 10:57
WGLC for draft-ietf-csi-proxy-send-01
This is WGLC for draft-ietf-csi-proxy-send-01. Please review the document and send comments to the ml before dec the 9th. You can find the document at: http://tools.ietf.org/id/draft-ietf-csi-proxy-send-01.txt Regards, marcelo
18 Nov 2009 15:05
Re: Next steps
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).(Continue reading)
18 Nov 2009 17:15
Re: Next steps
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: > 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:(Continue reading)
19 Nov 2009 11:54
Comments on draft-ietf-csi-proxy-send-01
Hello, I reviewed draft-ietf-csi-proxy-send-01 and have the following comments/remarks: - In section 4.1, "figure 1: Proxy ND operations", in the first message, I think the "SLLAO = B_LL" should be "SLLAO = A_LL" - Small typo in section 6, "(PSO.)" should be "(PSO)." - I have a concern about the content of the Security Considerations (Section 8). It would be nice to have a warning text such as: "Note that if a Secure Proxy ND is corrupted, it can impersonate all the node in the subnet in which it is authorized to act as a proxy." - The section 10 (normative references) contains a reference to [I-D.ietf-netlmm-proxymip6] that is now RFC 5213 As you can see, I have only minor comments. The document is in a good shape. Hope it helps. Regards, Tony Cheneau
19 Nov 2009 18:21
Re: Comments on draft-ietf-csi-proxy-send-01
Hi Tony, Thanks for reviewing the draft! Replying to your concern on the security considerations "t would be nice to have a warning text such as: "Note that if a Secure Proxy ND is corrupted, it can impersonate all the node in the subnet in which it is authorized to act as a proxy." I wouldn't use the term impersonate -- the delegation certificate doesn't allow the proxy to impersonate nodes (they're only used for SEND), only to issue ND signalling on their behalf. So a compromised proxy is able, like a compromised router, to siphon off traffic from the host, or mount a man-in-the-middle attack. Looking at RFC 3971 for compromised router, it states: SEND does not protect against brute force attacks on the router, such as DoS attacks, or against compromise of the router, as described in Sections 4.4.2 and 4.4.3 of [RFC3756]. (as a side note the sections number of RFC 3756 being referred to above do not exist, I believe it should say 4.2.2 and 4.2.3. Could be fixed in a revision of RFC 3971) So maybe we want to say something like: Thanks to the authorization certificate it is provisioned with, a proxy ND is authorized to issue ND signalling on behalf of nodes on the subnet. Thus, a compromised proxy is able, like a compromised router, to siphon off traffic from the host, or mount a man-in-the-middle attack. As for SEND, which does not protect against against compromise of the route as described in Sections 9.2.4 of [RFC3971], Secure Proxy ND Support for(Continue reading)
RSS Feed