Subject: Re: [Netconf] Issue X: access to notification content

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 2 May 2008 11:22:01 -0400

Hi

The originator of the discuss was satisfied that his concerns were
addressed, I think you are raising different issues. The problem is that
the access control model is not yet defined and we need to be careful
about the assumptions we make about it. We also need to be careful to
not confuse authorization with how the information is actually available
(synchronous/asynchronous, NETCONF/Syslog/SNMP).

We do have the open question about the access control model on those
implementations that are tunnelling syslog or SNMP traffic in NETCONF.
Another reason I'm not a fan of this feature. In a lot of
implementations I expect these to map to a single underlying
authorization model, but since nothing has been standardized in the
IETF, we can't make that assumption here. Is this something we should
solve now or as part of the access control discussion? Presumably it
applies to notification and <get> traffic equally. I think it should be
solved more generally.

By proposed text, did you mean: 

"she probably should not ... depending on the access control model and
administrative policy." 

Which From [email-masked]  Fri May  2 08:22:38 2008
Content-class: urn:content-classes:message
Date: Fri, 2 May 2008 11:22:01 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "David B Harrington" <[email-masked]>,
	"Bert Wijnen - IETF" <[email-masked]>, <[email-masked]>
Subject: Re: [Netconf] Issue X: access to notification content
Sender: [email-masked]

Hi

The originator of the discuss was satisfied that his concerns were
addressed, I think you are raising different issues. The problem is that
the access control model is not yet defined and we need to be careful
about the assumptions we make about it. We also need to be careful to
not confuse authorization with how the information is actually available
(synchronous/asynchronous, NETCONF/Syslog/SNMP).

We do have the open question about the access control model on those
implementations that are tunnelling syslog or SNMP traffic in NETCONF.
Another reason I'm not a fan of this feature. In a lot of
implementations I expect these to map to a single underlying
authorization model, but since nothing has been standardized in the
IETF, we can't make that assumption here. Is this something we should
solve now or as part of the access control discussion? Presumably it
applies to notification and <get> traffic equally. I think it should be
solved more generally.

By proposed text, did you mean: 

"she probably should not ... depending on the access control model and
administrative policy." 

Which I proposed to change to

"she likely will not ... depending on the access control model and
administrative policy." 

Sharon 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2008 5:53 PM
To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; [email-masked]
Subject: RE: Issue X: access to notification content

Hi,

I don't think your proposed change addresses the security review
concern. It doesn't say how access will be controlled.

I think my proposed text does, by saying it will be handled by the
access control model and adminstrative policy.

Is there a reason you don't find my proposed text acceptable?

dbh

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2008 2:39 PM
> To: David B Harrington; Bert Wijnen - IETF; [email-masked]
> Subject: RE: Issue X: access to notification content
> 
> Hi
> 
> I can change from "she must not" to "she likely will not". I think
the
> probably softens things too much. The intent is that you only get to 
> view content you have permission to view, regardless of the access 
> mechanisms.
> 
> Sharon
> 
> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2008 10:25 AM
> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); 
> [email-masked]
> Subject: RE: Issue X: access to notification content
> 
> Hi,
> 
> If it is only a discussion, then I suggest rewording "she must not 
> ..."
> to "she probably should not ... depending on the access control
model
> and administrative policy." 
> 
> This does not create a CLR.
> 
> dbh
> 
> > -----Original Message-----
> > From: Bert Wijnen - IETF [mailto:[email-masked]]
> > Sent: Tuesday, April 29, 2008 2:41 AM
> > To: David B Harrington; 'Sharon Chisholm'; [email-masked]
> > Subject: RE: Issue X: access to notification content
> > 
> > Dave, this is a clarification to an concern from an IESG member.
> > It is in the "Security Considerations" section, so it is
> not a "hard
> > choice of protocol standard". We are explaining in the security 
> > considerations section what kind of access concerns there might
be. 
> > Does that clarify?
> > 
> > Sharon, do you have other comments on Dave's concern?
> > 
> > Bert Wijnen
> > 
> > > -----Oorspronkelijk bericht-----
> > > Van: David B Harrington [mailto:[email-masked]]
> > > Verzonden: maandag 28 april 2008 19:28
> > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; [email-masked]
> > > Onderwerp: Issue X: access to notification content
> > > 
> > > 
> > > Hi bert,
> > > 
> > > There were a bunch of issues I raised on 4/23 that I think
> > Sharon just
> > > didn't understand and didn't fix. here's one:
> > > 
> > > --
> > > In section 7, the text says "If a user does not have
> > >    permission to view content via other NETCONF operations, she
> must
> > > not
> > >    have access to that content via Notifications." 
> > > 
> > > This creates a big CLR.
> > > 
> > > Can content from a syslog or SNMP notification stream be
> sent to a
> > > user that does not have permission to access the syslog or SNMP 
> > > content using some other Netconf operation? What other Netconf 
> > > operation works with the syslog stream? Didn't we
> > explicitly decide it
> > > was not necessary to support <get> access to notication streams 
> > > (including syslog and SNMP streams)?
> > > 
> > > I am also concerned that this access control "policy" 
> should be an
> > > administrative one, not a hard choice of the protocol
> standard. In
> > > most cases it is the right choice. But a NOC manager
> might want to
> > > allow, say, the helpdesk to be alerted whenever a Netconf config
> is
> > > being changed, or an intrusion detection application to
> be alerted
> > > when there is an authentication failure. And yet, they may
> > not want to
> > > give the helpdesk or the IDS <get> permissions. With this CLR, a
> NOC
> > > manager is simply not allowed to make such a decision.
> > > 
> > > I understand the intent; I think the wording is poorly chosen, 
> > > especially because it uses a "must", which has special
> > RFC2119 meaning
> > > and creates a huge CLR. And since access control will be
> > done later, I
> > > don't think the WG wants this CLR constraining all future
> > AC designs. 
> > > 
> > > But I could be wrong; maybe the WG will decide this is exactly
> what
> > > they want to say. If that is the case, then I think we need
> > to review
> > > this document to make sure everything else (like syslog streams)
> can
> > > work with this CLR.
> > > 
> > > dbh
> > > 
> > > 
> > 
> 
> 

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

I proposed to change to

"she likely will not ... depending on the access control model and
administrative policy." 

Sharon 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2008 5:53 PM
To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; [email-masked]
Subject: RE: Issue X: access to notification content

Hi,

I don't think your proposed change addresses the security review
concern. It doesn't say how access will be controlled.

I think my proposed text does, by saying it will be handled by the
access control model and adminstrative policy.

Is there a reason you don't find my proposed text acceptable?

dbh

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2008 2:39 PM
> To: David B Harrington; Bert Wijnen - IETF; [email-masked]
> Subject: RE: Issue X: access to notification content
> 
> Hi
> 
> I can change from "she must not" to "she likely will not". I think
the
> probably softens things too much. The intent is that you only get to 
> view content you have permission to view, regardless of the access 
> mechanisms.
> 
> Sharon
> 
> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2008 10:25 AM
> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); 
> [email-masked]
> Subject: RE: Issue X: access to notification content
> 
> Hi,
> 
> If it is only a discussion, then I suggest rewording "she must not 
> ..."
> to "she probably should not ... depending on the access control
model
> and administrative policy." 
> 
> This does not create a CLR.
> 
> dbh
> 
> > -----Original Message-----
> > From: Bert Wijnen - IETF [mailto:[email-masked]]
> > Sent: Tuesday, April 29, 2008 2:41 AM
> > To: David B Harrington; 'Sharon Chisholm'; [email-masked]
> > Subject: RE: Issue X: access to notification content
> > 
> > Dave, this is a clarification to an concern from an IESG member.
> > It is in the "Security Considerations" section, so it is
> not a "hard
> > choice of protocol standard". We are explaining in the security 
> > considerations section what kind of access concerns there might
be. 
> > Does that clarify?
> > 
> > Sharon, do you have other comments on Dave's concern?
> > 
> > Bert Wijnen
> > 
> > > -----Oorspronkelijk bericht-----
> > > Van: David B Harrington [mailto:[email-masked]]
> > > Verzonden: maandag 28 april 2008 19:28
> > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; [email-masked]
> > > Onderwerp: Issue X: access to notification content
> > > 
> > > 
> > > Hi bert,
> > > 
> > > There were a bunch of issues I raised on 4/23 that I think
> > Sharon just
> > > didn't understand and didn't fix. here's one:
> > > 
> > > --
> > > In section 7, the text says "If a user does not have
> > >    permission to view content via other NETCONF operations, she
> must
> > > not
> > >    have access to that content via Notifications." 
> > > 
> > > This creates a big CLR.
> > > 
> > > Can content from a syslog or SNMP notification stream be
> sent to a
> > > user that does not have permission to access the syslog or SNMP 
> > > content using some other Netconf operation? What other Netconf 
> > > operation works with the syslog stream? Didn't we
> > explicitly decide it
> > > was not necessary to support <get> access to notication streams 
> > > (including syslog and SNMP streams)?
> > > 
> > > I am also concerned that this access control "policy" 
> should be an
> > > administrative one, not a hard choice of the protocol
> standard. In
> > > most cases it is the right choice. But a NOC manager
> might want to
> > > allow, say, the helpdesk to be alerted whenever a Netconf config
> is
> > > being changed, or an intrusion detection application to
> be alerted
> > > when there is an authentication failure. And yet, they may
> > not want to
> > > give the helpdesk or the IDS <get> permissions. With this CLR, a
> NOC
> > > manager is simply not allowed to make such a decision.
> > > 
> > > I understand the intent; I think the wording is poorly chosen, 
> > > especially because it uses a "must", which has special
> > RFC2119 meaning
> > > and creates a huge CLR. And since access control will be
> > done later, I
> > > don't think the WG wants this CLR constraining all future
> > AC designs. 
> > > 
> > > But I could be wrong; maybe the WG will decide this is exactly
> what
> > > they want to say. If that is the case, then I think we need
> > to review
> > > this document to make sure everything else (like syslog streams)
> can
> > > work with this CLR.
> > > 
> > > dbh
> > > 
> > > 
> > 
> 
> 

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 2 May 2008 13:40:53 -0400

> Sent: Friday, May 02, 2008 11:22 AM

That is not what your earlier response said. The proposal in your
response did not include the text after the ellipsis.

I prefer "she probably should not" because "should not" is RFC2119
language.
You might want to stiffen that slightly by making it 
"she probably SHOULD NOT ... depending on the access control model and
administrative policy."

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 2 May 2008 13:40:53 -0400

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 5 May 2008 08:33:12 -0400

Hi

I think it would be helpful to go back to original text we are editing
rather then the snippets. I've modified the second sentence in ways that
I think address the access versus authorization confusion and I think
makes it so we can keep the 'must not'. I think now we don't need to
'depending on access control..." part because we are make a
recommendation about the access control in order to maintain minimal
security. I've added a third option which tries to include those for
comparison. I prefer A.

Current text

The contents of notifications as well as the name of event streams
   may contain sensitive information and care should be taken to ensure
   that it is viewed only by authorized users.  If a user does not have
   permission to view content via other NETCONF operations, she must not
   have access to that content via Notifications.  If a user is not
   permitted to view one element in the content of the notification, the
   notification is not sent to that user.

Proposed text (A)

The contents of notifications as well as the name of event streams
   may contain sensitive information and care should be taken to ensure
   that it is viewed only by authorized users.  If a user does not have
   permission to view the information in the notification, they must not
   have access to that content via Notifications.  If a user is not
   permitted to view one element in the content of the notification, the
   notification is not sent to that user.

Proposed text (B)

The contents of notifications as well as the name of event streams
   may contain sensitive information and care should be taken to ensure
   that it is viewed only by authorized users.  If a user does not have
   permission to view the information in the notification, the access 
   control model and administrative policy probably should not
   allow them access to that content via Notifications.  If a user is
not
   permitted to view one element in the content of the notification, the
   notification is not sent to that user.

I also got rid of the 'she' thing since I think the singular use of
'they' is now grammatically acceptable in these cases.

Sharon 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Friday, May 02, 2008 1:41 PM
To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; [email-masked]
Subject: RE: Issue X: access to notification content

I prefer "she probably should not" because "should not" is RFC2119
language.
You might want to stiffen that slightly by making it "she probably
SHOULD NOT ... depending on the access control model and administrative
policy."

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 5 May 2008 08:33:12 -0400

Hi

Current text

Proposed text (A)

Proposed text (B)

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 7 May 2008 09:30:28 -0400

Hi

If there is no objection to proposal A then I will proceed to make this
change and publish the updated draft.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Monday, May 05, 2008 8:33 AM
To: David B Harrington; Bert Wijnen - IETF; [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content

Hi

security. I've added a third option which trFrom [email-masked]  Wed May  7 06:30:45 2008
Date: Wed, 7 May 2008 09:30:28 -0400

Hi

If there is no objection to proposal A then I will proceed to make this
change and publish the updated draft.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Monday, May 05, 2008 8:33 AM
To: David B Harrington; Bert Wijnen - IETF; [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content

Hi

Current text

Proposed text (A)

Proposed text (B)

Sharon 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]]
Sent: Friday, May 02, 2008 1:41 PM
To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; [email-masked]
Subject: RE: Issue X: access to notification content

ies to include those for
comparison. I prefer A.

Current text

Proposed text (A)

Proposed text (B)

Sharon

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 May 2008 08:06:55 -0400

Hi,

I am NOT OK with option A. Notifications in syslog and in SNMP are
normally sent to an application, which filters and aggregates the
notifications. Such an application might alert an operator to
important notifications, but many just get logged for later analysis.

With the MUST formulation in option A, it becomes a protocol
REQUIREMENT that such application/users CANNOT receive notifications
UNLESS that application is also allowed to perform other Netconf
operations. 

Syslog and SNMP do not contain such a crappy little rule;
Administrators can decide that syslog notifications and/or SNMP
notifications can be sent to a principal that has no other permissions
within syslog or SNMP. But if the operator decides to have syslog or
SNMP information carried over Nertconf, then they MUST give the
receiving principal permission to use some other Netconf operation.

WHY do we need to allow such an application to perform other Netconf
operations? It should be an administrative policy decision to allow
notifications to be sent to a principal that has no other operational
permission in Netconf.

I don't like option B simply because I don't like the way it has been
worded. I suggest:

Proposed Text (C)

"The contents of notifications as well as the names of event streams
may contain sensitive information and care should be taken to ensure
that they are viewed only by authorized users. It is an administrative
policy decision to determine who (or what) is authorized to have
access to the information contained in notifications. It is
RECOMMENDED that if a user is not authorized to view the content in
the notification via other Newtconf operations, then they SHOULD NOT
be authorized to have access to that content via Netconf
notifications. If a user is not authorized to view all elements in the
content of the notification, the notification is not sent to that
user."

dbh

> Sent: Thursday, May 08, 2008 3:53 AM
> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; 
> [email-masked]
> Subject: RE: [Netconf] Issue X: access to notification content
> 
> I am OK with option/proposal A
> 
> Bert Wijnen 
> 
> > Van: Sharon Chisholm [mailto:[email-masked]]
> > Verzonden: woensdag 7 mei 2008 15:30
> > Aan: David B Harrington; Bert Wijnen - IETF; [email-masked]
> > Onderwerp: RE: [Netconf] Issue X: access to notification content
> > 
> > 
> > Hi
> > 
> > > "she probably should not ... depending on the access control
model

> > > > > >    permission to view content via other NETCONF
operations,
> > she
> > > > > > give the helpdesk or the IDS <get> permissions. 
> With this CLR,
> > a
> > > > NOC

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 May 2008 08:06:55 -0400

Hi,

Proposed Text (C)

dbh

model

operations,

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 May 2008 08:51:33 -0700

> Hi,

I agree with Dave's concerns, and support his option (C) text.

I don't even see what other NETCONF operations have to do
with a notification receiver application.  I don't agree
that any additional security is provided by this MUST requirement.

When user A attempts NETCONF operation <foo>, the agent will
authorize the RPC operation at that time.  Why would the agent
even check if <foo> would be authorized in the future, when
the user requests operation <bar>?  I don't know much about
security, but it seems to be a total waste of time to do this.

Andy

> Administrators can decide that syslog notifications andFrom [email-masked]  Thu May  8 09:11:18 2008
Date: Thu, 08 May 2008 08:51:33 -0700
From: Andy Bierman <[email-masked]>
To: David B Harrington <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content
Sender: [email-masked]

> Hi,

I agree with Dave's concerns, and support his option (C) text.

I don't even see what other NETCONF operations have to do
with a notification receiver application.  I don't agree
that any additional security is provided by this MUST requirement.

When user A attempts NETCONF operation <foo>, the agent will
authorize the RPC operation at that time.  Why would the agent
even check if <foo> would be authorized in the future, when
the user requests operation <bar>?  I don't know much about
security, but it seems to be a total waste of time to do this.

Andy

> Administrators can decide that syslog notifications and/or SN/or SNMP
>>MP
>>>>>> Subject: RE: Issue X: access to notification contenProposed text (B)
>>>
>>>>t

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 8 May 2008 12:08:46 -0400

Hi

Neither proposal A or B talk about other NETCONF operations. That text
is only in the before text. The difference between proposal A and
proposal B is that proposal A is making recommendations to prevent a
security issue (don't give people information they are not allowed to
see) and proposal B leaves open the option to have this security issue
(you may allow people to see information they are not allowed to see).

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 08, 2008 11:52 AM
To: David B Harrington
Cc: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content

I don't even see what other NETCONF operations have to do with a
notification receiver application.  I don't agree that any additional
security is provided by this MUST requirement.

When user A attempts NETCONF operation <foo>, the agent will authorize
the RPC operation at that time.  Why would the agent even check if <foo>
would be authorized in the future, when the user requests operation
<bar>?  I don't know much about security, but it seems to be a total
waste of time to do this.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 8 May 2008 12:08:46 -0400

Hi

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 08, 2008 11:52 AM
To: David B Harrington
Cc: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 May 2008 10:13:30 -0700

> (you may allow people to see information they are not allowed to see).

oops -- I was confused.  I thought the paragraph dealt with
other NETCONF operations, but I see that is Dave's text, not (A) or (B).

I actually don't like any of the choices.
The authorization policies, mechanisms, and data models are
way out of scope at this time.  At best, a generic sentence
about the advantages of preventing sensitive information
from being disclosed without proper authorization is needed.

We already have an standard authorization architecture in NETCONF.
It you can login, you can do anything and everything
the agent supports.  Root access or nothing.  It really stinks,
but it is what the protocol supports From [email-masked]  Thu May  8 10:13:50 2008
Date: Thu, 08 May 2008 10:13:30 -0700
From: Andy Bierman <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content
Sender: [email-masked]

> (you may allow people to see information they are not allowed to see).

oops -- I was confused.  I thought the paragraph dealt with
other NETCONF operations, but I see that is Dave's text, not (A) or (B).

I actually don't like any of the choices.
The authorization policies, mechanisms, and data models are
way out of scope at this time.  At best, a generic sentence
about the advantages of preventing sensitive information
from being disclosed without proper authorization is needed.

We already have an standard authorization architecture in NETCONF.
It you can login, you can do anything and everything
the agent supports.  Root access or nothing.  It really stinks,
but it is what the protocol supright now.

Until something real is done about access control, I suggest the
protocol not make any assumptions about how authorization to a specified
subset of the 'entire agent' is done.  IMO, an authorization
model that does not account for the entire NETCONF stack is
broken.  Focusing on the data, ignoring the RPC methods,
and ignoring the transport layer issues as well, will not
lead to a good enough solution.

Andy

>>>> If there is no objection to proposal A then I wilports right now.

Until something real is done about access control, I suggest the
protocol not make any assumptions about how authorization to a specified
subset of the 'entire agent' is done.  IMO, an authorization
model that does not account for the entire NETCONF stack is
broken.  Focusing on the data, ignoring the RPC methods,
and ignoring the transport layer issues as well, will not
lead to a good enough solution.

Andy

>>>> If there is no objection to proposal A thenl proceed
>>> to make this
>>>> SHOULD NOT ... dependin I will proceed
>>> to make this
>>>> SHOULD NOT ... deg on the access control model and
>>> administrative
>>>> policy."
>>>>
>>>>> Sharon
>>>>>
>>>pending on the access control model and
>>> administrative
>>>> policy."
>>>>
>>>>> Sharon
>>>>>
>>>>>> standard. >>>>> most cases it is the right choice. But a NOC manager
>>>>>> might want to

In

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 May 2008 13:50:53 -0400

Hi Sharon,

You need to read RFC2119 to understand the difference between stating
a REQUIREMENT and making a RECOMMENDATION. I mentioned uisng RFC2119
langauge in one of my earleir messages, to make it unambiguous.

"must" = REQUIREMENT 
"should" = RECOMMENDATION 

You keep wanting to use "must" and that makes it a REQUIREMENT of the
protocol. It should NOT be a REQUIREMENT. If we want to say anything
about matching to other operations, then we want to make a
RECOMMENDATION, and use "should", not "must".

dbh

> Sent: Thursday, May 08, 2008 12:09 PM
> To: Andy Bierman; David B Harrington
> Cc: Bert Wijnen - IETF; [email-masked]
authorize

> >>> makes it so we can keep the 'must not'. I think now we don't
need
> > to

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 May 2008 13:50:53 -0400

Hi Sharon,

"must" = REQUIREMENT 

dbh

authorize

need

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 May 2008 14:26:34 -0400

> other NETCONF operations, but I see that is Dave's text, not 

Read the "current text" again, Andy. The current text specifies:
"If a user does not have permission to view content via other NETCONF
operations, she must not have access to that content via
Notifications."

I object to this for multiple independent reasons:
1) "must" is an RFC2119 reserved word. Using it here makes this a
REQUIREMENT.
2) Access control mechanisms are out of scope at this time. So we
should not state any REQUIREMENTS about how access control "must"
work.
3) the current text makes notification access control dependent on the
access controls used for other operations. Andy, I think this is a bad
idea, for reasons similar to those you mention.
4) authorization to view information should be an adminstrative
decision, not a protocol decision.
5) Netcofn notifications were designed to carry syslog and SNMP
notifications streams. We should not impose the access control
requirement that is specified in the "current text" for syslog and/or
SNMP content.

> I actually don't like any of the choices.

I don't like any of the choices either. The Proposed text (C) was a
concession to Sharon's unwillingness to remove the dependence on other
operations. In the REQUIREMENT in Sharon's (A), is access via SNMP-GET
or syslog logging acceptable as the "permission to view  the
information" - I think that a dependency on access control mechanisms
in other protocols would be even worse than "permission to view
content via other NETCONF operations".

here is another proposed text to replace the original text:

Proposed Text (D)

"The contents of notifications as well as the names of event streams
may contain sensitive information and care should be taken to ensure
that they are viewed only by authorized users. It is an administrative
policy decision to determine who (or what) is authorized to have
access to the information contained in notifications. If a user is not
authorized to view all elements in the content of the notification,
the notification is not sent to that user."

I could also live with the nice simple

Proposed Text (E)

"The contents of notifications as well as the names of event streams
may contain sensitive information and care should be taken to ensure
that they are viewed only by authorized users. If a user is not
authorized to view all elements in the content of the notification,
the notification is not sent to that user."

I could also live with the even simpler:

"The contents of notifications as well as the names of event streams
may contain sensitive information and care should be taken to ensure
that they are viewed only by authorized users."

And then leave it up future access control mechanisms to determine
authorization.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 May 2008 14:26:34 -0400

Proposed Text (D)

Proposed Text (E)

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Thu, 8 May 2008 22:05:00 +0200

Bert Wijnen

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Thu, 8 May 2008 22:05:00 +0200

Bert Wijnen

---

From: "Natale, Bob" <[email-masked]>
Date: Thu, 8 May 2008 16:25:27 -0400

I don't have a position in this matter...I'm just looking at the
wording for implementation implications:

All three of the option/proposal texts below conclude with this
statement:
"If a user is not permitted to view one element in the content of the
notification, the notification is not sent to that user."

That can (sensibly) be read as meaning:
"If a user is permitted to view [at least] one element in the content
of the notification, the notification is sent to that user."

If that is not what is intended, then perhaps something *like* this
would be more effective:
"If and only if a user is permitted to view all elements in the content
of the notification, then the notification is sent to that user."

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf OfFrom [email-masked]  Thu May  8 13:27:19 2008
Content-class: urn:content-classes:message
Date: Thu, 8 May 2008 16:25:27 -0400
From: "Natale, Bob" <[email-masked]>
To: "Bert Wijnen - IETF" <[email-masked]>,
	"Sharon Chisholm" <[email-masked]>,
	"David B Harrington" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content
Sender: [email-masked]

I don't have a position in this matter...I'm just looking at the
wording for implementation implications:

All three of the option/proposal texts below conclude with this
statement:
"If a user is not permitted to view one element in the content of the
notification, the notification is not sent to that user."

That can (sensibly) be read as meaning:
"If a user is permitted to view [at least] one element in the content
of the notification, the notification is sent to that user."

If that is not what is intended, then perhaps something *like* this
would be more effective:
"If and only if a user is permitted to view all elements in the content
of the notification, then the notification is sent to that user."

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Beh Bert Wijnen - IETF
Sent: Thursday, May 08, 2008 4:05 PM
To: Sharon Chisholm; David B Harrington; [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content

Bert Wijnen 

> response did not alf Of Bert Wijnen - IETF
Sent: Thursday, May 08, 2008 4:05 PM
To: Sharon Chisholm; David B Harrington; [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content

Bert Wijnen 

> response diinclude the text after the ellipsis.
> 

> > > > > I am also concerned not include the text after the ellipsis.
> 

> > > > > I am also cod that this access control "policy" 
> > > should be an
> > > > > give the helpdesk or the IDS <get> permissions. With this
CLR,

ncerned that this access control "policy" 
> > > > > give the helpdesk or the IDS <get> permissions. With this
CLR,

---

From: Andy Bierman <[email-masked]>
Date: Thu, 08 May 2008 16:57:15 -0700

> operations, she must not have access to that content via

This text is not acceptable.
What content?  What operations?
What if the data the user is allowed to see via notifications
is not available via other operations?  Does this sentence mean that
scenario is forbidden in NETCONF?

(E) is good.

We have seen recently that people will parse a normative sentence
to make it say what they want it to say.  We should not add any
problematic sentences to the Notifications RFC that will be impede
any future access control work.

(I bet dollars to donuts that the terms used carelessly in
this paragraph in question will be parsed against the terminology
in future access control documents, and cause problemsFrom [email-masked]  Thu May  8 16:57:45 2008
Date: Thu, 08 May 2008 16:57:15 -0700
From: Andy Bierman <[email-masked]>
To: David B Harrington <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Issue X: access to notification content
Sender: [email-masked]

> operations, she must not have access to that content via

This text is not acceptable.
What content?  What operations?
What if the data the user is allowed to see via notifications
is not available via other operations?  Does this sentence mean that
scenario is forbidden in NETCONF?

(E) is good.

We have seen recently that people will parse a normative sentence
to make it say what they want it to say.  We should not add any
problematic sentences to the Notifications RFC that will be impede
any future access control work.

(I bet dollars to donuts that the terms used carelessly in
this paragraph in question will be parsed against the terminology
in future access control documents, and cause pr. ;-)

Andy

oblems. ;-)

Andy

---

From: "tom.petch" <[email-masked]>
Date: Fri, 9 May 2008 12:20:27 +0200

I think that F) is the best so far, namely

> > David Harrington"

I would suggest
 /they are viewed only by/they are made available only to/
to cover more forms of communication (like print).

Tom Petch

----- Original Message ----- 
From: "Andy Bierman" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 09, 2008 1:57 AM
Subject: Re: [Netconf] Issue X: access to notification content

> in future access control documents, and cause problems. ;-)
> 
> 
> Andy
> 
> 
> 
> >

---

From: "tom.petch" <[email-masked]>
Date: Fri, 9 May 2008 12:20:27 +0200

I would suggest

Tom Petch

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Wed, 14 May 2008 17:27:00 +0200

I think (D) is better than (E). IMO it is better to 
have the additional sentence to avoid another 
discuss asking "who is not authorized?".

Cheers, 
Mehmet

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Andy Bierman

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Wed, 14 May 2008 17:27:00 +0200

Cheers, 
Mehmet