Hi Marcelo,
Thanks for your comments. I will try to answer them inline.
We think multiple keys can be a good transition mechanism in network
that are (or will be) deployed with 3971 version of SEND. I explain why
this is good and how we can make it backward compatible with the actual
SEND specification.
> RFC3972 states that only RSA are supported and there is a mandatory
> Public Key filed in the CGA PDS that contains:
>
> The public key MUST be formatted as a DER-encoded
> [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo,
> defined in the Internet X.509 certificate profile [RFC3280]. SEND
> SHOULD use an RSA public/private key pair. When RSA is used, the
> algorithm identifier MUST be rsaEncryption, which is
> 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by
> using the RSAPublicKey type as specified in Section 2.3.1 of RFC
> 3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits.
> Other public key types are undesirable in SEND, as they may result
> in incompatibilities between implementations. The length of this
> field is determined by the ASN.1 encoding.
>
> So we have two options to support alternative public key algorithms in
> CGAs:
> - one option is to allow to include a public key of another algortihm in
> the Public Key field. In order to do that, we must provide a way to tell
> which algorithm is used.
> According to RFC3280,
> SubjectPublicKeyInfo ::= SEQUENCE {
> algorithm AlgorithmIdentifier,
> subjectPublicKey BIT STRING }
> and
>
> AlgorithmIdentifier ::= SEQUENCE {
> algorithm OBJECT IDENTIFIER,
> parameters ANY DEFINED BY algorithm OPTIONAL }
>
> I understand that RFC3279 defines the different algorithm identifiers
> for RSA.
> So, this option would be to simply allow to use other algorithms and see
> if the Algorithm identifiers for these algorithms have been properly
> defined.
> While it seems that current RFC3972 allows this already, we may want to
> update it to make it more explicitly.
> In addition, we want to make sure that the ECC support is properly
> defined.
This is one way to do it. We plan to use it when the node only support
one type of Signature Algorithm. ECDSA SubjectPublicKeyInfo already has a
been defined if I'm not wrong (in RFC3279 I think).
I am not sure about that. I have look it up in a quick reading and i couldn't
find it, but it was a very quick reading....
I think Sean explained it now. There is also some info about
SubjectPublicKeyInfo for ECC in an other WG draft named
draft-ietf-pkix-ecc-subpubkeyinfo (draft is currently up to IESG
processing).
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.. 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.
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.
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.
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.
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.
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 ?
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). 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.
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.
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).
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
