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

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 14 Dec 2008 19:41:03 +0100

Hi,

there have been some discussion about how to support multiple public key 
algorithms in CGAs.
I include some thoughts below to continue the discussion

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.

The main issue here is that we need a mechanism to deal with the case 
that different nodes support different algorithms.
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.
In any case, it seems clear that if we go this path, we should reccomend 
that the usage of alternative aplgorithms would break the aforementioned 
protocols assumptions and needs to be deployed and used in a controlled 
manner, to avoid failure modes.

The other option is to define a new CGA extension that could carry an 
additional public key (of eventually a different algorithm)
In this case, a node could have multipla public keys of different 
algorithms, associated to the same CGA. this would have no backward 
compatibility problems, since the "main" public key would be RSA and the 
additional ones could be of other algortihms.
The problem here, is that in order to do this, we impose that all nodes 
must have a RSA public key and one of the motivations for this was that 
some lighweight nodes couldn't use RSA. However, this approach seems 
particularly attractive imho for routers and servers, that need to 
communicate both with normal SEND nodes and lighweight nodes. In this 
case,they can choose to use RSA for backward comaptibility and also to 
use ECC when talking to lighwieght nodes.
One intermediate approach could be to require to all nodes to always be 
capable of verifying RSA signatures, but not requiring to have a RSA key 
itself. This would allow to always be able to fall back to RSA when at 
least one of the nodes has an rsa key to have a secure channel
.

I think we probably need to do both, but i am not certian yet.

comments?

Regards, marcelo

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Sean Shen <[email-masked]>
Date: Mon, 15 Dec 2008 11:40:55 +0800

hi, Marcelo,
We (Tony, Micheala, Mariline and me) are writing two drafts for the agility
work: one is the agility support for CGA, the other is the agility support
for SeND. Basically the CGA agility will simply let an CGA associated with
multiple public keys, in the extension part of Public Key field in the CGA
PDS.  SeND Agility will deal with how to get agreement on an algorithm which
both nodes can use in SeND. We separate the job of two protocols to clarify
roles of CGA and SeND in agility, such that CGA will provide enough support
when it is used in protocols other than SeND 
We just had a discussion last night and made more improvement. Tony is
sorting out our discussions and will soon send our detailed answer soon.
Best,

Sean

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
>Sent: Monday, December 15, 2008 2:41 AM
>To: [email-masked]
>Subject: [CGA-EXT] Public Key algorithm agility in CGAs
>
>Hi,
>
>there have been some discussion about how to support multiple 
>public key algorithms in CGAs.
>RFC3972 states that only RSA are supported and there is a 
>mandatory Public Key filed in the CGA PDS that contains:
>
>- 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,
>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.
>The main issue here is that we need a mechanism to deal with 
>the case that different nodes support different algorithms.
>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.
>In any case, it seems clear that if we go this path, we should 
>reccomend that the usage of alternative aplgorithms would 
>break the aforementioned protocols assumptions and needs to be 
>deployed and used in a controlled manner, to avoid failure modes.
>
>The other option is to define a new CGA extension that could 
>carry an additional public key (of eventually a different 
>algorithm) In this case, a node could have multipla public 
>keys of different algorithms, associated to the same CGA. this 
>would have no backward compatibility problems, since the 
>"main" public key would be RSA and the additional ones could 
>be of other algortihms.
>The problem here, is that in order to do this, we impose that 
>all nodes must have a RSA public key and one of the 
>motivations for this was that some lighweight nodes couldn't 
>use RSA. However, this approach seems particularly attractive 
>imho for routers and servers, that need to communicate both 
>with normal SEND nodes and lighweight nodes. In this case,they 
>can choose to use RSA for backward comaptibility and also to 
>One intermediate approach could be to require to all nodes to 
>always be capable of verifying RSA signatures, but not 
>requiring to have a RSA key itself. This would allow to always 
>be able to fall back to RSA when at least one of the nodes has 
>an rsa key to have a secure channel .
>

---

From: Tony Cheneau <[email-masked]>
Date: Mon, 15 Dec 2008 15:01:46 +0100 (CET)

Hello Marcelo,

As Sean stated, we (Michaela, Sean, Maryline and I) are currently working on
some solutions for the problems you exposed. Unfortunately, we didn't finish
writing the drafts yet. The comments during the last WG meeting provided us
some really good insight. We hope this discussion will make clearer what is
possible and what is not.

I will try to explain how we envision to solve theses problems. Comments
inline.

> there have been some discussion about how to support multiple public key 
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:
>
> - 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,
> 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.
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).

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              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Public Key will encoded the same way as the Public Key field in the CGA
PDS (DER-encoded, etc.).

When constructing the CGA, we will have to compute a  hash of a CGA PDS
looking like this:
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |                             |
                        +         Modifier            |
                        |                             |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |                             |
                        +      Subnet Prefix          +
                        |                             |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |Col Count|                   |
+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |      |        Public Key           |
~  Public Key 1 ~ ->   ~                             ~
|               |      |     (variable length)       |
+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+      |         Extension           |
|               |      ~       Public Key 2          ~
~  Public Key 2 ~ ->   |     (variable length)       |
|               |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+      |                             |
                        ~           ...               ~
                        |                             |
+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |      |         Extension           |
~  Public Key N ~ ->   ~       Public Key N          ~
|               |      |     (variable length)       |
+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |      Extension Fields       |
                        ~                             ~
                        | (optional, variable length) |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This way, all the Public Keys are linked to the CGA address. Note here that it
is only a transitional mechanism as it will make the messages grow bigger as
more Public Keys are added.

Now that a node can have multiple public keys, we need to differentiate
which one are in used to sign the message. For this reason, we update
the format of the current RSA signature option:

     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     | Key Position  |  Reserved     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                          Key Hash                             |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       Digital Signature                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                           Padding                             .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We merely redefined the Reserved field to suit our needs. The Key
Position indicates which Public Key was used to build the signature in
the Digital Signature field. Value 0 indicates it was signed with the
CGA PDS Public Key field. Value 1, signed with the first Public Key
extension in the Extension field of the PDS. And so on. The construction
of the Digital Signature field will be define in separate specific
documents for each Signature Algorithm scheme (e.g. draft-shen-csi-ecc
for ECDSA).

A node using a RSA Signature will place its RSA Public Key in the CGA
PDS Public Key field. When using the "not-RSA-only-anymore Signature
Option", it will set the Key Position to 0. This way, it is fully
backward compatible with 3971 enabled nodes.

Will the WG allow us to do such modification to RFC3971 ?

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.

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

> Note that today, CGAs are used by SEND, MIPv6 and SHIM6 and they all assume 
> that the key is RSA
> 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.

This error message may not be needed at all, when using the "Supported
Signature Algorithm option".

> In any case, it seems clear that if we go this path, we should reccomend that 
> the usage of alternative aplgorithms would break the aforementioned protocols 
> assumptions and needs to be deployed and used in a controlled manner, to 
> avoid failure modes.
We didn't evaluate the needed changes for MIPv6 and SHIM6, but for SEND,
we tried to make changes as smooth as possible. We made a separate draft on
Multiple-key CGA and an other one about modification on the SEND protocol. We
think we can success to make RFC3971 capable nodes and new nodes compatible
through a small negotiation process.

> In this case, a node could have multipla public keys of different algorithms, 
> associated to the same CGA. this would have no backward compatibility 
> problems, since the "main" public key would be RSA and the additional ones 
> could be of other algortihms.
That is the path we plan to take when we consider nodes with multiple
keys deployment.

> The problem here, is that in order to do this, we impose that all nodes must 
> have a RSA public key and one of the motivations for this was that some 
> lighweight nodes couldn't use RSA. However, this approach seems particularly 
> attractive imho for routers and servers, that need to communicate both with 
> normal SEND nodes and lighweight nodes. In this case,they can choose to use 
> RSA for backward comaptibility and also to use ECC when talking to lighwieght 
> nodes.
We believe we can make use of routers in heterogeneous network that  will
support multiple kind of signature option in the same message. Receiver
will only have to check one of the signature to trust a router.  If I
remember correctly, the WG wasn't really happy with this idea. 
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.

> itself. This would allow to always be able to fall back to RSA when at least 
> one of the nodes has an rsa key to have a secure channel
> .
>
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.

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.

Things as I told them may be fuzzy, we will post the drafts as soon as
possible for reviews.

Regards,
 	Tony Cheneau

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Dec 2008 15:40:50 +0100

Hi tony,

thanks for the answer

your points seem reasonable to me and i am expecting to draft to comment 
further.

please check the other mail i sent about interop, you may want to cover 
these as well in your draft.

some replies in line...

Tony Cheneau escribió:
>> there have been some discussion about how to support multiple 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,
>> 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.

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....

> draft) the structure of the extension. It basically looks like this:
mmm, maybe it would be better to define a generic public key extnesion 
and define subtypes for the different algorithms?
seems cleaner to me

> When constructing the CGA, we will have to compute a  hash of a CGA PDS

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...)

> Will the WG allow us to do such modification to RFC3971 ?
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

> "Supported Signature Algorithm Option" (name it itself being clear):
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?

> RSA Signature option. Supported-Signature-Algo option
> ECC Signature option. Supported-Signature-Algo option
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
>> 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.
> 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
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)

So, this would imply that dropping one packet and generating an error 
message (which is unprotected) would deactivate send between two 
nodes... right?

>> reccomend that the usage of alternative aplgorithms would break the 
>> aforementioned protocols assumptions and needs to be deployed and 
>> used in a controlled manner, to avoid failure modes.
that is not in our charters, but i think we need to make sure that this 
doesn't break other stuff
> through a small negotiation process.
sounds good

>> compatibility problems, since the "main" public key would be RSA and 
>> the additional ones could be of other algortihms.
>> The problem here, is that in order to do this, we impose that all 
>> nodes must have a RSA public key and one of the motivations for this 
>> was that some lighweight nodes couldn't use RSA. However, this 
>> approach seems particularly attractive imho for routers and servers, 
>> that need to communicate both with normal SEND nodes and lighweight 
>> nodes. In this case,they can choose to use RSA for backward 
>> comaptibility and also to use ECC when talking to lighwieght nodes.
not sure why not....

> signatures for routers will reduce the overhead. However, our analysis 
> is that for host, multiple signature shouldn't be used.

one issue here is do you think that we also need router with multiple 
certificates? i.e. certs with different crypto suites?
>
>> One intermediate approach could be to require to all nodes to always 
>> be capable of verifying RSA signatures, but not requiring to have a 
>> RSA key itself. This would allow to always be able to fall back to 
>> RSA when at least one of the nodes has an rsa key to have a secure 
>> channel
>> .
>>
right,
but the porblem if you allow both is that we need to figure out how the 
different combinations interact

> support on type of specific Signature Algorithm) mixing with normal 
i like this, cool
would this be related to the proxy send work?

> Things as I told them may be fuzzy, we will post the drafts as soon as
great!

thanks, marcelo

---

From: Sean Shen <[email-masked]>
Date: Tue, 16 Dec 2008 17:41:11 +0800

Hi, 
It took me a while to pull down to the bottom of an email, so I am trying to
comments in threads. Let me know it it does not help at all.   
Please check in line..

>identifiers 
>algorithms and 
>> 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....

In rfc3279,  the signation algorithm OID is defined in Section 2.2, the
subject public key OID is defined in Section 2.3. ECDSA algorithm and public
key has been defined there. 

Sean

---

From: Tony Cheneau <[email-masked]>
Date: Wed, 17 Dec 2008 00:35:17 +0100 (CET)

Hi Marcelo,

Thanks for your comments. I will try to answer them inline.

> 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).

> 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.

> disucssion, but updating rfc3971 is clearly needed imho
OK, we will propose changes and see if they reach a consensus.

> 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?
We need both to perform negotiation process.

> 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).

>>  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
> 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.

>>  signatures for routers will reduce the overhead. However, our analysis is
>>  that for host, multiple signature shouldn't be used.
We are not sure anymore about how feasible would be this specific point.

> different combinations interact
Right, this is why negotiation has to be robust.

> 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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 Dec 2008 09:43:55 +0100

Tony Cheneau escribió:
>>> | | ~                        Public Key                              ~
>> mmm, maybe it would be better to define a generic public key 
>> extnesion and define subtypes for the different algorithms?
>> seems cleaner to me
right

>> 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...)
seems good to me

> Router Advertisements message instead of one.
well, i guess that the normal scenario would not be 10 keys...

> 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, 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
>>> >  The main issue here is that we need a mechanism to deal with the 
>>> case >  that different nodes support different algorithms.
>>> ~ ~ |                           ...                                  |
well, it depends how you define the nogotiation process, right?

>> right, but the problem is that RADV are also sent unsolicited... so 
>> how you propose to deal with this situation?
>> 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

>>>
>>> >  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.
>>> won't
>> 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....

> 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
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?

>>>  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

me neither
>> but the porblem if you allow both is that we need to figure out how 
>> the different combinations interact

ok, will look into that once you have the draft

Regards, marcelo

---

From: Tony Cheneau <[email-masked]>
Date: Wed, 17 Dec 2008 11:23:44 +0100 (CET)

Hi Marcelo,

> couldn't parse this one....
I just meant to say: if we want for some usage more that 10 keys, we
might have to handle/use NDP packet fragmentation. NDP packet
fragmentation may be undesired here, but we have may have to state it
explicitly.

> changes in the draft you are writing?
Yes.

>> > >  If not, we can as well use the Key Hash to determine which Public Key 
>> > >  in
>> > >   the
Yes.

> 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....
What I wanted to say was: the attacker can drop some ND packet, so he
can virtually drop anything. If he block on NDP packet and send an error
message in order to shutdown a communication, I don't see any difference
(the new attack effects are not worst if we consider that we won't
update any cache upon reception of an untrusted error message).

> the whole point of the error message it to handle the case that there is no 
> common crypto suite between the two communicating nodes
The receiver might not, but a third party could. An administrator could
place probes inside his network that will tell him an attack is
undergoing.

> I mean, would the error would sign by the long key or the short key?
The short key error in this case is caused by the node that will receive
the error. But it is true that it might be difficult  to trust the error
message in some cases.

Regards,
 	Tony Cheneau

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 Dec 2008 11:44:04 +0100

> fragmentation may be undesired here, but we have may have to state it

i think fragmentation should be avoided.
I woudl preffer sending multiple ND messages than fragment
>
>
>
>
>>> >  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)
>> but in this case it was able to talk to him and he obtained a reply 
>> that contains the error message
>> messages, I understand that SEND always rewrites plain ND, but i 
>> don't rememebr how this works when ND has a cached data....

the difference is that if the receiver caches  the error information, it 
will not retry again, and the attacker will be able to disable send with 
just dropping one message and forging an error.
in other words, the difference is the tiem frame of the impact of the 
attack.
In the current situation, the attacker needs to be intercepting the 
messages for the whiole duration of the attack, If the attacker leaves 
the location and stop dropping the packet, the attack is over.
In this other situation, if the attacker manages that the reciever 
caches the error information and makes it beleive that the receiver does 
not support send, then send will not be used as lomng as the cached 
information is preserved. Even if the attacker leaves the attack 
position, the impact of the attack still applies

is this clearer?
>>> >  So, this would imply that dropping one packet and generating an 
>>> error >  message (which is unprotected) would deactivate send 
>>> between two >  nodes... right?
>> the whole point of the error message it to handle the case that there 
>> is no common crypto suite between the two communicating nodes
agree, for tracing purposes, this is useful

regards, marcelo