2 Nov 2008 11:26
draft meeting agenda
Hi, We have posted a draft agenda for the next meeting http://www.ietf.org/proceedings/08nov/agenda/csi.txt Please let us know if something needs to be changed Regards, marcelo
Hi, We have posted a draft agenda for the next meeting http://www.ietf.org/proceedings/08nov/agenda/csi.txt Please let us know if something needs to be changed Regards, marcelo
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-01.txt Pages : 13 Date : 2008-11-03 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 SHA-1 [sha-1] hash algorithm and PKIX certificates [rfc3280] 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-csi-hash-threat-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
_______________________________________________(Continue reading)
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 : Secure Proxy ND Support for SEND Author(s) : S. Krishnan, J. Laganier, M. Bonola Filename : draft-ietf-csi-proxy-send-00.txt Pages : 22 Date : 2008-11-4 Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling initiated by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND, the Secure Proxy ND Support for SEND. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-csi-proxy-send-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.(Continue reading)
A new draft "DHCPv6 and CGA Interaction: Problem Statement" draft-jiang-csi-dhcpv6-cga-ps-00.txt has been submitted to CSI WG. Your comments are welcomed. Best regards, Sheng JIANG, Ph.D. IP Research Department, Networking Research Department, Network Product Line, Huawei Technologies Co. Ltd. > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : DHCPv6 and CGA Interaction: Problem Statement > Author(s) : S. Jiang, S. Shen > Filename : draft-jiang-csi-dhcpv6-cga-ps-00.txt > Pages : 7 > Date : 2008-10-27 > > This document presents a problem statement for the possible > interactions between DHCPv6 and CGA. Firstly, in order to support > the > co-existing scenarios of DHCPv6 and CGA, Some operations are > clarified for the interaction of DHCPv6 servers and CGA-associated > hosts. Then, some extended scenarios are also discussed in this > document, including using CGAs in DHCPv6 operations to enhance the > security features and using DHCPv6 to serve the CGA generation. >(Continue reading)
Hello CSI people,
We (Michaela, Sean, Maryline and myself) are currently working on the PKI
agility for SEND. This will offer, for example, support of ECC based CGA
(see draft draft-shen-csi-ecc-01) to SEND. Our work is primarily focused
on a negotiation algorithm for nodes supporting different PKI algorithms.
We introduce a new ICMP error message called "ICMP Unsupported PKI" and an
option to this ICMP message called "supported PKI option". This addition
allows use to have a basic negotiation mechanism that permit
interoperability in most cases.
For scenario where nodes aren't sharing any common PKI algorithm, we then
introduce a new optional entity called "notary" (functionality assumed by
the router for now).
This all will be part of work that Sean will present next Wednesday during
the CSI meeting.
With this mail, you will have an email attachment that contains more
details on the basic ideas to permit PKI agility.
Thanks you in advance for all your review and comments.
Best regards,
Tony Cheneau
1. PKI agility basic support: The PKI agility basic support implies: - Two IPv6 nodes supporting at least plain ND (RFC 4861) must be able to perform neighbor discovery(Continue reading)
RSS Feed8 | |
|---|---|
1 | |
1 | |
1 | |
1 | |
11 | |
1 | |
6 | |
4 | |
9 | |
16 | |
19 | |
9 | |
7 | |
21 | |
27 | |
21 | |
33 | |
4 | |
8 | |
26 | |
1 | |
3 | |
21 | |
4 | |
16 | |
42 | |
6 | |
6 | |
22 | |
1 | |
30 | |
25 | |
12 | |
2 | |
1 |