On 3/15/2017 6:32 PM, Kent Watsen wrote:
Benoit,
I fixed this text in my drafts already. Actually, I found the old
text difficult to
read, so I fixed it like this:
The YANG module defined in this document is designed to be accessed
via YANG based management protocols, such as NETCONF [RFC6241
<https://tools.ietf.org/html/rfc6241>] and
RESTCONF [RFC8040 <https://tools.ietf.org/html/rfc8040>]. Both of
these protocols have mandatory-to-
implement secure transport layers (e.g., SSH, TLS) with mutual
authentication.
The NETCONF access control model (NACM) [RFC6536
<https://tools.ietf.org/html/rfc6536>] provides the means
to restrict access for particular users to a pre-configured subset of
all available protocol operations and content.
(from:
https://tools.ietf.org/html/draft-ietf-netconf-keystore-01#section-4).
I like the "YANG based management protocols" part
Trying the combine the different proposals:
The YANG module defined in this document is designed to be accessed
via YANG based management protocols, NETCONF [RFC6241
<https://tools.ietf.org/html/rfc6241>] or
RESTCONF [RFC8040 <https://tools.ietf.org/html/rfc8040>]. The lowest
NETCONF layer is the secure transport layer,
and mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242],
while the lowest RESTCONF layer is HTTP, and the
mandatory-to-implement secure
transport is Transport Layer Security (TLS) [RFC5246].
The NETCONF access control model [RFC6536] provides the means to
restrict
access for particular NETCONF or RESTCONF users to a pre-configured
subset
of all available NETCONF or RESTCONF protocol operations and content.
Related, I wasn't entirely sure how to handle the situation where a
draft uses
groupings from another draft. Does it simply point to the other
draft's Security
Considerations, or recreate them in its Security Considerations
section? For now,
I chose the former, for instance:
The YANG module defined in this document uses groupings defined in
[I-D.ietf-netconf-ssh-client-server
<https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#ref-I-D.ietf-netconf-ssh-client-server>]
and [I-D.ietf-netconf-tls-client-server
<https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#ref-I-D.ietf-netconf-tls-client-server>].
Please see the Security Considerations section in those documents for
concerns related those groupings.
I believe this is the right approach.
Regards, Benoit
(from:
https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#section-5)
Thanks,
Kent // contributor
-----ORIGINAL MESSAGE------
On 3/15/17, 12:45 PM, "netmod on behalf of Benoit Claise"
<[email protected] <mailto:[email protected]> on behalf of
[email protected] <mailto:[email protected]>> wrote:
Dear all,
[copying the security ADs to make sure the new security section is fine]
Let's separate the two issues
1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt
Basically, I agree with Jürgen
I see section 4.7:
This section MUST be patterned after the latest approved template
(available athttp://trac.tools.ietf.org/area/ops/trac/wiki/
<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>
yang-security-guidelines
<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>).Section
7.1
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-7.1>
contains the security
considerations template dated 2013-05-08. Authors MUST check the WEB
page at the URL listed above in case there is a more recent version
available.
Then, I see section 7:
The following section contains the security considerations template
dated 2010-06-16.
Not sure why it contains this cut/paste? It should just say: the
latest version is at this URL.
Then, I see in the same section:
This section MUST be patterned after the latest approved
template (available at
http://www.ops.ietf.org/netconf/yang-security-considerations.txt
This page is not found.
This should be corrected in rfc6087bis.
2. the new security guidelines must include RESTCONF.
At this point, this is a blocking factor for the publication of YANG
module. As an example,
draft-ietf-lmap-yang-11
<https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/>, A YANG Data
Model for LMAP Measurement Agents, on the telechat tomorrow.
As mentioned the most up to date version is
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
Here is the proposal, discussed on the YANG doctors list:
OLD
The YANG module defined in this memo is designed to be
accessed via the NETCONF protocol [RFC6241]. The lowest
NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The NETCONF access control model [RFC6536] provides
the means to restrict access for particular NETCONF users to a
pre-configured subset of all available NETCONF protocol
operations and content.
NEW
The YANG module defined in this memo is designed to be
accessed via the NETCONF [RFC6241] or RESTCONF [RFC8040]
protocol. The lowest NETCONF layer is the secure transport
layer, and mandatory-to-implement is Secure Shell (SSH)
[RFC6242], while the lowest RESTCONF layer is HTTP, and the
mandatory-to-implement secure transport is Transport Layer
Security (TLS) [RFC5246].
The NETCONF access control model [RFC6536] provides the means
to restrict access for particular NETCONF or RESTCONF users to
a pre-configured subset of all available NETCONF or RESTCONF
protocol operations and content.
Any objections?
Have covered all that we need for the new RESTCONF protocol?
Regards, Benoit
Hi,
this came up during IESG processing of a YANG module - is there a new
security guideline boilerplate text covering RESTCONF? This was
briefly discussed on the yang-doctors but somehow the discussion
stopped because RESTCONF was not published yet at that time. I think
this affects draft-ietf-netmod-rfc6087bis-12.txt.
draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read
online documents - why do we need several points? I think some are
also not working. Ideally, there should be a single stable URL.
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
