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
| Black_David <at> emc.com
07/04/06 23:24
|
|
To
|
Julian Satran/Haifa/IBM <at> IBMIL
|
|
cc
|
davidw <at> netapp.com, ips <at> ietf.org
|
|
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:Julian_Satran <at> il.ibm.com]
Sent: Friday, April 07, 2006 8:40 AM
To: Black, David
Cc: Black, David; davidw <at> netapp.com; ips <at> ietf.org
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
| Black_David <at> emc.com
06/04/06 18:08
|
|
To
|
davidw <at> netapp.com
|
|
cc
|
ips <at> ietf.org, Black_David <at> emc.com
|
|
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
black_david <at> emc.com Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Dave Wysochanski [mailto:davidw <at> netapp.com]
> Sent: Friday, March 31, 2006 9:35 PM
> To: Black, David
> Cc: ips <at> ietf.org
> Subject: Re: [Ips] X#NodeArchitecture draft - next steps
>
> Black_David <at> emc.com 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
> > black_david <at> emc.com Mobile: +1 (978)
394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >
>
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
RSS Feed