Subject: [CGA-EXT] Router Certificate in SEND

From: "Silviu VLASCEANU" <[email-masked]>
Date: Wed, 28 May 2008 16:51:40 +0200

Hello,

I am writing here with hope to find answers to a question that I have on the
SEND protocol. It is related to the certificate (certR) that a router (R)
presents to a host (H), in a CPA message, to certify the prefix that it
advertises.

Is the private key used by R to sign its SEND messages (= the private key
used in generating the CGA address) the same with the private counterpart of
the public key contained in certR?

Thanks!

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

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Wed, 28 May 2008 17:45:43 +0200

Silviu,
On Wednesday 28 May 2008 16:51:40 Silviu VLASCEANU wrote:
> Hello,
>
> I am writing here with hope to find answers to a question that I have on
> the SEND protocol. It is related to the certificate (certR) that a router
> (R) presents to a host (H), in a CPA message, to certify the prefix that it
> advertises.
>
> used in generating the CGA address) the same with the private counterpart
> of the public key contained in certR?
yes.  
Here is one place in RFC3971 where it has to be that way:
section 6.4.6

"The host SHOULD retrieve a certification path when a Router
 Advertisement has been received with a public key that is not
 available from a certificate in the hosts' cache, or when there is no
 certification path to one of the host's trust anchors.  In these
 situations, the host MAY send a Certification Path Solicitation
 message to retrieve the path. 
 "
The public key carriied by the RA (matching the private key used for sig, by 
definition) is the one for which the host wants to see a certificate. 
Eric

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 28 May 2008 20:27:04 +0200

Hi Eric,

at first thank for your reply but I am a little confused by it. See
comments in line below.

>  > of the public key contained in certR?

So you mean when the router R generates its CGA based Link-Local
address using a public/private key pair (named respectively Kp/Ks) and
each time it will request a new Router Authorization Certificate, it
will have to provide Kp (i.e. always the same public key) to the
Certification Authority/Registration Authority?
Then, even when a CGA option is present, the RSA Signature option will
use Ks for the signature, correct?

If this is the case, it is strange to use the same security material:
- to secure two different services (i.e. Neighbor Discovery and Router
Discovery);
- for all the certificates needed by the router.

>  definition) is the one for which the host wants to see a certificate.

Yes but, IMHO, that doesn't mean that this is the public key used by
the router to generate the CGA based LL address.

Best regards.

JMC.

---

From: Greg Daley <[email-masked]>
Date: Thu, 29 May 2008 08:11:26 +1000

Hi Jean Michel, 

> - for all the certificates needed by the router.

Personally, I have no problem with the same key being used for neighbour and
router discovery, but we may want to explore situations where this is not desirable.

With regard to the second point, within the SEND working group there was the
discussion regarding the types of certificates required for Routing, and I believe
there was some advantage seen in having X.509 extensions to identify routing
authority for particular prefixes (as in so-BGP).  This would allow different keys
to be used for other purposes on the router, but a certificate would exist which
in-common would allow for the first hop gateway function *and* the back-end
routing protocol security. 

I believe that given the immaturity of the extensions, and the desire for general
applicability of SEND prevented that at the time.

Perhaps investigating the roles of different keypairs is useful, but it may be 
necessary to explore the issues in a draft ;)

Greg

_________________________________________________________________
Be part of history. Take part in Australia's first e-mail archive with Email Australia.
http://emailaustralia.ninemsn.com.au

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 29 May 2008 08:25:31 +0200

Hi Jean-Michel,
On Wednesday 28 May 2008 20:27:04 Jean-Michel Combes wrote:
> >  > I am writing here with hope to find answers to a question that I have
> >  > on the SEND protocol. It is related to the certificate (certR) that a
> >  > router (R) presents to a host (H), in a CPA message, to certify the
> >  > prefix that it advertises.
> >  >
> >  > Is the private key used by R to sign its SEND messages (= the private
> >  > key used in generating the CGA address) the same with the private
> >  > counterpart of the public key contained in certR?
> >
> > yes.
>
indeed. But that is the way the spec is written. As a host, if I receive a RA, 
and want to verify the sender credential, I have to refer to the key 
contained in this RA. 
I don't have much problem with that btw (I think it's complicated enough, 
deployment wise), neither with allowing different security marterials if 
someone can come up with a reasonnable case. I just don't see how you could 
do it with the current spec.

> >  The public key carriied by the RA (matching the private key used for
> > sig, by definition) is the one for which the host wants to see a
> > certificate.
>
Now I am the one confused. The RA carries only one public key. And one 
signature. So the signature is for that public key. 
Now reading the section mentionned, the host look at this very key, and must 
find out if it has a certification path for it. In that context, how could 
the certification path refer to a different key?
I am not aguying whether this would be desirable or not. I am arguing that, 
with the information available in the RA, you can only associate the RA with 
a certifciate that certifies the key found in the RA, which happen to be the 
one that verifies the CGA address.
Eric

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 29 May 2008 15:27:38 +0200

Sorry. I forgot to send my reply to the ML.

JMC.

---------- Forwarded message ----------
From: Jean-Michel Combes <[email-masked]>
Date: 29 mai 2008 15:26
Subject: Re: [CGA-EXT] Router Certificate in SEND
To: Greg Daley <[email-masked]>

Hi Greg,

 > routing protocol security.

I agree.

 > necessary to explore the issues in a draft ;)

My main concern is, for the moment, the (bad?) consequences from a
 security point of view to use the same key pair. If the analysis shows
 security issues, so the SEND protocol should be modified to allow the
 use of different key pairs (i.e. one for the CGA and one for the
 Router Authorization Certificate).

 Cheers.

 JMC.

 >
 > Greg
 >
 > ________________________________
 > Email Australia. Be part of history. Take part in Australia's first e-mail
 > archive with

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 29 May 2008 16:42:32 +0200

Hi Eric,

2008/5/29, Eric Levy-Abegnoli <[email-masked]>:

[snip]

>  do it with the current spec.

After a quick review of different RFCs and I had spoken some
colleagues (crypto and certs experts), here are some issues:
o RFC3972 specifies that:
"Nodes that implement CGA verification for SEND SHOULD be able to
process RSA public keys that have the algorithm identifier
rsaEncryption and, key length between 384 and 2,048 bits.
Implementations MAY support longer keys."
=> So the algorithm (i.e. RSA) and the key length are fixed for the
certs once this last is decided for CGA. My certification expert
colleague explained me that some CA/RA may have a specific policy
regarding the public key in certs (i.e. algorithm, key length) and CGA
constraints could be in opposition with these ones.

o We know that more the key length is large, more the security of the
key pair is strong but less the CGA process is efficient. That's why
RFC3972 says:
"The minimum RSA key length required for SEND is only 384 bits.  So
short keys are vulnerable to integer-factoring attacks and cannot be
used for strong authentication or secrecy.  On the other hand, the
cost of factoring 384-bit keys is currently high enough to prevent
most denial-of-service attacks.  Implementations that initially use
short RSA keys SHOULD be prepared to switch to longer keys when
denial-of-service attacks arising from integer factoring become a
problem."
=> But, from my crypto expert colleague, when RSA key length is 384
bits, you may break it quickly.
=> That's why my certification expert colleague explained me that it
is useless to certify a key with such a length :)
o So, RFC 3972 says:
"The impact of a key compromise on CGAs depends on the application for
which they are used.  In SEND, it is not a major concern."
			^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=> I have the strong feeling the authors/SEND WG didn't take the fact
that the key pair MUST be the same for the CGA generation and the
Authorization Router Certificates, when a router wants to send RAs
with a CGA Option, into consideration when the RFC 3971 & 3972 were
specified. Indeed, on one side (the CGA one), I agree it should be
"easy"/"fast" for the router to generate again a new CGA address but,
OTOH, I have doubts the process should be easy to redo certification
process for all the needed certificates.
Now, I must admit it is too far in time, for me, to remember whether
there were discussions about this point :(

"If the private signature key is compromised because the SEND node has itself
been compromised, the attacker does not need to spoof SEND messages
from the node.  When it is discovered that a node has been
compromised, a new signature key and a new CGA SHOULD be generated. On
the other hand, if the RSA key is compromised because
integer-factoring attacks for the chosen key length have become
practical, the key has to be replaced with a longer one, as explained
above.  In either case, the address change effectively revokes the old
public key.  It is not necessary to have any additional key revocation
mechanism or to limit the lifetimes of the signature keys."
=> Here is, maybe, an illustration, IMHO, the RFCs didn't take the
previous point into account.

o Regarding the recommendation of use different security material for
different services:
- the hokey WG had decided the specification of USRK
(draft-ietf-hokey-emsk-hierarchy). => Even if this example is for
symmetric crypto, I think it may apply to us.
- the RFC 5280 says:
"The use of a single key pair for both signature and other purposes is
strongly discouraged.  Use of separate key pairs for signature and key
management provides several benefits to the users.  The ramifications
associated with loss or disclosure of a signature key are different
from loss or disclosure of a key management key.  Using separate key
pairs permits a balanced and flexible response. Similarly, different
validity periods or key lengths for each key pair may be appropriate
in some application environments. Unfortunately, some legacy
applications (e.g., Secure Sockets Layer (SSL)) use a single key pair
for signature and key management."
=> IHMO, this paragraph, from the Security Considerations section,
seems to confirm my fears. Maybe, it would be useful to contact the
PKIX WG people/chairs to get their feedbacks?

> I just don't see how you could

I totally agree but one of the goal of this working group is "Update
base specifications (RFC 3971 and 3972)." :-)

Potential approaches may be (BTW, I didn't check whether that works or not):
- to modify RSA Signature in adding flag to precise whether the
signature is linked to CGA key or cert key and to add two RSA Sig
options (one linked to CGA and one linked to the cert) in the RA
instead of only one like today
- to add a RSA Signature option in CPA messages: the RSA Sig option in
the RA is linked to the CGA address, the one in the CPA messages is
linked to the Router Authorization Certificate
- to add the router's Link Local address in the Router Authorization
Certificate and the node should have to check it too.
- others solutions?

>  one that verifies the CGA address.

Clearly, RFC3971bis needs clarifications ;-)

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 29 May 2008 16:44:33 +0200

Hi again,

> necessary to explore the issues in a draft ;)

IHMO, the draft should be RFC3971bis :)

Cheers.

JMC.

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 29 May 2008 18:04:47 +0200

Hi Jean-Michel,
On Thursday 29 May 2008 16:42:32 Jean-Michel Combes wrote:
> > indeed. But that is the way the spec is written. As a host, if I receive
> > a RA, and want to verify the sender credential, I have to refer to the
> > key contained in this RA.
> >  I don't have much problem with that btw (I think it's complicated
> > enough, deployment wise), neither with allowing different security
> > marterials if someone can come up with a reasonnable case. I just don't
> > see how you could do it with the current spec.
>
> "If the private signature key is compromised because the SEND node has
> itself been compromised, the attacker does not need to spoof SEND messages
I guess if one is careful up front to  use a big-enough key, for instance a 1k 
(which seems to be a good compromise), he should be safe for the duration of 
the certificate (couple of years). 
Could also increase the sec level: that does not change the key, hence does 
not require a re-cert.
Anyway,  I remember I advocated in Phily that routers addresses should not be 
CGA in critical cases, the same way they are not EUI-64. 
That way, a re-cert  or a re-key will not affect the address. And the key/cert 
for the router's address can be different (or the same) from the one for the 
router role.
 
> >  do it with the current spec.
I am not convinced the address ownership, and the address "role" (address that 
should be used as the default gateway address) can be seen as different 
services, requiring different key materials. I would argue this is going too 
far.
Then how about the address vs the prefix? The certificate already authorizes 
two things: the owner to be a default gateway, and the prefixes announced to 
be used for autoconf. Do you also want separate keys/certificates for these 
two?
 
> base specifications (RFC 3971 and 3972)." :-)
sure. But the initial question (from  Silviu) sounded more like a 
clarification question on the current spec. The current spec is clear and 
unambiguous: this is the same key.

I agree it would not be a big deal to fix it. 
However, I think that the biggest problem we have today with SEND is not about 
security holes, it's about complexity, especially deloyment-wise. More key 
pairs on the router will not help with that regard. What is the point in 
designing a super extra secured protocol that nobody deploys?

>
> Potential approaches may be (BTW, I didn't check whether that works or
> not): - to modify RSA Signature in adding flag to precise whether the
those mentionned will work. 
As long as they are "optional", they provide more flexibility, so it's ok. We 
can work out the details later.
Eric

> >  > >   available from a certificate in the hosts' cache, or when there is
> >  > > no certification path to one of the host's trust anchors.  In these
> >  > >  The public key carriied by the RA (matching the private key used
> >  > > for sig, by definition) is the one for which the host wants to see a
> >  > > certificate.
> >  >
> >  Now reading the section mentionned, the host look at this very key, and
> > must find out if it has a certification path for it. In that context, how
> > could the certification path refer to a different key?
> >  I am not aguying whether this would be desirable or not. I am arguing
> > that, with the information available in the RA, you can only associate
> > the RA with a certifciate that certifies the key found in the RA, which
> > happen to be the one that verifies the CGA address.
>

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 29 May 2008 19:06:36 +0200

Hi Eric,

[snip]

>  for the router's address can be different (or the same) from the one for the

OK.

>  be used for autoconf.

In the case, there is a CGA option and so the certificate is based on
CGA keys to be conform with the RFC 3971, I agree.
In the case, there is no CGA option, I disagree: there is no proof
that the owner, identified by the LL address, is the default gateway
it said in the RA. Nothing prevents it to launch, for example, the
"Default router is killed' (cf. RFC 3756, section 4.2.2) attack
because there is no ownership check on the LL address.

> Do you also want separate keys/certificates for these
>  two?

I am not sure whether the points I've raised, regarding the
requirement to have the same key pair for CGA and certs, may impact or
not the security. That is why I proposed to ask advices from the PKIX
WG people: if they say there is no problem, it will be fine for me :)

>  unambiguous: this is the same key.

No choice in fact :)

>  designing a super extra secured protocol that nobody deploys?

OTOH, if this is necessary for routers to request too frequently new
certs because the CGA keys must be renewed too frequently, we have an
administration issue with the deployment.

>  can work out the details later.

OK.

Best regards.

JMC.