Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT)
Alia Atlas <akatlas@gmail.com> Thu, 27 April 2017 04:11 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37D0127A97; Wed, 26 Apr 2017 21:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 n6jmK-70He75; Wed, 26 Apr 2017 21:11:40 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 34BBE1277BB; Wed, 26 Apr 2017 21:11:40 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id r190so2748002wme.1; Wed, 26 Apr 2017 21:11:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HdM70hYOI4KJMyjcLQyiibec9gTDcFrjDzRQR74tIsc=; b=dxquERLyqdx5IgrHHmsW8N1SYizHj+KnDdB59xuSN1LMJdhAHxThOyyA8jIV03y+GP EsIZSOeu8Z390FSbsUG8a2J1CZ2UHIeVGwamAAqUP38EmkZdv5HdrJNvlCTYF4VxpbeQ lDXolej+0nx1Y40TpELWzpMWhHo0qJwk6biD+AOv8hAV/pZkLvk3NtXQuDUh4ck3DWi/ wh3grL14K+5ByB2CCzJJOuQOmu/3eWqI6zyK/Wk2g67LHJRLc+ivGBFyxGc7+W75wDMp FlGgxXhXQXg+DX2SN1o58/PA6F6sglmOzfk0xPT4mZqEwPzg93+vQOxlMt2NvKl96OQc cFmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HdM70hYOI4KJMyjcLQyiibec9gTDcFrjDzRQR74tIsc=; b=Amk+K7O1pwSJaFj8bUwx+tUtJuVTTIoYXCntDHEWwhSjeAq/OhfqBRW+gleX3aRQvI yBfDRrXwKUHI0D5PGndWEMnuMudeddrXY6iplmx7xN3Cx7v25k172x9pDvVg3vAu4i6r 82LWcp63QoFLoZeEQtM+TojFIsx1hwgV1BXCHxPzdcyVn2UnQnNp53J6aIWs926TYiB9 71PHf8X2bG7eIOLy0Fhj/kpowz93YROTrtULdNosZaPAngTJ5m2+vFtKj0q+y2Q84t0v dwxzhWlbbz3nXsEgWQTXqiaf8WItSB5qx7NxiHpbjJPTPJRZ1zkfcGoAKaF5jahCUnP5 iK4w==
X-Gm-Message-State: AN3rC/5Ul3lmuZ46mwNnxSnlCm/fbKqakJJsIazTEEJR9T75AQRRxbzQ F1yHOxqpw1hJKb9yJsQi5AN6dv4yCSYv
X-Received: by 10.28.5.8 with SMTP id 8mr701206wmf.70.1493266298478; Wed, 26 Apr 2017 21:11:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.120 with HTTP; Wed, 26 Apr 2017 21:11:37 -0700 (PDT)
In-Reply-To: <CAG4d1reMAu0YmTfPnStYFx1DotDpwnuGP3BM8ks5-YA1XxrKtA@mail.gmail.com>
References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <f366eb05-b82c-123e-d0ca-8701fe16a469@nostrum.com> <CAHbuEH5vDjZ5tSt=314Dquju7N26XSOqQPNjV=jO6D8Xn7QVdQ@mail.gmail.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <CAHbuEH5OX-GiwF7zqWmks5k6yLj5SXvXwYVFjCChrsa_ckokwQ@mail.gmail.com> <f6ac64b0-1e50-b02f-7043-8cae2cd56020@nostrum.com> <CAHbuEH7B=bzknZnfF_qsE435peOOd8XYjd=YKREeXw0RW18aGA@mail.gmail.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> <CAG4d1reMAu0YmTfPnStYFx1DotDpwnuGP3BM8ks5-YA1XxrKtA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Thu, 27 Apr 2017 00:11:37 -0400
Message-ID: <CAG4d1rfn2Eb3oFQmUtxH970UXv27=0yNURUNhBEoeFcpW6OMfw@mail.gmail.com>
Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT)
To: Adam Roach <adam@nostrum.com>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-rtgwg-yang-key-chain@ietf.org, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="001a1144369a46a54d054e1e2747"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/SLawpCo7vyfOBI0Ci8BIqWsPP8M>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2017 04:11:42 -0000
One last piece (sorry to top-post, but scanning the relevant security considerations piece in version -20): With this model, any user/group can read the operational state via YANG model and that would, by default, include unencrypted keys being transmitted. If NACM is supported, then only certain users/groups would be able to access the keys. Without NACM, using the KEK ensures that even if a user/group receives the operational state of the YANG model, the keys aren't unencrypted. Thus the user/group would need to have access to the key used in KEK. Does this match up with your understanding? I think that Kathleen's Discuss is just asking for a paragraph - perhaps in 3.2 or a new 3.2.1 that describes the above and that the key-handling for KEK is out-of-bounds. Regards, Alia On Thu, Apr 27, 2017 at 12:02 AM, Alia Atlas <akatlas@gmail.com> wrote: > I am just catching up on this conversation. > > First, the YANG model is primarily for information in motion - either for > configuration to the device > or to read from the device. It is much less likely to represent the data > structure and storage in the device. > I believe that this draft's context is strictly for information in motion. > > This YANG model, as with all, is intended for transport over NetConf or > RestConf, which are confidential > transports. Thus, any keys sent in the YANG model are already protected > in flight. > > However, to allow for the limited cases (as I understand it) where that > isn't viewed as sufficient protection, > the key might be sent encrypted (via KEK) so it is encrypted before being > handed to the model, the configuration > action would be with the encrypted key, and then the device would have to > know how to decrypt it, which is all > out-of-band behavior as far as the YANG model and associated protocols go. > > The gotcha - and why, as I understand it, that encrypted keys are even > mentioned is that it alters the data type > used for transmitting the key as in the snippet below. Normally the > keystring would be a string, but if encrypted, > it is a hex-string - so arbitrary bytes. > > "+--rw key-string > > | +--rw (key-string-style)? > | +--:(keystring) > | | +--rw keystring? string > | +--:(hexadecimal) {hex-key-string}? > | +--rw hexadecimal-string? yang:hex-string > " > > This draft isn't trying to describe how or whether to use KEK. It's just > making sure the YANG model is sufficient > general to transmit the key if it is previously encrypted. > > Does that make sense and help clarify? > > Regards, > Alia > > > On Wed, Apr 26, 2017 at 11:00 PM, Adam Roach <adam@nostrum.com> wrote: > >> On 4/26/17 9:34 PM, Kathleen Moriarty wrote: >> >>> The final paragraph, I believe is referring to how the key is stored - >>> either a KEK is used and it's encrypted or it's not and it's advising >>> obfuscation at a minimum. >>> >> >> That's how I read it too: it's talking about how the key is stored. If >> it's encrypted with a real crypto operation, it's going to have a KEK >> (which isn't necessarily the same KEK as is used to decrypt the information >> received from a remote node, right?); and, if it's obfuscated, it doesn't >> even necessarily have a key at all, just some kind of reversible >> transformation. >> >> Let's focus on the "obfuscation" case, because I think it's easier to >> reason about (and less likely to get conflated with other operations), and >> then we can extend that reasoning to the crypto case if we come to >> agreement. I'm making certain assumptions here which you may have a >> different read on (and, as before, this is your area, so I'd take your >> assumptions over my own) -- please correct me where I'm overstating or >> misstating things. >> >> In the obfuscation case -- and barring any advanced anti-debugger and >> anti-ICE defenses -- reverse-engineering the obfuscation technique would be >> a fairly straightforward exercise. So I think we can safely assume that any >> such obfuscation performed by popular routers will be reversible by your >> average black-hat hacker. >> >> That seems to negate most of the benefit obtained by obfuscation. >> >> At the same time, an administrator observing that the stored value is not >> the same as the actual key may make the erroneous assumption that the >> on-disk value itself is not particularly high value, and may take steps >> that make it more likely to fall into the hands of an attacker than if the >> administrator saw the literal key present in the configuration. >> >> That seems to make the obfuscation potentially harmful. >> >> Little benefit with possible harm would, to me, indicate that obfuscation >> should not be employed. >> >> >> >> Does that help? I'll defer to the authors and AD and get back to the >>> part of the thread where I'm hoping we can add the KEK back into the >>> draft. >>> >> >> I hope so too. As a process point: removing this from the document seems >> like a material change. If this went through WGLC and IETF LC with the KEK >> as part of the data model, I would think its removal would require WG >> buy-in, and running through IETF LC again. >> >> /a >> >> >
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Acee Lindem (acee)
- Kathleen Moriarty's Discuss on draft-ietf-rtgwg-y… Kathleen Moriarty
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Kathleen Moriarty
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Adam Roach
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Acee Lindem (acee)
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Adam Roach
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Kathleen Moriarty
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Acee Lindem (acee)
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Kathleen Moriarty
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Adam Roach
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Kathleen Moriarty
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Brian Weis (bew)
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Alia Atlas
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Alia Atlas
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Adam Roach
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Kathleen Moriarty
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Kathleen Moriarty
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Eric Rescorla
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Alia Atlas
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Adam Roach
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Acee Lindem (acee)
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Acee Lindem (acee)
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Alia Atlas
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Eric Rescorla
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Acee Lindem (acee)
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Alia Atlas
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Kathleen Moriarty
- Re: Kathleen Moriarty's Discuss on draft-ietf-rtg… Kathleen Moriarty