headers
Roque Gagliano | 4 Feb 2010 17:03
Favicon

Fwd: New Version Notification for draft-ietf-csi-send-name-type-registry-01

Dear WG,

I issued a new version of the name type registry draft with only typos corrections.

I believe this document, which is very simple, is ready for WGLC.

Regards,

Roque.

Begin forwarded message:

From: IETF I-D Submission Tool <idsubmission-EgrivxUAwEY@public.gmane.org>
Date: February 4, 2010 4:58:20 PM GMT+01:00
Subject: New Version Notification for draft-ietf-csi-send-name-type-registry-01


A new version of I-D, draft-ietf-csi-send-name-type-registry-01.txt has been successfuly submitted by Roque Gagliano and posted to the IETF repository.

Filename: draft-ietf-csi-send-name-type-registry
Revision: 01
Title: SEND Name Type field Registry
Creation_date: 2010-02-04
WG ID: csi
Number_of_pages: 10

Abstract:
SEcure Neighbor Discovery (SEND) defines the Name Type field in the
Trust Anchor option.  This document request to IANA the creation and
management of a registry for this field.  This document also
specifies a new Name Type field based on a certificate Subject Key
Identifier (SKI).



The IETF Secretariat.


<div>Dear WG,<div><br></div>
<div>I issued a new version of the name type registry draft with only typos corrections.</div>
<div><br></div>
<div>I believe this document, which is very simple, is ready for WGLC.</div>
<div><br></div>
<div>Regards,</div>
<div><br></div>
<div>Roque.<br><div>
<br><div>Begin forwarded message:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>
<span>From: </span><span>IETF I-D Submission Tool &lt;<a href="mailto:idsubmission@...">idsubmission@...</a>&gt;<br></span>
</div>
<div>
<span>Date: </span><span>February 4, 2010 4:58:20 PM GMT+01:00<br></span>
</div>
<div>
<span>To: </span><span><a href="mailto:roque@...">roque@...</a><br></span>
</div>
<div>
<span>Cc: </span><span><a href="mailto:suresh.krishnan@...">suresh.krishnan@...</a>,<a href="mailto:ana.kukec@...">ana.kukec@...</a><br></span>
</div>
<div>
<span>Subject: </span><span>New Version Notification for  draft-ietf-csi-send-name-type-registry-01 <br></span>
</div>
<br><div>
<br>A new version of I-D, draft-ietf-csi-send-name-type-registry-01.txt has been successfuly submitted by Roque Gagliano and posted to the IETF repository.<br><br>Filename:<span class="Apple-tab-span">	</span> draft-ietf-csi-send-name-type-registry<br>Revision:<span class="Apple-tab-span">	</span> 01<br>Title:<span class="Apple-tab-span">	</span><span class="Apple-tab-span">	</span> SEND Name Type field Registry<br>Creation_date:<span class="Apple-tab-span">	</span> 2010-02-04<br>WG ID:<span class="Apple-tab-span">	</span><span class="Apple-tab-span">	</span> csi<br>Number_of_pages: 10<br><br>Abstract:<br>SEcure Neighbor Discovery (SEND) defines the Name Type field in the<br>Trust Anchor option. &nbsp;This document request to IANA the creation and<br>management of a registry for this field. &nbsp;This document also<br>specifies a new Name Type field based on a certificate Subject Key<br>Identifier (SKI).<br><br><br><br>The IETF Secretariat.<br><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply | 0 comments |
headers
Benoit Lourdelet (blourdel | 5 Feb 2010 21:03
Picon
Favicon

1rst SeND/CGA bake-off announcement

Hello,

 

 

I would like to announce the 1rst SeND/CGA bake off to be organized the week-end

before the IETF in Anaheim.

This bake-off will be focus on interoperability and operational practice.

 

Please contact me directly asap if you plan to attend or have any questions.

 

Benoit Lourdelet

 

 

Organization information:

 -------------------------

 Dates: Friday March 19th 12pm to Saturday March 20th 6pm

 

 Location: TBD, close proximity of the Anaheim venue.

 

 Open to: any participant coming with an original implementation of SeND/CGA

 Disclosure mode: this is a typical non disclosure event, ie you'll have full

 access to your test results, and we will only publish a short summary of the

 even.

 Contact & registration: blourdel-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org

 

 What to bring: A platform to run your code (laptop, small router,...)

 Cost: none. Sponsored by Cisco.

 

 

<div>

<div class="Section1">
<span>Hello,<p></p></span><span><p>&nbsp;</p></span><span><p>&nbsp;</p></span><span>I would like to announce the 1rst SeND/CGA bake off to be organized the week-end<p></p></span><span>before the IETF in Anaheim.<p></p></span><span> <p></p></span><span>This bake-off will be focus on interoperability and operational practice. <p></p></span><span><p>&nbsp;</p></span><span>Please contact me directly asap if you plan to attend or have any questions.<p></p></span><span><p>&nbsp;</p></span><span>Benoit Lourdelet<p></p></span><span><p>&nbsp;</p></span><span><p>&nbsp;</p></span><span>Organization information:<p></p></span><span> -------------------------<p></p></span><span> <p></p></span><span>&nbsp;Dates: Friday March 19th 12pm to Saturday March 20th 6pm<p></p></span><span><p>&nbsp;</p></span><span> Location: TBD, close proximity of the Anaheim venue.<p></p></span><span><p>&nbsp;</p></span><span> Open to: any participant coming with an original implementation of SeND/CGA<p></p></span><span> <p></p></span><span>&nbsp;Disclosure mode: this is a typical non disclosure event, ie you'll have full<p></p></span><span> access to your test results, and we will only publish a short summary of the<p></p></span><span> even.<p></p></span><span> <p></p></span><span>&nbsp;Contact &amp; registration: blourdel@...<p></p></span><span><p>&nbsp;</p></span><span> What to bring: A platform to run your code (laptop, small router,...)<p></p></span><span> <p></p></span><span>&nbsp;Cost: none. Sponsored by Cisco.<p></p></span><span><p>&nbsp;</p></span>

<p class="MsoNormal"><p>&nbsp;</p></p>

</div>

</div>
Permalink | Reply | 0 comments |
headers
Tony Cheneau | 6 Feb 2010 18:06
Picon

Comments on draft-ietf-csi-hash-threat-05

Hello Ana, Suresh and Sheng,

I've read your draft and find it is in a good shape.

However, in the following text, I have a small comment:

    extensions.  For example, an attack against the IP address extension
    would enable the router to advertize the changed IP prefix range,
    although, not broader than the prefix range of the parent certificate
    in the ADD chain.

RFC 3971 does not mandate the use of IP prefix range (or address) (it is 
a "should"). Maybe you could add "if used in the original certificate".

Also, can you update the following references ?
    [sig-agility]
               Cheneau, T., Maknavicius, M., Shen, S., and M. Vanderveen,
               "Signature Algorithm Agility in the Secure Neighbor
               Discovery (SEND) Protocol",
               draft-cheneau-csi-send-sig-agility-00 (work in progress),
               October 2009.

Regards,
 	Tony
Permalink | Reply | 0 comments |
headers
Ana Kukec | 12 Feb 2010 14:51
Picon

Re: WGLC for draft-ietf-csi-hash-threat-05.txt

Hi Jean-Michel,

Thanks for the comments, they are very useful. While addressing your 
comments in the new version of the draft, i noticed your question.

Jean-Michel Combes wrote:
>    ... non-repudiation feature, while collision attacks are mainly about
>    affecting the non-repudiation feature, i.e. in the collision attack
>    against the CGA both of the CGA Parameters sets are choosen by an
>    attacker, which is not useful in the real-world scenarios.
>
> <JMC>
> "which is not useful in the real-world scenarios"
> Out of curiosity, may you explain to me why you have such a conclusion?
> <JMC>
>   

AFAIU, that conclusion is the consequence of two things:
=> CGA does is that it proves that the sender of the message is the same 
as the one from the previous message.
=> In the collision attack against CGA in SEND, the attacker itself 
produces both (colliding) CGAs and both sets of CGA Parameters sets.

This basically means that CGAs do not deal with the non-repudiation. So, 
what are the benefits of such attack? I mean, CGA and SEND did what they 
were supposed to do, no matter of circumstances.

Ana
Permalink | Reply | 0 comments |
headers
Roque Gagliano | 16 Feb 2010 16:35
Favicon

Fwd: New Version Notification for draft-ietf-csi-send-cert-02

Dear WG,

We just submitted a new version of the cert-profile draft.

It includes the comments received in Hiroshima and in the mailing list. Particularly:
- several editorial changes.
- no mention to CRL fetching.
- we add some text that a SEND certificate MUST have IPv6 address resources and MUST NOT have IPv4 or ASNs.

The only open item is to finalize the process in the PKIX WG in order for them to allocate us the EKU OIDs.

We believe this document is ready for WGLC.

Regards,

Roque.





Begin forwarded message:

From: IETF I-D Submission Tool <idsubmission-EgrivxUAwEY@public.gmane.org>
Date: February 16, 2010 4:26:37 PM GMT+01:00
Subject: New Version Notification for draft-ietf-csi-send-cert-02


A new version of I-D, draft-ietf-csi-send-cert-02.txt has been successfuly submitted by Roque Gagliano and posted to the IETF repository.

Filename: draft-ietf-csi-send-cert
Revision: 02
Title: Certificate profile and certificate management for SEND
Creation_date: 2010-02-16
WG ID: csi
Number_of_pages: 19

Abstract:
SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for
performing router authorization.  This document specifies a
certificate profile for SEND based on Resource Certificates along
with extended key usage values required for SEND.



The IETF Secretariat.


<div>Dear WG,<div><br></div>
<div>We just submitted a new version of the cert-profile draft.</div>
<div><br></div>
<div>It includes the comments received in Hiroshima and in the mailing list. Particularly:</div>
<div>
<span class="Apple-tab-span">	</span>- several editorial changes.</div>
<div>
<span class="Apple-tab-span">	</span>- no mention to CRL fetching.</div>
<div>
<span class="Apple-tab-span">	</span>- we add some text that a SEND certificate MUST have IPv6 address resources and MUST NOT have IPv4 or ASNs.</div>
<div><br></div>
<div>The only open item is to finalize the process in the PKIX WG in order for them to allocate us the EKU OIDs.</div>
<div><br></div>
<div>We believe this document is ready for WGLC.</div>
<div><br></div>
<div>Regards,</div>
<div><br></div>
<div>Roque.</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>
<br><div>
<br><div>Begin forwarded message:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>
<span>From: </span><span>IETF I-D Submission Tool &lt;<a href="mailto:idsubmission@...">idsubmission@...</a>&gt;<br></span>
</div>
<div>
<span>Date: </span><span>February 16, 2010 4:26:37 PM GMT+01:00<br></span>
</div>
<div>
<span>To: </span><span><a href="mailto:roque@...">roque@...</a><br></span>
</div>
<div>
<span>Cc: </span><span><a href="mailto:suresh.krishnan@...">suresh.krishnan@...</a>,<a href="mailto:ana.kukec@...">ana.kukec@...</a><br></span>
</div>
<div>
<span>Subject: </span><span>New Version Notification for draft-ietf-csi-send-cert-02 <br></span>
</div>
<br><div>
<br>A new version of I-D, draft-ietf-csi-send-cert-02.txt has been successfuly submitted by Roque Gagliano and posted to the IETF repository.<br><br>Filename:<span class="Apple-tab-span">	</span> draft-ietf-csi-send-cert<br>Revision:<span class="Apple-tab-span">	</span> 02<br>Title:<span class="Apple-tab-span">	</span><span class="Apple-tab-span">	</span> Certificate profile and certificate management for SEND<br>Creation_date:<span class="Apple-tab-span">	</span> 2010-02-16<br>WG ID:<span class="Apple-tab-span">	</span><span class="Apple-tab-span">	</span> csi<br>Number_of_pages: 19<br><br>Abstract:<br>SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for<br>performing router authorization. &nbsp;This document specifies a<br>certificate profile for SEND based on Resource Certificates along<br>with extended key usage values required for SEND.<br><br><br><br>The IETF Secretariat.<br><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply | 0 comments |
headers
marcelo bagnulo braun | 16 Feb 2010 16:44
Picon

WGLC for draft-ietf-csi-send-cert-01.txt and for draft-ietf-csi-send-name-type-registry-01.txt

Hi,

This note issues the WGLC for two related documents:

draft-ietf-csi-send-cert-01.txt and
draft-ietf-csi-send-name-type-registry-01.txt

Please review the documents and send comments before the 2nd of march.

For you convenience, the docs can be found at:

http://www.ietf.org/id/draft-ietf-csi-send-name-type-registry-01.txt
http://www.ietf.org/id/draft-ietf-csi-send-cert-01.txt

Regards, marcelo
Permalink | Reply | 2 comments |
headers
Roque Gagliano | 16 Feb 2010 17:03
Favicon

Re: WGLC for draft-ietf-csi-send-cert-01.txt and for draft-ietf-csi-send-name-type-registry-01.txt

Marcelo,

I believe there is a typo in your email.

The new version of the cert profile document is the 02 and I believe it is the one that should go through WGLC:
http://www.ietf.org/id/draft-ietf-csi-send-cert-02.txt

Regards,
Roque,

On Feb 16, 2010, at 4:44 PM, marcelo bagnulo braun wrote:

> Hi,
> 
> This note issues the WGLC for two related documents:
> 
> draft-ietf-csi-send-cert-01.txt and
> draft-ietf-csi-send-name-type-registry-01.txt
> 
> Please review the documents and send comments before the 2nd of march.
> 
> For you convenience, the docs can be found at:
> 
> http://www.ietf.org/id/draft-ietf-csi-send-name-type-registry-01.txt
> http://www.ietf.org/id/draft-ietf-csi-send-cert-01.txt
> 
> Regards, marcelo
> 
> _______________________________________________
> CGA-EXT mailing list
> CGA-EXT@...
> https://www.ietf.org/mailman/listinfo/cga-ext
Permalink | Reply | 1 comment |
headers
marcelo bagnulo braun | 16 Feb 2010 17:08
Picon

WGLC for draft-ietf-csi-send-cert-02.txt and for draft-ietf-csi-send-name-type-registry-01.txt

Right, sorry about that.

Correction:

This note issues the WGLC for two related documents:

draft-ietf-csi-send-cert-02.txt and
draft-ietf-csi-send-name-type-registry-01.txt

Please review the documents and send comments before the 2nd of march.

For you convenience, the docs can be found at:

http://www.ietf.org/id/draft-ietf-csi-send-name-type-registry-01.txt
http://www.ietf.org/id/draft-ietf-csi-send-cert-02.txt

Regards, marcelo

El 16/02/10 17:03, Roque Gagliano escribió:
> Marcelo,
>
> I believe there is a typo in your email.
>
> The new version of the cert profile document is the 02 and I believe it is the one that should go through WGLC:
> http://www.ietf.org/id/draft-ietf-csi-send-cert-02.txt
>
> Regards,
> Roque,
>
>
> On Feb 16, 2010, at 4:44 PM, marcelo bagnulo braun wrote:
>
>    
>> Hi,
>>
>> This note issues the WGLC for two related documents:
>>
>> draft-ietf-csi-send-cert-01.txt and
>> draft-ietf-csi-send-name-type-registry-01.txt
>>
>> Please review the documents and send comments before the 2nd of march.
>>
>> For you convenience, the docs can be found at:
>>
>> http://www.ietf.org/id/draft-ietf-csi-send-name-type-registry-01.txt
>> http://www.ietf.org/id/draft-ietf-csi-send-cert-01.txt
>>
>> Regards, marcelo
>>
>> _______________________________________________
>> CGA-EXT mailing list
>> CGA-EXT@...
>> https://www.ietf.org/mailman/listinfo/cga-ext
>>      
>
>
Permalink | Reply | 0 comments |
headers
marcelo bagnulo braun | 22 Feb 2010 19:30
Picon

call for presentations for the CSI meeting in anaheim

Please, drop me a note if you want present something.

Regards, marcelo
Permalink | Reply | 0 comments |
headers
Tony Cheneau | 1 Mar 2010 14:27
Picon

Comments on draft-ietf-csi-send-name-type-registry-01

Hello Ana, Rogue and Suresh,

I read the draft draft-ietf-csi-send-name-type-registry-01 and I have the 
following comments:

Section 3 title is "SEND SKI trust anchor Name Type field.", I think it 
should be "SEND SKI trust anchor option Name Type field".

In section 3.1,
"   If the router is unable to find a path to the requested anchor, it
    SHOULD send an advertisement without any certificate.  In this case,
    the router SHOULD include the TA options that were solicited."
This is already stated in RFC 3971 (with the same terms). Is there any 
valid reason to add it there ? It makes it sound like a new "processing 
rule".

IMHO, the document is in a good shape.

Regards,
 	Tony
Permalink | Reply | 1 comment |

Gmane