marcelo bagnulo braun | 5 Nov 11:22 2009
Picon

slides, notetakers.

Hi,

I would ask people presenting if they could send me the slides by monday 
1300hrs.
If someone can volunteer for taking notes and jabber, it would be 
appreciated.

Regards, marcelo

Internet-Drafts | 9 Nov 07:45 2009
Picon

I-D Action:draft-ietf-csi-hash-threat-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Cga & Send maIntenance Working Group of the IETF.

	Title           : SeND Hash Threat Analysis
	Author(s)       : A. Kukec, et al.
	Filename        : draft-ietf-csi-hash-threat-05.txt
	Pages           : 12
	Date            : 2009-11-08

This document analysis the use of hashes in SeND, possible threats
and the impact of recent attacks on hash functions used by SeND.
Current SeND specification [rfc3971] uses the SHA-1 [sha-1] hash
algorithm and PKIX certificates [rfc5280] and does not provide
support for the hash algorithm agility.  The purpose of the document
is to provide analysis of possible hash threats and to decide how to
encode the hash agility support in SeND.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
(Continue reading)

Roque Gagliano | 11 Nov 10:54 2009
Picon

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

Behcet Sarikaya | 11 Nov 14:02 2009
Picon

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)

Behcet Sarikaya | 12 Nov 08:41 2009
Picon

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)

marcelo bagnulo braun | 18 Nov 10:56 2009
Picon

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-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 
(Continue reading)

marcelo bagnulo braun | 18 Nov 10:57 2009
Picon

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

Roque Gagliano | 18 Nov 15:05 2009
Picon

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)

The IESG | 18 Nov 15:06 2009
Picon

Last Call: draft-ietf-csi-sndp-prob (Securing Neighbor Discovery Proxy Problem Statement) to Informational RFC

The IESG has received a request from the Cga & Send maIntenance WG (csi) 
to consider the following document:

- 'Securing Neighbor Discovery Proxy Problem Statement '
   <draft-ietf-csi-sndp-prob-03.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2009-12-02. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-csi-sndp-prob-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17791&rfc_flag=0

Tony Cheneau | 18 Nov 17:15 2009
Picon

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)


Gmane