Re: Router Certificate in SEND

Hi Eric,

2008/5/29, Eric Levy-Abegnoli <elevyabe@...>:
> Hi Jean-Michel,
>
> On Thursday 29 May 2008 16:42:32 Jean-Michel Combes wrote:
>  > Hi Eric,
>  >
>  > 2008/5/29, Eric Levy-Abegnoli <elevyabe@...>:
>  >
>  >

[snip]

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

OK.

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

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

>
>
>  >
>  > I totally agree but one of the goal of this working group is "Update
>  > 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.

No choice in fact :)

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

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.

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

OK.

Best regards.

JMC.

>
> Eric
>