Subject: RE: [Ips] X#NodeArchitecture draft - next steps

From: [email-masked]
Date: Mon, 10 Apr 2006 08:00:12 -0400

But sites might not be small, plus some sites might have this
concern even when there is no known vulnerability to hide.  This
security concern is similar to one addressed in the standard SNMP
security "boilerplate" - the concern needs to be addressed in something
like this fashion, and disabling off sending the key "just in
case" is fine.  I also disagree with your "invites an attack
rationale" - not sending the key might be indicative of a more
thorough/aggressive site security policy/posture, in which case
an attacker might look elsewhere (e.g., for a site that may be
less diligent about keeping patch levels up to date).
 
Thanks,
--David
---------------------------------------------------- 
David L. Black, Senior Technologist 
EMC Corporation, 176 South St., Hopkinton, MA  01748 
+1 (508) 293-7953             FAX: +1 (508) 293-7786 
[email-masked]        Mobile: +1 (978) 394-7754 
---------------------------------------------------- 

  _____  

From: Julian Satran [mailto:[email-masked]] 
Sent: Saturday, April 08, 2006 7:44 AM
To: Black, David
Cc: [email-masked]; [email-masked]
Subject: RE: [Ips] X#NodeArchitecture draft - next steps

David, 

Sites might be small. If a given target code has a known weakness just not
answering or even answering "not understood" invites an attack by a scanner.

IMHO the best solution would be for the draft to say nothing. 

Julo 

[email-masked] 

07/04/06 23:24 

To
Julian Satran/Haifa/IBM@IBMIL 

cc
[email-masked], [email-masked] 

Subject
RE: [Ips] X#NodeArchitecture draft - next steps

IMHO, a site-wide policy of not using the key is within reason. 
Obfuscating the value defeats the primary purpose of the key - 
the interest is in what is *actually* running, not the name 
of some other implementation that this one ought to be 
behaviorally indistinguishable from.  Not sending the key is 
a better means of dealing with this concern. 
  
Thanks, 
--David 

  _____  

From: Julian Satran [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 8:40 AM
To: Black, David
Cc: Black, David; [email-masked]; [email-masked]
Subject: RE: [Ips] X#NodeArchitecture draft - next steps

I am not sure that not sending the key is that good a measure (not sending
it when it was previously seen is a way of leaking information). 
I guess what you want to mandate is that the value can be specifically faked
(set) and/or responding "not understood". 

Julo 

[email-masked] 

06/04/06 18:08 

To
[email-masked] 

cc
[email-masked], [email-masked] 

Subject
RE: [Ips] X#NodeArchitecture draft - next steps

Dave,

> New proposed text:
> 
> 3.  Security Considerations 
> 
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in 
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.

Good start, needs editing to something like:

  This extension key transmits specific implementation details
  about the node that sends it; such details may be considered
  sensitive in some environments.  For example, if a certain
  software or firmware version is known to contain security
  weaknesses, announcing the presence of that version via this
  key may not be desirable.  The countermeasures for this
  security concern are:
               - not sending the extension key, or
               - using IPsec to provide confidentiality for the iSCSI
                                connection on  which the key is sent (see
RFC 3720
                                and RFC 3723).
  To support the first countermeasure, all implementations of
  this extension key MUST provide an administrative mechanism
  to disable sending the key.

Reasons for the edits:
- Focus on specific threat, not general "where security is a primary
               concern".
- Make the "MUST" for disabling transmission of the key globally
               applicable, vs. possibly scoped to specific environments.
               This is a "MUST implement" requirement, not "MUST use".
- Avoid the "SHOULD ... use ... IPsec" phrasing, at least for now.

> New proposed text:
> 
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.

This one is close - 3 suggestions:
- "proper" -> "intended"
- remove "and for better understanding of customer environments" or
               replace it with something more specific like "and to enable
               collection of iSCSI implementation usage information"
- The "such as ... or other uses not defined here" is not sufficiently
               precise.
The last one is crucial - it needs to be easy for an implementer to
determine whether s/he's stepped over this line.

I'm comfortable with not mentioning the JavaScript and browser versions
mess, as I think we all know that it's the motivating example for this
text.

Thanks,
--David (as individual participant, *not* as WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Dave Wysochanski [mailto:[email-masked]] 
> Sent: Friday, March 31, 2006 9:35 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [Ips] X#NodeArchitecture draft - next steps
> 
> [email-masked] wrote:
> 
> > This draft is better known as: 
> > draft-wysochanski-xkey-iscsi-support-00.txt
> >
> > This draft will be an official WG draft, but three things
> > need to happen first:
> >
> > (1) New security text.  The existing "SHOULD" in the security
> >         considerations text needs to be a "MUST".  In addition,
> >         there needs to be a sentence pointing out that it may
> >         be important to shield the contents of this key from
> >         observers of network traffic, and that IPsec as specified
> >         for iSCSI in RFC 3720 and 3723 (cite both of them) is an
> >         appropriate tool for this purpose.
> >
> New proposed text:
> 
> 3.  Security Considerations 
> 
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node.  For these
>    environments, nodes implementing this public extension key
>    MUST provide a method to disable sending the key.  In
>    addition to providing a disable mechanism, security sensitive
>    environments SHOULD consider use of IPsec, as specified in 
>    RFC 3720 and 3723, as a means to shield the contents of this
>    key from observers of network traffic.
> 
> 
> 
> Original text:      
> 
> 3.  Security Considerations 
> 
>    In certain environments where security is a primary concern,
>    the use of this extension key may not be appropriate as it
>    reveals specific details about an iSCSI node. For these
>    environments, nodes implementing this public extension key
>    SHOULD provide a method to disable sending the key.
> 
>       
> 
> > (2) New "prevention of abuse" text.  The current "The key MUST NOT
> >         be used by iSCSI nodes for things such as ..." is well-
> >         intentioned but does not get the job done.  My recollection
> >         of discussion in Dallas is that saying that "functional behavior
> >         of the iSCSI node MUST NOT depend on this key (presence/absence
> >         or value)"  may be closer to the mark.  The only permitted
> >         (and intended) use of this key is to report it/log it in order
> >         to avoid the browser detection JavaScript disasters caused by
> >         the corresponding HTTP header fields.
> >
> 
> I wasn't sure about deleting the original "MUST NOT" sentence so I left it
in.  Anyone
> have a preference?  Also wasn't sure whether it's worth putting in a
sentence or two at
> least acknowledging what has happened in the past with User-Agent --
intent would be
> the working group acknowledges this historical misuse and wishes to avoid
it.
> 
> New proposed text:
> 
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  Functional behavior of the iSCSI
>    node MUST NOT depend on the presence, absence, or content of
>    the key.  The key MUST NOT be used by iSCSI nodes for things
>    such as interoperability, performance, exclusion or deception
>    of other nodes, or other uses not defined here.  To enforce
>    proper use, iSCSI nodes MUST NOT allow user modification of
>    the key value(s), and SHOULD set the value automatically based
>    on standard internal interfaces.
> 
> 
> 
> Original text:
> 
>    The following described Public Extension Key is sent during
>    the login phase of an iSCSI normal session.  It is important
>    to note that the proper use of this key is to provide enhanced
>    logging and support capabilities, and for better understanding
>    of customer environments.  The key MUST NOT be used by iSCSI
>    nodes for things such as interoperability, performance,
>    exclusion or deception of other nodes, or other uses not
>    defined here.  To enforce proper use, iSCSI nodes MUST NOT
>    allow user modification of the key value(s), and SHOULD set
>    the value automatically based on standard internal interfaces.
> 
> 
> 
> 
> 
> 
> > (3) The draft needs a new title and file name ("supportability" just
> >         reeks of marketing ;-) ).  Let's try:
> >
> >            The iSCSI X#NodeArchitecture Key
> >         draft-ietf-ips-iscsi-nodearch-key-00.txt
> >
> Sounds fine to me.
> 
> 
> > Text for (1) and (2), or at least initial versions of it should be
> > worked out on the list before the -00 version of the draft-ietf-ips-...
> > draft is submitted.  I've just sent the request to the secretariat for
> > an end-of-2006 completion milestone for this, but in practice, it
> > could be done shortly after Montreal, if not before.
> >
> Great, thanks.
> 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Ips mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ips
> >
> 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: [email-masked]
Date: Mon, 17 Apr 2006 18:09:07 -0400

> How about another option:
>              - sending less detailed information in the key values
 
Sounds reasonable.  I think you can take the results of the list
discussion to date and submit a -00 WG draft for further discussion
and editing.
 
Thanks,
--David (as WG chair)

  _____  

From: Dave Wysochanski [mailto:[email-masked]] 
Sent: Friday, April 14, 2006 7:57 AM
To: Black, David
Cc: [email-masked]
Subject: Re: [Ips] X#NodeArchitecture draft - next steps

[email-masked] <mailto:[email-masked]>  wrote: 

Dave, 

How about another option:
             - sending less detailed information in the key values

Security concerns could also be lessened by sending less
detailed information, such as omitting the version numbers of
things (for example, send "Microsoft Windows, software initiator"
instead of  "Microsoft Windows 2003, software initiator version 1.2.3.4").
I will have to rework the format of the key a bit but this seems
worth doing.  Hopefully there is a reasonable level of information
that most people will find acceptable transmitting by default while
not greatly compromising security.

                connection on  which the key is sent (see RFC 3720 

This sentence then becomes something like.

To support the first and second countermeasures, all implementations
of this extension key SHOULD provide a way to configure different
levels of detail in the extension key values and MUST provide an
administrative mechanism to disable sending the key.

Reasons for the edits: 

Thanks, 
[email-masked] <mailto:[email-masked]>         Mobile: +1 (978)
394-7754 

> From: Dave Wysochanski [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Cc: [email-masked] <mailto:[email-masked]>  
> [email-masked] <mailto:[email-masked]>  wrote: 
> 

in.  Anyone 
sentence or two at 
intent would be 
it. 
> > [email-masked] <mailto:[email-masked]>         Mobile: +1
(978) 394-7754 
> > [email-masked] <mailto:[email-masked]>  
<https://www1.ietf.org/mailman/listinfo/ips>