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

Sean Turner <sean@sn3rd.com> Fri, 12 April 2019 04:28 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BB3120094 for <sidrops@ietfa.amsl.com>; Thu, 11 Apr 2019 21:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFXpISCrQQK5 for <sidrops@ietfa.amsl.com>; Thu, 11 Apr 2019 21:28:41 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002EF12003F for <sidrops@ietf.org>; Thu, 11 Apr 2019 21:28:40 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id o129so4885558qke.8 for <sidrops@ietf.org>; Thu, 11 Apr 2019 21:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ZIWQISjErt4ZYPfQuHC+rKoit7m5kHkDeHlfqmVgMI=; b=HFr1ZNnv5I8Snl0MmvIUCLEUOJw4awa0+Fr4qIeq8V9VyEwPxX1pyRgmziFacwpjG6 DNxuYSubsMMtdcJ3n5oQkckigkG4nr+R+5KbjJCojvWdk7YgybVNhxthnp5daN8cffDi SvMXm0hjy/kW+fpgmfSAK5fL1HCiv6F8F0yWI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ZIWQISjErt4ZYPfQuHC+rKoit7m5kHkDeHlfqmVgMI=; b=jsZuM0j85UruAK57uHd2GK1VrVcoU8xCDnbNCL5A6FU/XOnG5aer2ayL/pbnANK2WS bC7EhtLiA5O4Vr1F6ph+5RwRJwyl5nvDVRCktc8dlJz6yCQADBHY7+/+bzrky2RiBUYe 2cZfqilZ70gAQ9DkG5lAGMxG/E3POf2PEaWsZHNSQnSI+SYQCrpu+iOiSmpTX5mJIzHL cPo1SfpfUm9TKAs9v0dHQdEJTXztmZytUCvzMj50F6cUWqRGI0U2Hi3wsy69P5REdxC7 pR5w//P7h3KFO+0lGasPiKufcVQ7P7DROm+2e7NmvMzCs48DfaI+MTi9w9C7y3WrjnZp neKA==
X-Gm-Message-State: APjAAAVQzzRAmeoJaFuAoqQWcEZGM02UOmF7koEA6eR6sm0vx8Ok9Hi/ nNBy+pTcKSf2qGzIa+B/nBiPYQ==
X-Google-Smtp-Source: APXvYqyJPQUQEtQQ5EtL3hwS3U/OFXELeWVFmJk2jb/9Q8DeNL2M+jQVw7pEQCt2bk6JHtyoWHcZjA==
X-Received: by 2002:a37:bb07:: with SMTP id l7mr41652330qkf.51.1555043320014; Thu, 11 Apr 2019 21:28:40 -0700 (PDT)
Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id z20sm23912240qkb.52.2019.04.11.21.28.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 21:28:39 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <CABcZeBN_X5X48hJCS+F5ODHwEmvXLownbH6Mf5=4qsSKyENGaQ@mail.gmail.com>
Date: Fri, 12 Apr 2019 00:28:35 -0400
Cc: Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>, SIDROps Chairs <sidrops-chairs@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, SIDR Operations WG <sidrops@ietf.org>, draft-ietf-sidrops-rtr-keying@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6FC4441-9A27-4738-9E85-BF87DF741DF6@sn3rd.com>
References: <154830586386.7517.12515642346949342885.idtracker@ietfa.amsl.com> <587443F2-D022-4109-AFF7-E6C06091E151@sn3rd.com> <CABcZeBN_X5X48hJCS+F5ODHwEmvXLownbH6Mf5=4qsSKyENGaQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/zlCvHrR3omUcox2Aru5POo0VyR8>
Subject: Re: [Sidrops] Eric Rescorla's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 04:28:44 -0000

> On Mar 22, 2019, at 06:23, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Tue, Feb 12, 2019 at 6:25 PM Sean Turner <sean@sn3rd.com> wrote:
> 
> 
> > On Jan 23, 2019, at 23:57, Eric Rescorla <ekr@rtfm.com> 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.

I’m suggesting the following text in s2:

  To be clear: for both of these methods, an initial leap-of-faith
  is required because the router has no keying material that it
  can use to protect communications with anyone or anything.
  Because of this initial leap of faith, a direct physical connection
  is safer than connecting via a network connection because there
  is less chance of a man in the middle.  Once keying material is
  established on the router, the communications channel must
  prevent eavesdropping, tampering, and message forgery.  This
  initial leap-of-faith will no longer be required once routers are
  delivered to operators with operator-trusted keying material.

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

Here the operator is doing the POP check and if the channel the operator is talking to the router over is secured after initial set-up then the operator can be sure that the entity that signed the CSR after the operator requested the router sign the CSR is the CSR.  The operator can then act as the RA to tell the CA that it was the one that the POP check.  If the operator is trying to be a bad guy then sure all bets are off.

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

On the router side it’s the CSR and on the CA side it’s some kind of account entry on the CA.  I will add the following to the bullet:

  The CA stores this authentication material in an account entry for the router
  so that it can later be compared against the CSR prior to the CA issuing a
  certificate to the router.

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

I’m dropping everything from that paragraph after the 1st sentence.

A new version was posted:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/

spt