Hi,
Comments inline.
On Mon, 15 Dec 2008, marcelo bagnulo braun wrote:
[...]
So, first we have identified the main elements that use the algortihms and
they are:
- the certificates contain both a public key and use a hash
- the SEND protocol itself sends the RSA signature option and use hash
algorithm.
- the CGA includes a public key and uses a hash algorithm
Next, we should agree of what level of backward compatibility we aim for.
First, it should be noted that SEND has two different behaviours. Some
messages are in the request response format and another ones are just a
message (like the periodic RADV).
Second, it should be noted that the public key and the hash algorithm are
tightly coupled to the CGA and also to the certificates.
So, types of nodes and elements can we have in a scenario with crypto
agility?
for hosts
H1- we can have a host that only supports crypto suite 1 and has no
capabilities of doing any operations of algorithms that are not part of this
crypto suite (e.g. the node supports only RSA and SHA1 and it is not capable
of verifying ECC nor MD5 nor any other algorithm). this node has generated
its own CGA with this suite of algorithms.
H2- we can have a host that supports multiple crypto algorithm suite but has
only one CGA, generated with one of the crypto suites. So, in this case, the
node has generated its CGA with crypto suite1, but he can also verify CGAs,
and certs and signatures using other crypto suites.
H3- we then can have a host that supports multiple crypto suites and that he
has generated as many different CGAs as crypto suites it supports.
H4- we can also have a node that supports multiple crypto suites and that he
has generated one CGA that includes multiple public keys, one per public key
algorithm it supports but using a single hash function though.
for routers
R1- a router with a single certificate generated with a given crypto suite.
The router supports only the crypto suite that was used for generating the
cert and it cannot perform crypto operations for other algorithms
R2- a router with a single cert generated with a given crypto suite, but that
it is capable of validating other crypto suites.
R3- a router with multiple certs with different crypt suites. The router
supports multiple crypto suites and can validate the different suites.
Hosts following current SEND specs are essentially H1 type and routers are R1
type, since only RSA and SHA1 is supported
One question we can ask ourselves is what type of hosts and routers will be
accetable under the crypto agility scheme?
I personally think we should have H4 type and R3 type that would provides
the wider compatibility with older nodes. This is the type of
hosts/routers we define in our draft.
H4 type are only required during a transition phase, once a specific
crypto suite is adopted, they will act as H2 type of nodes.
We can rule out H3 type as it is really hard to bind two CGA addresses
together (you have to prove you know the two secret, and sometime, you
can't prove it to a node that don't support the correct crypto suite).
I am not sure R2 will work. Only one certificate, validating multiple
crypto suite: this involves multiple keys, right? How do we link the
certificate and the multiple keys ?
R3 seems more fitted. Routers being more powerful.
Then, what type of interop can we expect?
One option is to have a type H1 host supporting crypto suite 1 that tries to
communicate with another host or router of type H1/R1 but that uses a
different crypto suite. Of course, in this case, they won't be able to use
SEND for the communication and they will fall back to normal ND. I guess that
what is needed in this is a mean to allow the hosts and routers to tell that
the crypto suite is different than the one they support. I understand that is
already available in SEND
Falling back is a good alternative when there is no other choice, for the
RFC3971 nodes.
Another option is to have a host of type H2 communicating with a router of
type R2. even though they have used differnet crypt suites to generate their
CGAs and certs, they support each other crypto suites. In this case, if they
can identify the crypto suite used by each other, they should be able to
communicate. If the crypt suites are not overlapping, i guess they need to
fall back to plain ND.
Right.
Another option is that we have two hosts of type H3 communicating. this is
complicated cause they need to find the right coupling between the different
CGAs they have. It is probbaly possible, but it probably involves some form
of probing.
In our draft, in the best case scenario (which I believe would be the more
common), we have 2 messages (as many as in SEND), when things goes wrong,
we have 3 messages.
Basically, good case is just like:
- Node A supports Type 1 and Type 2 crypto suite (in this preference
order)
- Node B supports Type 1 and Type 3 crypto suite (in this preference
order)
- Node A send a NS signed with Type 1 to Node B. The Supported Signature
Algorithm option indicates which Type of crypto suite Node A supports.
- Node B verify the signature, everything is OK, it builds up a NA signing
with Node A preferred crypto suite (First crypto suite to appear in the
list inside the Supported Signature Option): Type 1.
- Node A receives the message and checks the signature.
Worst case:
- Node A supports Type 2 and Type 1 crypto suite (in this preference
order)
- Node B supports Type 3 and Type 1 crypto suite (in this preference
order)
- Node A send a NS signed with Type 2 to Node B. The Supported Signature
Algorithm option indicates which Type of crypto suite Node A supports.
- Node B try to verify the signature: it doesn't support Type 2. It
checks the crypto suite available to communicate with A with the help
of the Supported Signature Algorithm option. It chooses Type 1. It
signs the NA with Type 1, add to the message its Supported Signature
Option that indicate that the initial message need to be resent. This
message is sent.
- Node A receives the message and checks the signature. The Supported
Signature Option indicates that node A has to has to send again the
informations. The option indicates which crypto suite is available:
Type 1. It re-sends a NS or maybe a NA with the Type 1 crypto suite.
Another option is for a host of type H4 communicate with a host of type H1.
In this case, if one of the public keys used by the H4 host is supported by
the H1 host, the communication could be possible, but hte problem is how to
choose which is the right public key to use to sign the messages.
Not a trivial problem. If a H4 type node send a message to a node he
knows nothing of, after a timeout delay, it may try to resent the packet
using a H1 type mechanism. Basically, here, it means that we will sign
using with a RSA signature using a RSA Public Key located in the Public
Key field of the CGA PDS.
I think the first thing we need to do is to define whoch of the host and
routers types we are going to support and then define what inerop modes are
we going to allow.
I agree.
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
