Tony Cheneau escribió:
We also defined a way for the node to support multiple Public Keys
as a
transition mechanism.
For this, we use the CGA PDS extension field and define (in a separate
draft) the structure of the extension. It basically looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~ Public Key ~
| |
+ +-+-+-+- - - - - - - - -+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mmm, maybe it would be better to define a generic public key
extnesion and define subtypes for the different algorithms?
seems cleaner to me
The Public Key would be recognize by the Algorithm Identifier as the PK
is a DER encoded ASN.1 structure of the type SubjectPublicKeyInfo. I
don't think we might need another kind of identifier.
right
right.. have you made some numbers about how many public keys can you
include in a normal ND messgae? that should be included in the draft,
to have a clear picture about this (it is not the same if we can
include 1 and a half keys than if we can include 10 keys...)
We don't have any theoretical number yet. We sure will have to evaluate
this.
We still can approximate, I have a capture of a node configured
to use a 1024-bit RSA PK. Starting from the IP layer, the packet weight
440 bytes. The CGA option is 192 bytes long and the RSA signature option
is 152 bytes long. These two sizes are of course depending of the size
of the RSA key.
As a remainder, IPv6 requires MTU to be at least 1280 bytes.
A 512 bits ECC PK should be at least 64 bytes long (without any
encoding). So maybe a 512 bits ECDSA PK in the CGA PDS will add
something like 80 bytes. Doing little math, we may be able to fit no
more than ten 512-bits Public Key + one 1024-bit RSA PK in a normal
Neighbor Solicitation message.
A 512-bits long ECDSA key is equivalent to 15360-bits long RSA key.
seems good to me
When using multiple signature (for routers, if we allow it), it might
raise the size of the packet over the MTU size (if we have a lot of
Public Keys). No a real problem here, as we may choose to send multiple
Router Advertisements message instead of one.
well, i guess that the normal scenario would not be 10 keys...
I don't know if when are up to do packet fragmentation in order to
support more Public Keys or if there is even a need for that.
couldn't parse this one....
well, it seems that in order to support crypto agility we will need
some shanges in send.
whether these particular set of changes is the right one, it is up
for disucssion, but updating rfc3971 is clearly needed imho
OK, we will propose changes and see if they reach a consensus.
ok, i understand that you will include an high level overview of these
changes in the draft you are writing?
If not, we can as well use the Key Hash to determine which Public
Key in
the
CGA PDS was used to perform the Digital Signature, but we think it is
neither
really optimal (as the node may have to compute a lot of extra
hashs) nor
elegant.
> The main issue here is that we need a mechanism to deal with the
case > that different nodes support different algorithms.
We address this problem by introducing a new SEND option named
"Supported Signature Algorithm Option" (name it itself being clear):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R| Nr. supp. Algos | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig. Alg. 1 | Sig. Alg. 2 | Sig. Alg 3. | Sig. Alg 4. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ | ... |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Sig. Alg. N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option contains signature algorithm that are supported by a node.
The receiver can determine which Signature Algorithm is more suited
for
the emitter.
what does supported means?
does it means that it can validate using this suite or does it means
that it has CGA and or a cert that it uses this suite?
these are different things and i think we need both?
We need both to perform negotiation process.
well, it depends how you define the nogotiation process, right?
The 'R' flag (generally set by the message sent by the nodes that
respond to the initial request) helps to diagnosis when a resent of
the
message is needed:
It helps in this case:
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
right, but the problem is that RADV are also sent unsolicited... so
how you propose to deal with this situation?
one option would be that if a node receives a RADV with signed with a
non supported suite it can then send a RSOL asking for the right
suite, but that would imply to be able to differnetiate the fact that
a node can validate with a suite and that a node has the CGA and the
cert with a given suite i think
That is almost the way we plan to do it (sending a RSOL to ask the right
suite).
> Note that today, CGAs are used by SEND, MIPv6 and SHIM6 and they
all > assume that the key is RSA
> I understand that in the case that a different
AlgorithmIdentifier is > included in the Public Key field of the
CGA PDS, the receiving peer will > fail the verification. Since the
key is bound to the address, the sender > will need to retry, but
using a different public key, hence using a > different address. It
seems that what may be needed then is an error > message in these
protocols. The potential problem of such error message > is that it
could open the door for downgrading attacks.
I'm not sure an error message could cause any harms.
If we request the error message to be signed and secured with SEND
option.
For example:
After a request from a node A, the node B send its reply. In the
meantime, the attacker send a fake error message supposed to come from
node B. - case 1: node A can check the signature on B's message, it
won't
fall
for it. - case 2: node A can't check B's signature, it won't
trust be,
the error
message won't help the attacker since it won't be trusted either
In any cases, if the attacker is in position to drop any of B's
packet,
the error message won't help the attacker to become more powerful.
mmm, but the point is that if the attacker can drop ONE packet and
fake the error message, it would render send inactive between the
nodes for as long as the information is stored in the cache (Which
can be a long time if the nodes talk to each other frequently)
Maybe a node shouldn't store/update a cache when it can't talk to a
node. Does it serve a purpose ?
but in this case it was able to talk to him and he obtained a reply that
contains the error message
So, i guess that you are suggesting is that we don't cache the error
message when it is not secured...
I guess we need to check how send works when dealing with plain ND
messages, I understand that SEND always rewrites plain ND, but i don't
rememebr how this works when ND has a cached data....
So, this would imply that dropping one packet and generating an error
message (which is unprotected) would deactivate send between two
nodes... right?
The error message should be protected (so a third party can check the
message during forensic).
how?
the whole point of the error message it to handle the case that there is
no common crypto suite between the two communicating nodes
So, by definition, the receiver cannot validate the error message
Note that the message could be understood by
the node. If the error message only state something like "you are using
too short keys", it wouldn't prevent the receiver to verify the message.
right, in this case i agree
but this opens the door to downgrading attacks though
I mean, would the error would sign by the long key or the short key?
This is to my mind a really important feature. Consider the following
example:
a router is in a heterogeneous network were nodes are using ECC or RSA
(not
both at the same time). If we don't allow multiple signatures, the
router
will
have to send 2 messages so all node can be aware of the same
information.
If
we allow multiple signature, we have only one message. Allowing
multiple
signatures for routers will reduce the overhead. However, our
analysis is
that for host, multiple signature shouldn't be used.
Host will more likely resend a message with another Signature
Option when
need.
one issue here is do you think that we also need router with multiple
certificates? i.e. certs with different crypto suites?
We are not sure anymore about how feasible would be this specific point.
me neither
We think the choice should be made on deployment. An administrator may
have full control on the network, choosing one Signature Algorithm on
the same network (PK only contained in CGA PDS Public Key field).
On the
other side, administrator may not have any control and faces host
with a
lot of different type of Signature Algorithm (routers will have to
support multiple Signature Algorithms, controlled host will have to
use
multiple-key CGA). The modification of the protocol we propose
should be
fitted for these usages.
right,
but the porblem if you allow both is that we need to figure out how
the different combinations interact
Right, this is why negotiation has to be robust.
We also plan to introduce an optional Router-as-a-notary function,
that
helps nodes that don't have any common Signature Algorithm to securely
communicate NDP informations together. Basically: when a node doesn't
understand the signature of a message, it will forward the packet to a
router (that will be trusted for this role via its certificate), that
have more processing capabilities (and functionalities) and that will
check the signature on the nodes behalf. Once the signature has been
checked, the status is transfered to the node. This may induce
specification of two new ICMP messages.
This is useful for scenario with really lightweight nodes (that can
only
support on type of specific Signature Algorithm) mixing with normal
nodes.
i like this, cool
would this be related to the proxy send work?
No, I don't think it will, this is just too different. We are just
introducing two new ICMP messages. First one is used to forward
(securely) to a trusted router a copy of the packets it can't verify by
itself. The second one is the response from the router which indicate
the status of the previous message (signature was good/bad).
ok, will look into that once you have the draft
Regards, marcelo
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
