Tony Cheneau escribió:
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.
mmm, but the problem is that one of the motivations for all this cryptp
agility work is that we will have some nodes with very limited resources
and that they cannot execute RSA much less they will be able to execute
multiple algorithms. I don't know if we can assume that they can
validate using multiple algorithms though.... (i.e. don't know if they
are H1 or H2)
So, i think we will have at least 3 type of nodes:
We will have cureent send nodes, that are H1 for hosts and R1 for routers
We will have new types of nodes that will only support one crypto suite
but will not be RSA (these are the limited devices). I don't know if we
will have R1 of these too, or will only be hosts...
We will also then have some normal nodes will be H1, H2, H3 or H4 or R1
or R2 or R3 is up to us to decide.
In other words, H1 are a reality, then new resource limited nodes will
be either H1 or H2 (not clear to me)
Then we need to understnad if there is a case for the other options, H3
or H4 or we cna simply rule out some of these...
H4 type are only required during a transition phase, once a specific
crypto suite is adopted, they will act as H2 type of nodes.
not really cause they are likely to be able to interact with multiple
types of H1 nodes. I mean an H$ node not only can validate multiple H1
nodes, but its credentials can be validated by different H1 nodes, which
is soemthing that a H2 node cannot provide
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 think i agree we could rule out H3, but i woudl preffer to keep in the
dicussion for a while, to see if someone can come up with a reason for that
please note that i am not sure we can rule out R3 though...
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 ?
R2 means that the router has a single certificate, but himself is able
to validate multiple crypto suites. That would acually make sense to
me... i mean, i am not sure we will be able to get people to deploy
multiple certificates in parallel....
R3 seems more fitted. Routers being more powerful.
The problem with R3 is that you need multiple certs per router and i am
not sure how realistic that is from a deployment perspective...
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.
As i mentioned in my reply to the other email, you should note that a
node can support a set of crypto suites that it can validate and a
different set of crypto suites that it has credentials.
I mean, for instance a node may have only a RSA CGA but it is able to
validate both ECC and RSA
So, how do you express the difference?
you need to express it?
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.
right, but it can resend signing it with a different key if itfinds out
that the other node supports a different algorithm, right?
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.
one more question, how does hash agility fits into all this?
regards, marcelo
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
