Subject: [Netconf] Security AD comments for draft-ietf-netconf-access-control-05.txt

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 25 Oct 2011 23:15:04 +0200

Editors/authors, pls take a look at these and make changes as
you see fit. If there is anything that you think we need
to get WG concensus on, pls let me know. I still have to read/check
the details myself, wanted to send this to WG list asap.

Bert
----------------------------
draft-ietf-netconf-access-control-05 comments
SF, 2011-10-24

General questions:

1) How do you contol access when a rule-set is managed by Alice but
Bob updates the server code to deploy new protocol operations? Does
it say somewhere that Alice and Bob need to talk? Or maybe that
Bob's new code should figure its running for the 1st time with an
existing config and send some kind of notification, and should
Alice's config include something to say where?

2) Do you need to have any security considerations about odd
username strings, e.g. would it be possible to authenticate as
"stephen\[email-masked]" and for an access control implementation
to treat me as "stephen"?

other comments

- be good if 1st sentence of 2.2 had a reference but I understand
why you might be shy - the X.500 access control scheme however may
be fair game:-)

- (total nit) "MUST be authorized" near top of p13 is ambiguous.  It
could mean you "MUST let it happen" or (the actual intent I assume)
"MUST be checked"

- 3.2 says that local/remote file access via URLs is "optional to
support." a) what does that mean? that being able to query/return a
file is OPTIONAL or that applying the access control model is
OPTIONAL?  b) shouldn't there be some 2119 language there?

- I didn't get the 2nd para of 3.2.3 but I expect that's just a lack
of background. I guess in my ignorance I'd wonder if there are any
operations with default-operation=none that are actually sensitive -
if so, then not doing access control might be bad. Can you confirm
that there are no such operations?

- 3.2.3 3rd last para: If I had a container called "bagOfStuff" that
has within it "whoCares" (not sensitive) and "veryImportant"
(sensitive) and there's an ACL that allows me full access to
everyhing in bagOfStuff except veryImportant but there's another ACL
that gives me full access to "noBodyCares/*" then could I rename
bagOfStuff to noBodyCares/bagOfStuff and thence get access to
veryImportant?

- 3.3.2 - are Group names ever sent over the wire? If so, how're
they handled/encoded? ("Administerung" vs. "Administrators" was an
old msft glitch;-) If they're not sent over the wire, then maybe
saying that will fend off some I18N discusses so might be worth it.

- 3.3.3.1 - I assume setting enable-nacm=false is protected, right?

- What is the "acme NS" in Figure 3?

- In 3.4.4 do you need to say that this algorithm MUST be separately
run for each <rpc> element in a received request?  The concern would
be someone sending a single packet meaning "close-session then
open-session&do-bad-thing" - if the message handler only looked at
the start of the message then it'd do the wrong thing. That might be
handled elsewhere but might still be worth stating to help coders.
(And "validates the <rpc> element" might not be quite specific
enough perhaps.)

- In 3.4.4 its not clear to me how the "transport layer" can provide
group memberships - did I miss that?

- In 3.4.4, maybe I'm confused but skipping from step 5 to 10 for a
user who's a member of no groups seems to mean that rules can only
be defined for goups - is that right? (Same question later as well
in 3.4.5)

- I don't get what session is used in 3.4.6? (Confused again:-)

- I just flicked quickly through 3.5.2 since I'm no YANG expert;-)

- 3.7.1 - s/ot it/or it/?

- I didn't go through appendix A really.

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: "Sean Turner" <[email-masked]>; "Romascanu, Dan (Dan)" 
<[email-masked]>; "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>; 
"Andy Bierman" <[email-masked]>; "Martin Bjorklund" <[email-masked]>
Sent: Tuesday, October 25, 2011 3:41 PM
Subject: Re: Reminder: Security Advisor review PLEASE for 
draft-ietf-netconf-access-control-05.txt

>
> Hi Bert,
>
> So Sean and I looked at this and we both think its
> on the right track so there's certainly no major huge
> problem looming.
>
> Being a bit more anal about things in general, I wrote
> some notes (attached) that might be useful. We can chat
> about those if you like. Note: I'm not saying that any
> or all of those would or would not turn into discusses
> so treating 'em as early last-call feedback is probably
> about right.
>
> Cheers,
> S.
>
> On 10/20/2011 01:45 PM, Bert Wijnen (IETF) wrote:
>> OK, great.
>> WG last call ends this weekdn.
>>
>> I herewith ask the authors/editors to wait for your
>> comments as well. I trust that we will see them by Tuesday
>> then.
>>
>> Thanks,
>> Bert
>> document shepherd
>>
>> On 10/20/11 2:38 PM, Stephen Farrell wrote:
>>>
>>> Hi Bert,
>>>
>>> Sean's done. I'm not. We're gonna talk about it Tuesday
>>> (after I've had a read) and get back to you then.
>>>
>>> Sorry for being the slow coach here;-)
>>>
>>> S.
>>>
>>> On 10/20/2011 01:33 PM, Bert Wijnen (IETF) wrote:
>>>> Hi Sean and Stephen,
>>>>
>>>> how are you doing on your review?
>>>>
>>>>
>>>> Thanks,
>>>> Bert
>>>> document shepherd
>>>>
>>>> On 10/5/11 5:12 PM, Bert Wijnen (IETF) wrote:
>>>>> Great (well the fact that you and Stephen will take a
>>>>> look next week, not that fact that you could not find
>>>>> any takers). Looking forward to any comments you may have.
>>>>>
>>>>> Bert
>>>>>
>>>>> On 10/5/11 4:50 PM, Sean Turner wrote:
>>>>>> We tried to rope in an additional reviewer. We got no takers. Stephen
>>>>>> and I will have a look next week.
>>>>>>
>>>>>> spt
>>>>>>
>>>>>> On 10/5/11 7:55 AM, Bert Wijnen (IETF) wrote:
>>>>>>> On 9/21/11 4:57 PM, Sean Turner wrote:
>>>>>>>> We're going to search for a new advisor.
>>>>>>>
>>>>>>>> If we can't find one, we'll get the SECDIR secretary to assign an
>>>>>>>> early reviewer.
>>>>>>>>
>>>>>>>> spt
>>>>>>>>
>>>>>>>
>>>>>>> So, a revised version of the document is out (trying to address
>>>>>>> all previous WGLC comments). We as WG chairs have put out a new
>>>>>>> WG Last Call for draft-ietf-netconf-access-control-05.txt
>>>>>>> which runs till Okt 21st 2011.
>>>>>>>
>>>>>>> After that finishes we expect to soon request our AD for
>>>>>>> an IETF Last Call to consider this document for PS.
>>>>>>>
>>>>>>> So review by a SEC advisor or early review by a SEC Area
>>>>>>> reviewer would be very much appreciated. The whole document
>>>>>>> is about security for Access Control to NetConf operations and data.
>>>>>>>
>>>>>>> Bert and Mehmet
>>>>>>> Netconf WG chairs.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Oct 2011 10:06:13 -0700

> the details myself, wanted to send this to WG list asap.

We will discuss it and have a NACM update done soon.
See inline for some more comments.

> Bert

A different NETCONF draft specifies the notifications to send when
a config datastore is changed.  Bob and Alice have to coordinate off-line
wrt/ specific device configuration changes, and their impact on access control config.
(This is no different than when I have to go through Engineering Lab Services at work
to get a new server setup in the lab net -- you have some off-line mechanism
to request that an authorized user make the config changes.)

> to treat me as "stephen"?

NACM sort of punts the username management corner-cases to the administrator.
They have to make sure all user names resolve to unique and correct NETCONF
user names.

> other comments

We will go through these and fix the draft as needed.

> ----- Original Message ----- From: "Stephen Farrell" <[email-masked]>
> Cc: "Sean Turner" <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>; "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>; "Andy Bierman" <[email-masked]>; "Martin Bjorklund"
> <[email-masked]>
> Subject: Re: Reminder: Security Advisor review PLEASE for draft-ietf-netconf-access-control-05.txt
>
>
>>
>> Hi Bert,
>>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 26 Oct 2011 19:16:11 +0200

> See inline for some more comments.

I believe the deadline for revisions of I-Ds is this coming Monday
So if you can do it before that time, that would be great.

   2011-10-31 (Monday): Internet Draft final submission cut-off
   by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Oct 2011 10:22:41 -0700

> So if you can do it before that time, that would be great.

of course! May just make the deadline by minutes, though...

> by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Oct 2011 11:44:39 -0700

On 10/26/2011 11:25 AM, Stephen Farrell wrote:
>
> Hi Andy,
>
> A few follow-ups below. I don't mind if we try bottom out
> on these now or you leave 'em for later - whichever's better
> for you/the WG is fine.
>
> On 10/26/2011 06:06 PM, Andy Bierman wrote:
> Not sure if I was clear enough in the question but that maybe
> (partly) answers a slightly different question.
>
> My question related to when the server code changes, not
> when the config datastore changes. I.e. Alice does the datastore
> admin but Bob installs new server code.
>
> The danger there is that the new server code has some new
> feature that's accessible according to the existing config
> (due to some wildcard or whatever) but that ought not be. Say
> that the current config says that "foo/*" is accessible
> to the world, because that's ok with the current s/w, but the
> s/w update creates a new "foo/explode" knob that kills
> something. With the new s/w and the current config, "foo/explode"
> would, I think, also be world accessible, which could be bad,
> depending what explode means.
>
> Since its (I think) impossible to automatically handle that
> in general, the question is whether you might recommend that
> the new code notify Alice when first run.
>
> That notification I've in mind might say something like "Hi
> Alice, Version 2.10 of <s/w> has just started running on
> node <X> for the first time, (previously version 2.8). You may
> need to update your config, see <URL>."
>
> I'm not asking that you definitely do that, but really whether
> you've thought about that, because that wasn't clear to me
> reading the draft.
>

I will add something to the SC section that warns administrators
that changing software images, and perhaps other mechanisms, can alter
the NETCONF content available to a given user, and care must
be taken to insure no unintended access is allowed. NETCONF <hello>
messages contain a URI summary of all the content supported by the server,
called the server capabilities.

The system notifications also has capability change events.
If a new image or current image has any different data models or capabilities than
it did before, the client can know about it via NETCONF netconf-capability-changed
notifications.  Implementation of the system notifications draft is not coupled to NACM
in any way.  I can add text that suggests this draft is implemented
to warn administrators of security threats due to changing capabilities.

>> They have to make sure all user names resolve to uique and correct NETCONF
>> user names.
>
> I'd like to more-than-sort-of understand if the above corner-case
> is likely to be a gotcha or not;-) That basic trick was used in X.509
> certs for web sites in the wild and worked in some places for some
> time. It might well be that any change needed isn't for this spec
> but the problem might hit when you do access control so it may well
> be worth a reference to the relevant part of some other netconf
> spec from this one, or to just warn about the need to ensure that
> the identifiers use in access control are the right ones as a
> security consideration, with an example like the above (if it is
> a real potential vulnerability).

We will try to add some security consideration text emphasizing this
sort of user identity management issue.

> Cheer,

Andy

>>> <[email-masked]>; "Ersue, Mehmet (NSN - DE/Munich)"
>>> <[email-masked]>; "Andy Bierman" <[email-masked]>; "Martin
>>> Bjorklund"
>>> <[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Oct 2011 19:25:33 +0100

Hi Andy,

Cheer,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Oct 2011 20:27:48 +0100

Hi Andy,

I think those would be fine additions.
Thanks for considering them,

Cheers,
S.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Oct 2011 08:37:35 +0200

> a real potential vulnerability).

RFC6241 says:

   The authentication process MUST result in an authenticated client
   identity whose permissions are known to the server.  The
   authenticated identity of a client is commonly referred to as the
   NETCONF username.  The username is a string of characters that match
   the "Char" production from Section 2.2 of [W3C.REC-xml-20001006].

Would it make you happy to point to this with some explicit text that
implementations have to make sure they handle any legal username as a
name and nothing else?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Oct 2011 12:28:22 +0100

Hi Juergen,

> implementations have to make sure they handle any legal username as a

Something like that would be good. I've seen slip-ups happen
between authentication and authorization code a good few times
so whatever helps avoid that is good.

Ta,
S.

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 31 Oct 2011 22:01:06 +0100

This revision 06 has just been posted.
If you wan to check if your comments have been
properly addressed (or answerd), pls do so.

The diff is here:
http://tools.ietf.org/wg/netconf/draft-ietf-netconf-access-control/draft-ietf-netconf-access-control-06-from-05.diff.html

I think we're ready for the next step, namely
hand it over to our AD for IETF Last Call.

Bert Wijnen,
Document shepherd.