Re: [Sidrops] Eric Rescorla's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Tue, Feb 12, 2019 at 6:25 PM Sean Turner <[e-mail]> wrote:

>
>
> > On Jan 23, 2019, at 23:57, Eric Rescorla <[e-mail]> wrote:
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-sidrops-rtr-keying-03: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D13996
> >
> >
> >
> > DETAIL
> > S 2.
> >>
> >>     Operators are free to use either the router-driven or
> operator-driven
> >>     method as supported by the platform.  Regardless of the method
> >>     chosen, operators first establish a protected channel between the
> >>     management system and the router.  How this protected channel is
> >>     established is router-specific and is beyond scope of this document.
> >
> > This seems rather under-specified. Given that we know that people are
> > not careful about this, I think you need to specify some sort of
> > minimum requirements for this channel. That need not be a particular
> > protocol, but it needs to specify the security properties it provides.
> > I see you have some SHOULD-level language later, but I think you need
> > MUST level, and as noted below, I think the guidance is wrong.
>
> Alissa had a comment in the same vein so I hope to address both here.
>
> In the future, routers may come with key material burned into them that
> the router can then use to securely communicate with the operator (e.g.,
> brewski or something akin to what’s in s8), but the reality is that the
> routers arrive with nada on them.  So, s2 is about how the operator gets
> keying material into the router that it can then later use to secure
> communications with the operator.  There’s two ways to get this done and
> there’s an initial leap of faith that has to happen (i.e., there’s -no-
> security on first connect):
>
> - the operator connects directly through the “craft” port and “squirts”
> the keying material in and configures the router to use SSH (or whatever)
> for future connections.  It’s also going to set up it’s AS number and
> whatever else goes in the config file to make the protocol run.
>
> - the operator connects over a network port and squirts the keying
> material in and configures the router to use SSH (or whatever) for future
> connections.  But, chances are very high that the operator connects to the
> router via SSH, and probably with some generic lame pwd.
>
> So while I agree we want to better specify what kind of protections this
> channel should provide I am unsure what to write if the router has no
> keying material whatsoever when the operator gets first it.
>

OK. I think you need to lay this out in the text in more detail, but I'll
trust you to do it.


> > S 5.2.
> >>     the BGP Identifier when it sends the CSR to the CA.
> >>
> >>     Even if the operator cannot extract the private key from the router,
> >>     this signature still provides a linkage between a private key and a
> >>     router.  That is, the operator can verify the proof of possession
> >>     (POP), as required by [RFC6484].
> >
> > It's not clear to me what is being claimed in terms of PoP here. As I
> > understand it, the certificate is a binding between the AS number/BGP
> > identifier pair and the public key, but if neither of those is in the
> > PKCS#10 request, then they're not signed over by the private key, and
> > so PoP isn't really operative. The relevant question is whether if I
> > obtain the PKCS#10 request I can obtain a certificate for an identity
> > other than the intended one.
>
> 1st baed on somebody else’s comment we’re moving that paragraph to s5.1.
> It’s out of place in s5.2 because If the operator can generate the key well
> they certainly have access to it.
>
> The POP we’re getting is that the router has the key.   If there’s nothing
> in the CSR but the operator is the middle-man then the operator can tell
> the CA this CSR goes with this name though some other means.
>

But this *isn't* PoP because you can transplant the CSR into another
context.


>>         the CA prior to operator initiating the router's CSR.  CAs use
> >>         authentication material to determine whether the router is
> >>         eligible to receive a certificate. Authentication material at a
> >>         minimum includes the router's AS number and BGP Identifier as
> >>         well as the router's key material, but can also include
> >>         additional information. Authentication material can be
> >
> > Surely it also includes some information that allows the router to
> > prove it is entitled to a key with that AS and BGP identifier, but I'm
> > not seeing this here.
>
> I guess maybe I am confused because I thought that’s what the entire
> bullet was about.  The operator is priming the CA with information that
> will allow the router to begin contacting the CA without the operator in
> the middle.
>

 Yes, but my point is what ties this to the identity? Some account entry on
the CA?


> > S 1.
> >>     operator-driven method.  Routers are required to support at least
> one
> >>     of the methods in order to work in various deployment environments.
> >>     Some routers may not allow the private key to be off-loaded while
> >>     others may.  While off-loading private keys would ease swapping of
> >>     routing engines, exposure of private keys is a well known security
> >>     risk.
> >
> > This is a somewhat shallow treatment of this. Specifically:
> >
> > 1. There are multiple ways in which a device might allow a key not to
> > be exported. For instance, there might not be a command, but it might
> > be in unencrypted NVRAM. Or, it might be in an HSM. These have very
> > different security properties.
> >
> > 2. There are designs which allow a key to be moved from device to
> > device without exposure, e.g.,, a hardware token.
>
> I agree it’s a little/lot shallow, but I am not sure what digging deeper
> is going to accomplish here especially in the intro.
>

Well, my point is that it misrepresents the situation.

OULD be commensurate with the strength of the BGPsec
> >
> > I'm not sure "commensurate" is what's needed here. For instance, the
> > transport channel might be much more secure than the router key (e.g.,
> > P-521 and AES-256 with a RSA-2048 router key).
> >
> > More generally, it's not clear to me that these are really connected
> > at all, as the threat environments are totally different. As noted
> > above, I believe you should just specify a minimal level.
>
> Commensurate is probably the wrong word, I was shooting for "at least as
> good as."
>

Yes. My point is that that is a bad requirement for the reasons above.

-Ekr