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

Eric Rescorla <> Fri, 22 March 2019 10:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B1FE130EBF for <>; Fri, 22 Mar 2019 03:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TFjV8Gm9pttB for <>; Fri, 22 Mar 2019 03:24:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D9D81310A2 for <>; Fri, 22 Mar 2019 03:24:01 -0700 (PDT)
Received: by with SMTP id t13so1579304lji.2 for <>; Fri, 22 Mar 2019 03:24:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=771zY9fT2VZuD0HwkYWxZ+nFi82TboORfbTII6GQ0Mg=; b=pJO9n2h2Gvhwi4hqg0KrIOI7jHgCYKLptl9NmI3hhynBcicwc48HE8KbZ3std/IzPo OrTQ1zHc9tvFGeOpOY96j4CkxrUJn4yAP2LFDaN+dd6bITej0iLp6XdeNrVUZkhqKcnH KvkSnlJWMIiWs43EXqCPM5J7FjGcIkuVGf1xs7TAFthfZm3atvVG3hXMvarpFAnnYX0Y YYnhzraryrInCUcVji21Q82R4JGrdPXSrZgmO//MazVH91RWf/Xpru3Fo9DjfQrssqJW J3pxo4mcRJhoP+l2aapymnc2TaeyrOGC26onACX3rPB+coWUE40S9jzFO+Bpgmh2GB/s gRmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=771zY9fT2VZuD0HwkYWxZ+nFi82TboORfbTII6GQ0Mg=; b=s9evndwRi7WRIY80ROiwOsrJw7q+FrFkVij1cChiWRNrmaWTvo/4PksmwUReqMiZWs 0VDY02eN34V838L7QZgJf2RxohDQDC0pFCuONpcjqRMVW8uPnkiJNQkwmbq0oMsHd1cd 7e4T8zh5XubnRPomzarJP4lFECq8X630EiwgEnJn26vLM2uQhLAl23v8S/0/nbv/3/ip LyyF8nr0JVFDdByyD0LUesMaISKlclvxDREUC6EKS9PEnDRP6ielsymk6HzzXVuNouPb EuzbHCb3Vy6zrkRPT9yDyWGYLQb14pB7bXmuJqREE/4kodpXoRflN2wkdbss22v2z6AK GBCg==
X-Gm-Message-State: APjAAAXBqv4BxRUueGrJcjAl3fvRhIkEXNiXNw6cyHxfWjFIPWYnQNw0 /wH3koC8qk3Qek8u/MCLDKUloNz/3cV949ZUuKjKGw==
X-Google-Smtp-Source: APXvYqwxDXmOwH4eZr4IwO31omGoYxQ4Ry4NayxIxMGrAZzmb/hYqm0H6WMZuCQPRHX/DzCIypM7WgabfazOFWsA778=
X-Received: by 2002:a2e:8050:: with SMTP id p16mr4943072ljg.160.1553250239054; Fri, 22 Mar 2019 03:23:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Fri, 22 Mar 2019 03:23:22 -0700
Message-ID: <>
To: Sean Turner <>
Cc: Alissa Cooper <>, The IESG <>, SIDROps Chairs <>, Chris Morrow <>, SIDR Operations WG <>,
Content-Type: multipart/alternative; boundary="000000000000bf198c0584ac40c3"
Archived-At: <>
Subject: Re: [Sidrops] Eric Rescorla's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Mar 2019 10:24:18 -0000

On Tue, Feb 12, 2019 at 6:25 PM Sean Turner <> wrote:

> > On Jan 23, 2019, at 23:57, Eric Rescorla <> 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
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > Rich version of this review at:
> >
> >
> >
> >
> > 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

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