[CGA-EXT] about draft-cheneau-send-sig-agility-00.txt
marcelo bagnulo braun <marcelo@it.uc3m.es> Sun, 15 March 2009 15:39 UTC
Return-Path: <marcelo@it.uc3m.es>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AABA3A67AE for <cga-ext@core3.amsl.com>; Sun, 15 Mar 2009 08:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.43
X-Spam-Level:
X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UymUrx50FTPl for <cga-ext@core3.amsl.com>; Sun, 15 Mar 2009 08:38:59 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BFE533A63EC for <cga-ext@ietf.org>; Sun, 15 Mar 2009 08:38:58 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (157.pool85-53-154.dynamic.orange.es [85.53.154.157]) by smtp01.uc3m.es (Postfix) with ESMTP id BA1F6B86C7A for <cga-ext@ietf.org>; Sun, 15 Mar 2009 16:39:36 +0100 (CET)
Message-ID: <49BD2138.90906@it.uc3m.es>
Date: Sun, 15 Mar 2009 16:39:36 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: cga-ext@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16522.000
Subject: [CGA-EXT] about draft-cheneau-send-sig-agility-00.txt
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Mar 2009 15:39:00 -0000
Hi, I think this is doing very good progress. Still i am not sure i fully undersntad how this approach would work in the different cases. Some comments below... 1. Introduction Cryptographically Generated Addresses (CGA) [RFC3972] have been designed primarily for securing Neighbor Discovery [RFC3971]. I wouldn't state it this way. they were designed by the send wg, but their use for mobility was proposed in the same timeframe and they are also used for multihoming... so i would suggest to rephrase this. At the time when they were specified, CGAs allowed only one signing algorithm, namely RSA. They still only allow a single PK algorithm I am not sure i like the signing algorithm phrasing... i mean you need botht he PK algorithm and the hash algorithm to produce a signature, right? so it is not clear which one you are referring to I would suggest dropping both these initial sentences... It is well known that the RSA signature generation and verification is computationally expensive. I guess this sentence in the abstract doesn't make much sense.... i mean compared to what? for what type of devices? The usage scenarios associated with neighbor discovery have recently been extended to include environments with mobile or nomadic nodes. Many of these nodes have limited battery power and computing resources. Therefore, heavy public key signing algorithms like RSA are not feasible to support on such constrained nodes. Fortunately, more lightweight yet secure signing algorithms do exist and have been standardized, e.g. Elliptic Curve based algorithms. this paragraph makes more sense to me (i would still change the signing algorithm for pk algorithm though, in all the document i mean) I would suggest dropping all the first paragraph and start directly with this one The aim of this memo is to outline options for allowing public key signing algorithm agility for nodes configured to perform secure neighbor discovery operations when attaching to a new link. why is this restricted to the operation on a new link? i mean, i guess this also applies to the operations that a node performs after it has been attached to the link for a long time... 2.1.1. Classification of SEND nodes At the time of this writing, there are no known large-scale or even small-scale deployments of [RFC3971]-compatible devices. However, in the interest of caution, we assume that there exist nodes that support only the RSA algorithm and that are configured to perform secure neighbor discovery when attaching to a new link. same comment here.... they also do send operations when they have been long time attached to the link, rephrase Type H4 host: A host that supports multiple signature algorithms and has multiple CGAs, each of which is associated with a single key of one supported algorithm. For simplicity, we do not consider hosts that have multiple CGAs, one or more of which are generated from multiple public keys. A node MUST select and settle on one CGA when building a trust relationship with another device via SeND (more below). It is not obvious to me what this last sentence means... Type R1 router: A router that only supports one type of signature algorithm and has a CGA and Certificate with a public key of this algorithm. Such routers are expected to be commonplace, as compliance with [RFC3971] suffices for them. Not sure what you mean by this last sentence I mean, current routers will be more restrcited than this, since they will use only RSA, right? Type R3 router: A router that supports multiple types of signature algorithms and has multiple CGAs and Certificates with public key of several different algorithm types. This type of router can sign and verify signatures of multiple types. Such routers may not be attractive to build and deploy due to increased requirements on its resources. Moreover using multiple CGAs (with no bindings) may make that router appear as having multiple identities. Type R4 router: A router that supports multiple types of signature algorithms and has one CGA composed of multiple Publics Keys and multiple certificates containing each a Public Key. why did you switched router 3 and router 4 with respect to host3 and host 4? this is confusing. I think you should switch them so router 4 is the one with multiple CGAs moreover, it is weird that you leave the host with multiple CGAs out of the analysis but you keep a router with multiple CGAs as part of the analysis... or you don't? If you don't consider routers with multiple CGAs with an additional comment on router r3 It may make sense to have one of such routers, i guess, if a given interface is expected to handle one type of devices and a different interface a different type of devices. For instnace a wireless interface may want to use ECC while a wired interface may want to use RSA for backward compatibility. Even can be the case for the same interface. So while i may agree that for a host this configuration doesn't seem attractive, maybe for a router it is... 2.1.2. Principal Scenarios Based on the discussion above, a SEND agility solution should at least properly deal with the communication between devices of type H1, H2, H3, R1 and R2. I am not sure why do you think R4 is not relevant...I mean, having a router with multiple PK seems a good transition approach to me... An H1 or R1 node interacting with an H2 or R2 node: i.e., a node supporting only RSA (for example, an old non-agility node which only supports RFC3971) and a node supporting both RSA and ECDSA (or other new algorithms). These two nodes must be able to perform secure neighbor discovery. What do you mean they must be able to preform SEND? I mean, i find hard to see how the node H1 will be able to validate a NADV msg from H2 using a different pk algorithm. I think you need to be much more precise with what you mean here A node of any type (H1, H2, H3, R1, R2, R3 or R4) interacting with another node, their algorithms differ but there is a 3rd party willing/able to help: this is an optional solution applicable to the previous scenario, where two nodes that support SEND but do not have any signature algorithms in common can talk through a third party (router). In this case they should be able to perform facilitated secure neighbor discovery. I am not sure what you have in mind for this,,, hopefully it will be clearer later on but certainly seems to be drifting from the SEND model to me... An H2, H3 or R2 node interacting with another H2, H3, or R2 node: e.g., two nodes that support at least two signature algorithms in common (one of which is likely preferred over the other), will be able to perform secure neighbor discovery with any of the two algorithms. what about the scenario where they have one algorithm in common? wouldn't this be a common case as well? in 3. Supported Signature Algorithm Option it became apparetnt o me that you were actually talking about a crypto suite to support both pk algorithm and hash algorithm agility. I think is the way to go, but the document is very opaque about this. This should be made clear way earlier and a referecne tot he ahs threat analysis in needed, in order to motivate the hash agility. Signature Algorithm A one-octet long field indicating a signature algorithm that is supported by the node, this support implies at least ability to verify signatures of this PK algorithm. The first leftmost bit, bit 0, if set to 0, indicates that the emitter is able to perform signature checks only (i.e. no signature generation with this type on signature algorithm). If this bit is set to 1, it indicates that the emitter has a public key of this type and can generate signatures. Bit 1 and 2 are reserved. Bit 3 to 7 are named Signature Type Identifier subfield and encode the signature algorithm identifier. This signature algorithm identifier binds a Public Key algorithm with an hash algorithm. Default values for the Signature Type Identifier subfield defined in this document are: * Value 1 is RSA/SHA-256 * Value 2 is ECDSA/SHA-256 * Value 0 is reserved for future use. I am not sure i understand how this works. You will include one byte per PK alorithm supported? and within it you will specify the hash algorithm supported? This is not clear to me... 5. Basic negotiation 5.1. Overview Two nodes sharing a common Signing Algorithm must be able to securely communicate. Below is an example of such a message flow. Node A Node B NS {CGA option, RSA Signature option. Supported-Signature-Algo option (RSA, ECC, R=0)} --------> NA {CGA option, ECC Signature option Supported-Signature-Algo option <-------- (ECC, R=1)} NA {CGA option, ECC Signature option. Supported-Signature-Algo option (RSA, ECC, R=0)} --------> IPv6 traffic <-------> IPv6 traffic Basic Negotiation- Case 1 Two questions: why does the node B sends the R set, when there was nothing to validate in the NS msg? Second, why does the node A sends a NA as a reply to a NA msg? i don't think this is the normal ND behaviour, right? I think we need to understand how we want this to behave in the different scenarios you have described above. I think it is great that you describe this for these two cases, but i think more thorough analysis of how the different type of hosts, routers and the different ND msgs work is needed. I mean, i would like to understnad how every different host type interacts with every other host type and router type for every different ND msg exchange. I know this is a lot of work, but unless we understnad this, we wont be able to see if this works properly 6. Router-as-a-notary function This optional functionality enhances backward compatibility by introducing a new entity. Here, the entity named "notary" serves to certify the authenticity of a node's message. This improves communication when two nodes have a disjoint set of supported Signature Algorithm types and still require secure neighbor discovery. I really not sure if we want to go this path... 8. IANA Considerations This document requests IANA to allocate types for the two new notary ICMP messages. I understnad you are creating a registry for the signature algorithms used, so this belongs to the iana considerations section.
- [CGA-EXT] about draft-cheneau-send-sig-agility-00… marcelo bagnulo braun
- Re: [CGA-EXT] about draft-cheneau-send-sig-agilit… Tony Cheneau