Subject: [CGA-EXT] about draft-cheneau-send-sig-agility-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 15 Mar 2009 16:39:36 +0100

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.

---

From: Tony Cheneau <[email-masked]>
Date: Tue, 17 Mar 2009 16:53:47 +0100 (CET)

Hello Marcelo,

Thanks for your review.

Comments inline:

On Sun, 15 Mar 2009, marcelo bagnulo braun wrote:

> 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
> 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
NIST refers to these algorithms we are writing about as "digital signature
algorithms" (see FIPS 186-2). The digital signature algorithm includes a hash
algorithm. So we will replace "signing" by "digital signature" to be correct.

> I would suggest dropping all the first paragraph and start directly with this 
> one
We will rephrase it in the next version of the draft.

> 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...
This is only a poor phrasing. Will remove the "attach ..." part as it is
only confusing.

[...]

> It is not obvious to me what this last sentence means...
We will rephrase it. Basically, it means that the node having multiple
separate single PK CGAs, another node may start a ND process with a CGA based
on a signature algorithm it can't verify, while the very same node possess a
CGA with a signature algorithm which can be verified. The issue is that H4
nodes will try to bind multiples CGAs to the same owner node, which is not
feasible when some of the Digital Signature Algorithm associated with CGAs can
not be verified.

> I mean, current routers will be more restrcited than this, since they will 
> use only RSA, right?
We meant, that RFC3971 nodes only handle one type of PK per CGA and per
certificate. They fit in R1 category. Then, they are more likely to be
deployed that other type of nodes described in this draft. Hence, they
are expected to be "commonplace". That said, we will rephrase it (as it
is not really important for the reader), but RFC3971 nodes definitely
fit in R1 category.

> 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
True. We will switch them back in the next version of the draft.

> 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
We are not considering the multi-CGA hosts, as they complicate the situation
too much for this stage of the draft. Will either remove the multi-CGA router
description or add a similar one for hosts, but it will be irrelevant for the
rest of the draft anyway.
I'd say that the multiple CGA routers don't have the same identity problem as
host may have with multiple CGA as their identity(ies) is related to their
certificate(s).

> 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...
Indeed.

> 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...
R4 is a subset of R3 capabilities. That's why we ruled out R4 to focus
on R3. Also, note the wording, we said "at least", meaning that R4 could be
used. We will add it in the next versions.

> 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
The "must" we wrote should be a "may" (it will be corrected).  There are cases
when this is possible, and other cases when the ND operation will only be
successful at one of the nodes, the one able to verify the signature. These
cases we have shown in the slides that we prepared for the WG meeting.

>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...
This is basically a reference to the router-as-a-notary part. This is drifting
from the model, indeed. However, router would need a certificate to be trusted
as notaries (the same way as they currently need a certificate to be trusted
to advertise a prefix), no extra material needed. This will also relax
requirement on the hosts, which is the whole purpose of the draft.

> what about the scenario where they have one algorithm in common? wouldn't 
> this be a common case as well?
Indeed, we will simplify this point. The idea is that when two nodes share two
algorithms in common, they may have a "preferred one" (e.g. one that uses less
power, etc.).

> 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.
Will do.

> You will include one byte per PK alorithm supported?
Yes.
> and within it you will specify the hash algorithm supported?
Yes. According to NIST, a "digital signature algorithm" includes the
definition of a message digest. Here, we specify PK algorithm + Hash algorithm
to perform the digital signature.  We could have chosen to separate both,
saying that we support ECC, RSA in one side and SHA-1, SHA-256 on the other
side. But it may not be desirable to authorize ECC/SHA-1 while you may allow
ECC/SHA-256 and RSA/SHA-1 (just an example).

> why does the node B sends the R set, when there was nothing to validate in 
> the NS msg?
Picture didn't showed it, but we supposed that the A's NS message contained
the Source Link-Layer Address Option (that needs to be protected in order to
update the Neighbor Cache). Here, B basically indicates to A that he wasn't
able to check his signature, so he won't update this cache. Hence A sending
it's Link-Layer address in a other message.

> 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 am not sure in this special context. When A receives the B's NA message with
the SSA option indicating that its last message couldn't be verified, A still
have to make B node learn it's Link-Layer Address. I don't think we are still
in the "classic" ND or even in SEND as both party are supposed to understand
each other.

> 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
We are aware of this "lack". But in the interest of getting the main idea
out, we chose to leave out an exhaustive list of H* to H* interactions. We
will add a more thorough analysis in the next versions when H*, R* nodes will
be completely defined.

> I really not sure if we want to go this path...
I don't know if many people will agree here, but this (optional)
mechanism will help in transitional effort (current and future ones,
when moving to a main Signature Algorithm/Public Key to another one) and
also in heterogeneous networks. I think it's worth developing the idea a
bit in the next versions and see if we reach a consensus among the WG.

> I understnad you are creating a registry for the signature algorithms used, 
> so this belongs to the iana considerations section.
Will do.

Thanks for your comments.

Regards,
 	Tony Cheneau