[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Regarding Bill's draft
All,
I've been gone out of town taking care of family matters and have
just now resurfaced and caught up on email/lists. Several folks have asked
for detailed discussion on the problems with Bill's draft. Those folks
apparently are new subscribers to the IPsec list because the technical
problems have been discussed at some length over the course of the past
year. From where I sit, the main problem is that Bill refuses to edit his
draft in conformance with RFC-1825 and Working Group consensus (he made a
public refusal to make needed changes last November in a posting to the
IPsec list, for example). Now I'll try to rehash some of the highlights
for newcomers to this list.
1) There is a well-known attack possible by one user on a multi-user system
against another user on the same multi-user system. This has been
described in the past at length and is often called the "mutually
suspicious users" problem.
This was discussed at length, most recently during the Fall of 1995
on the IPsec list. Bill's draft does not have language on this topic
that is consistent with the WG consensus, as I noted in a message to
the IPsec list on 9 Nov 1995 entitled "naming and terminology".
Bill explicitly refused to make the change and his draft continues
to be broken in this area.
One possible fix would be to rephrase part of Section 1.8 of Bill's
draft to replace the text reading "When required for secure multi-user
environments, ..." with "On multi-user systems,..." or "On
multi-user systems having discretionary access controls (DAC), ..."
AND replace the text reading "Each secure multi-user operating
system MUST..." with "Each multi-user operating system SHOULD...".
Implementation support for user-oriented keying on "multi-user systems"
is specified by RFC-1825 in section 4.6 paragraph 5.
Additionally, the "Design Notes" of Section 1.8 need to be deleted.
NRL's implementation is an existence proof that support for user-
oriented keying does NOT require significant changes to an OS
or its APIs, contrary to Bill's incorrect assertion.
Please note that this item has NOTHING to do with "multi-level
security".
2) The draft incorrectly and unreasonably constrains the security policies
that users may have. In section 2.5.1, Bill requires that
authentication policy may only be determined by the receiver when in
fact this is not a useful or necessary restriction (as has been
discussed on the IPsec list in the past). The NRL implementation is
again a counter-example to Bill's incorrect assertion in that it permits
sender or receiver to each set their own policies on authentication.
The same problem occurs in section 2.5.2 where Bill asserts that
encryption policy is a sender decision. This is not a useful or
necessary restriction either. In particular, experiments at NRL
using the NRL implementation demonstrated that the receiver can
require the sender to use encryption for a session (e.g. telnet
or ftp sessions where the TCP session will never become established).
Again, these were both discussed on the list in some detail and
so this is not a new problem with Bill's draft.
To fix this problem, Bill needs to remove the language in his draft
that restricts the security policies that users can have.
3) Bill's draft does not fully conform with Section 1.4 of RFC-1825.
To conform, the following changes need to be made:
- The text in draft-ietf-ipsec-photuris-ext-01.txt, Section 2.7
needs to be detailed sufficiently that 2 independent implementers
could create interoperable implementations that successfully
pass the Sensitivity Label between them.
A sufficient approach would be to define the label values and
semantics for the US DoD levels specified in RFC-1108, reserve
most label values to IANA for future allocation, and reserve
a small number of label values for private use amongst consenting
parties.
- The sensitivity label option needs to be moved into the main
draft-ietf-ipsec-photuris-*.txt draft because it is a standard
component of an IPsec Security Association.
This isn't hard and I've told this to Bill in the past, but he hasn't
yet made the changes and in the past has specifically refused to change
and fix this on grounds that he personally doesn't believe in
Sensitivity Labels.
For newcomers, I'll note that sensitivity labels aren't really a
military-unique feature. For example, GE has a multi-level security
policy (Class I information is "all GE employees, but no outsiders"
while Class II information is more restricted, for example).
4) The DNS-SIG option should be detailed with both syntax and semantics.
DNS Security is about to move to Proposed Standard and the DNS is likely
to be a primary near-term way for hosts to obtain each others'
certificates. The DNS Security spec is plenty stable for Bill to
finish this item now.
5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted.
It is WAY outside the scope of Bill's draft to modify any standards
track protocol and the attempt to do so is more than sufficient grounds
to bar publication as ANY kind of RFC until that section is deleted.
6) Please also see Bill Sommerfeld's note to the IPsec list with
a subject of "Re: IPsec mailing list", date of 9 Oct 1995 16:57:19
and his note subject "Re: Security Problems in Photuris #2" dated
12 Oct 1995 15:25:28 and the note from Ron Rivest with subject
"Photuris terminology" dated 12 Oct 1995 19:54:57 for other
unresolved technical problems (generally all of those notes suggest
easy simple changes to fix the problems).
In summary, the main obstacle to progress is Bill's unwillingness to
work with the standards process and edit in accordance with WG consensus,
existing standards-track protocols, and the WG requirements.
If the draft should move to WG Last Call in the future, I would not be
surprised if additional technical issues resurfaced or appeared new.
Ran
rja@cisco.com