Hi again,
Comments inline.
On Mon, 15 Dec 2008, marcelo bagnulo braun wrote:
[...]
> 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...
Hum, I indeed wasn't clear. To me, a H4 node is a node that is capable
of handling multiple cryto suites and have multiple public keys linked
to its CGA. It is only "capable of", meaning that it can also choose to
use only one crypto suite, hence one public key. So the lightweight node
are only showing capabilities of H1 node + negotiation support, while
having the same set of capabilities as H4 type nodes.
Simply put, if we specify the behavior of H4 type nodes, by using a
small subset of their capabilities, we can emulate H2 and H1 type nodes.
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
This is true. But in a wide deployment of similar nodes, it may be more
preferable to only carry one type of Public Key in order to save the
bandwidth. We should at least allow this behavior.
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...
OK.
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....
That makes sense. I will read more on certificate to understand how we
can do that. For now, I'm wondering how a node can check a certificate
if it doesn't support the Signature Algorithm of the certificate.
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...
Right.
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?
Yes, good comment. We need to express in some specific cases. Still, we
can use the same "Supported Signature Algorithm" option and use a flag
to differentiate between crypto suite it uses to build addresses and
others.
[...]
> 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?
Yes. It means that the H4 type node will be able to emulate the behavior of a H1
type node if it supports the same cryto suite. In our current solution,
we use the Public Key field of the CGA PDS to store the Public Key that
can be used with H1 type nodes (e.g. store a RSA key to communicate with
RFC3971 nodes).
[...]
one more question, how does hash agility fits into all this?
We are pretty independent of this work right now, but it is clear that
the security level of a CGA is related to the hash algorithm and to the
length of its Public Key(s).
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
