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.
Thanks Acee On 4/26/17, 12:34 PM, "rtgwg on behalf of Kathleen Moriarty" <[email protected] on behalf of [email protected]> 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 >[email protected] >https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
