Re: [CGA-EXT] Public Key algorithm agility in CGAs

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
CGA-EXT@ietf.org
https://www.ietf.org/mailman/listinfo/cga-ext