Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT)

[Kathleen Moriarty <[e-mail]>]

Hi Acee,

Adding Brian since he may be able to assist since he is familiar with
other implementations with YANG modules.

On Wed, Apr 26, 2017 at 12:52 PM, Acee Lindem (acee) <[e-mail]> wrote:
> Kathleen,
>
> The lack of KEK specification is not a problem with the YANG key-chain
> model, it with RFC 5649 and KEK. I’d request that yourself or someone in
> the security area provide a reference or text. A primary reason KEK has
> not been widely deployed is that RFC 5649 is woefully lacking in
> operational guidance. If you can’t do this, I’ll remove the reference and
> rely on NCACM similar to the shared-secret data node in RFC 7317.

I'm not following you as to what is lacking, if you could please
expand on that it would be appreciated and then we can assist more.
RFC 3394 and RFC5649 are widely deployed according to the author.  Do
you mean deployed specific to YANG modules or something else?

Does the following guidance help:

    If you want to wrap an AES key and nothing else, use RFC 3394
    If you want to wrap an AES key and some other attributes too, use RFC 5649

I think it would be better to have the text from the -20 version in
the body of the document (rather than security considerations
section), I see it was removed in -21.  Then have the considerations
for using/not using in the security considerations section.  I think
Brian's responses help cover some of what would go into the text for
the security considerations section.

Is this the text provided what you need help with or is it something
additional for developers?  By implementors, are you referring to the
developers or operators configuring the devices?  I just want to be
sure we are clear on the problem so we can assist.

Thank you,
Kathleen

>
> Thanks
> Acee
>
> On 4/26/17, 12:34 PM, "rtgwg on behalf of Kathleen Moriarty"
> <[e-mail] on behalf of [e-mail]>
> wrote:
>
>>Kathleen Moriarty has entered the following ballot position for
>>draft-ietf-rtgwg-yang-key-chain-20: 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-rtgwg-yang-key-chain/
>>
>>
>>
>>----------------------------------------------------------------------
>>DISCUSS:
>>----------------------------------------------------------------------
>>
>>Thanks for your work on this draft.  There is one outstanding issue from
>>the SecDir review that may require some updated text to resolve.  It
>>seems use of the key wrap method in RFC5649 requires more guidance for
>>implementations to use it with this YANG module.  It's good to know that
>>this is in use for other modules, so having a clear reference either to
>>another draft or the text being in this draft for later reference would
>>be helpful.
>>
>>In looking at this text within the draft, I think it would be better to
>>pull the text out of the Security Considerations section and into an
>>earlier section of the draft.  It's better to introduce this prior to
>>enumerating security considerations for the draft since this something
>>that would be implemented.  Then security considerations should mention
>>the considerations of using this option versus just what's in NACM.
>>
>>You have the text:
>>
>>  When configured, the key-strings can be encrypted using the AES Key
>>   Wrap algorithm [AES-KEY-WRAP].  The AES key-encryption key (KEK) is
>>   not included in the YANG model and must be set or derived
>>independent
>>   of key-chain configuration.  When AES key-encryption is used, the
>>   hex-key-string feature is also required since the encrypted keys
>>will
>>   contain characters that are not representable in the YANG string
>>   built-in type [YANG].  AES key-encryption MAY be used for added key
>>   security in situations where the NETCONF Access Control Mode is not
>>   available.
>>
>>I think it's pretty straightforward after looking at RFC5649, but maybe
>>more text would be helpful to clarify for implementers.  This might mean
>>more text from 5649 on what gets placed in the YANG data model where you
>>have already allocated for this or including an example.
>>
>>
>>----------------------------------------------------------------------
>>COMMENT:
>>----------------------------------------------------------------------
>>
>>Thank you for working through the SecDir review and making the suggested
>>updates.
>>
>>Since the following text int he Security Considerations section is a
>>recommendation, IMO it would be better to drop "or otherwise obfuscated"
>>from the sentence as encrypting the keys really should be the
>>recommendation.  Can we make this update?
>>
>>   It is RECOMMENDED that keys be encrypted or otherwise obfuscated
>>when
>>   stored internally on a network device supporting this specification.
>>
>>If obfuscation is what happens more often in practice, maybe mention this
>>as a fallback from the recommendation, but not make them sound
>>equivalent?
>>
>>
>>_______________________________________________
>>rtgwg mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/rtgwg
>



-- 

Best regards,
Kathleen