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