Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21

[Kent Watsen]

>  Security Comments
>  
>  * I think almost all writable data nodes here are sensitive, because 
a network
>  attacker's first move is to block any logging on the host, and many 
of the data
>  nodes here can be used for this purpose.
> 
> [clw1] I will reword the security section to include all writeable nodes 
as sensitive.
> 
>  * Re: readable data nodes, I'm not
>  sure which are sensitive, and the document should give an example or 
two rather
>  than just say "some". Otherwise the security advice is not 
actionable. One
>  example: "remote" sections leak information about other hosts in the 
network.
> 
> [clw1] This text was lifted from another model. I will review the 
readable nodes and update.
> 
>  * Write operations... can have a negative effect on network 
operations. - I would
>  add "and on network security", because logs are often used to detect 
security
>  breaches.
> 
> [clw1] I will add this phrase.
> 

The fact that the syslog data nodes are write-sensitive can be made explicit in
the model by making the whole configuration tree nacm:default-deny-write, and
making read-sensitive subtrees nacm:default-deny-all.

Thanks,
Gary Wu


 Agreed.  Usually my modules have the NACM annotations and then, in the
Security Considerations section, I'm sure to point them out.


K.




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21

[Gary Wu (garywu)]

>  Security Comments
>  
>  * I think almost all writable data nodes here are sensitive, because 
a network
>  attacker's first move is to block any logging on the host, and many 
of the data
>  nodes here can be used for this purpose.
> 
> [clw1] I will reword the security section to include all writeable nodes 
as sensitive.
> 
>  * Re: readable data nodes, I'm not
>  sure which are sensitive, and the document should give an example or 
two rather
>  than just say "some". Otherwise the security advice is not 
actionable. One
>  example: "remote" sections leak information about other hosts in the 
network.
> 
> [clw1] This text was lifted from another model. I will review the 
readable nodes and update.
> 
>  * Write operations... can have a negative effect on network 
operations. - I would
>  add "and on network security", because logs are often used to detect 
security
>  breaches.
> 
> [clw1] I will add this phrase.
> 

The fact that the syslog data nodes are write-sensitive can be made explicit in
the model by making the whole configuration tree nacm:default-deny-write, and
making read-sensitive subtrees nacm:default-deny-all.

Thanks,
Gary Wu

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21

[Yaron Sheffer]

Hi Clyde,

Thank you for responding to my comments. I am OK with all of your responses.

Best,
Yaron

On 19/02/18 13:02, Clyde Wildes (cwildes) wrote:

Yaron,

Thanks for your review. My answers are inline as [clw1].

On 2/18/18, 6:31 AM, "Yaron Sheffer"  wrote:

 Reviewer: Yaron Sheffer
 Review result: Has Issues
 
 General Comments
 
 * The semantics of pattern matching is not clear: "and/or the message text" -

 are there cases where you only match the text but not the 
facility/severity? *
 
[clw1] Yes. There are three cases: 1. Match on facility/severity; 2. Match on the regex pattern; 3. Match on both facility/severity and the regex pattern.


 It's very confusing to specify rollover in minutes, but retention in hours.
 People are bound to get this one wrong.

[clw1] I will change the retention to minutes unless others object.

 * Interface selection: the feature
 makes sense, but I think the description is incorrect. "This leaf sets the
 source interface to be used to send messages to the remote syslog server. 
If
 not set, messages sent to a remote syslog server will contain the IP 
address of
 the interface the syslog message uses to exit the network element". AFAIK 
the
 source IP will always correspond to the interface, but this feature allows 
you
 to select a particular one.

[clw1] You are correct. I will modify the description to make this clearer. How 
about:

"This leaf sets the source interface to be used to send messages to the remote 
syslog server. If
not set, messages can be sent on any interface."

 * Usage examples: the second example lists a
 specific IPv6 address, but the Yang snippet shows a domain name.

[clw1] Thanks for catching this error. I will fix this in the next revision.

 * A generic
 question (I am new to the Yang ecosystem): I understand most implementers 
will
 use this module from
 
https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang
 - is this the expectation? If so, why not add a link from the RFC into the
 repo, to make it easier for people to find?

[clw1] It is standard practice to include the model in the RFC AFAIK. I have 
not seen github links published in any other RFCs.
 
 Security Comments
 
 * I think almost all writable data nodes here are sensitive, because a network

 attacker's first move is to block any logging on the host, and many of the 
data
 nodes here can be used for this purpose.

[clw1] I will reword the security section to include all writeable nodes as 
sensitive.

 * Re: readable data nodes, I'm not
 sure which are sensitive, and the document should give an example or two 
rather
 than just say "some". Otherwise the security advice is not actionable. One
 example: "remote" sections leak information about other hosts in the 
network.

[clw1] This text was lifted from another model. I will review the readable 
nodes and update.

 * Write operations... can have a negative effect on network operations. - 
I would
 add "and on network security", because logs are often used to detect 
security
 breaches.

[clw1] I will add this phrase.

 * Also add an advice, similar to the one on "pattern match", that the
 private key used for signing log messages MUST NOT be used for any other
 purpose, and that the implementation of this data node must ensure this
 property (I'm not sure how). The rationale: if the TLS private key is 
used, for
 example, this could result in a signing oracle for TLS and eventually a 
MITM
 attack.

[clw1] I will add this advice.

Thanks,

Clyde
 



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21

[Clyde Wildes (cwildes)]

Yaron,

Thanks for your review. My answers are inline as [clw1].

On 2/18/18, 6:31 AM, "Yaron Sheffer"  wrote:

Reviewer: Yaron Sheffer
Review result: Has Issues

General Comments

* The semantics of pattern matching is not clear: "and/or the message text" 
-
are there cases where you only match the text but not the 
facility/severity? *

[clw1] Yes. There are three cases: 1. Match on facility/severity; 2. Match on 
the regex pattern; 3. Match on both facility/severity and the regex pattern.

It's very confusing to specify rollover in minutes, but retention in hours.
People are bound to get this one wrong.

[clw1] I will change the retention to minutes unless others object.

* Interface selection: the feature
makes sense, but I think the description is incorrect. "This leaf sets the
source interface to be used to send messages to the remote syslog server. If
not set, messages sent to a remote syslog server will contain the IP 
address of
the interface the syslog message uses to exit the network element". AFAIK 
the
source IP will always correspond to the interface, but this feature allows 
you
to select a particular one.

[clw1] You are correct. I will modify the description to make this clearer. How 
about:

"This leaf sets the source interface to be used to send messages to the remote 
syslog server. If
not set, messages can be sent on any interface."

* Usage examples: the second example lists a
specific IPv6 address, but the Yang snippet shows a domain name. 

[clw1] Thanks for catching this error. I will fix this in the next revision.

* A generic
question (I am new to the Yang ecosystem): I understand most implementers 
will
use this module from

https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang
- is this the expectation? If so, why not add a link from the RFC into the
repo, to make it easier for people to find?

[clw1] It is standard practice to include the model in the RFC AFAIK. I have 
not seen github links published in any other RFCs.

Security Comments

* I think almost all writable data nodes here are sensitive, because a 
network
attacker's first move is to block any logging on the host, and many of the 
data
nodes here can be used for this purpose.

[clw1] I will reword the security section to include all writeable nodes as 
sensitive.

* Re: readable data nodes, I'm not
sure which are sensitive, and the document should give an example or two 
rather
than just say "some". Otherwise the security advice is not actionable. One
example: "remote" sections leak information about other hosts in the 
network.

[clw1] This text was lifted from another model. I will review the readable 
nodes and update.

* Write operations... can have a negative effect on network operations. - I 
would
add "and on network security", because logs are often used to detect 
security
breaches. 

[clw1] I will add this phrase.

* Also add an advice, similar to the one on "pattern match", that the
private key used for signing log messages MUST NOT be used for any other
purpose, and that the implementation of this data node must ensure this
property (I'm not sure how). The rationale: if the TLS private key is used, 
for
example, this could result in a signing oracle for TLS and eventually a MITM
attack.

[clw1] I will add this advice.

Thanks,

Clyde


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod