Hi,
We are chartered to provide crypto agility support for SeND and CGAs.
That include both public key algorithm and hash algorithm agility.
So far, only CGAs have hash algorithm agility defined and we have some
drafts covering the remaining pieces.
Now, i guess it makes sense to look at the big picture of how to provide
agility for all these and draw some big lines about how this should be
supported.
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?
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
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.
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.
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.
Another option is for a host of type H3 to communicate with a host of
type H1. In this case, is similar to the one of two hosts of type H3,
and the problem is how to find the right CGA to use.
So, there are many other combinations.
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.
Regards, marcelo
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
