Regarding Bill's draft
Ran Atkinson <rja@cisco.com> Thu, 22 February 1996 21:04 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08763; 22 Feb 96 16:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08758; 22 Feb 96 16:04 EST
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa21314; 22 Feb 96 16:04 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa05740; 22 Feb 96 15:31 EST
Received: from relay.tis.com by neptune.TIS.COM id aa05726; 22 Feb 96 15:27 EST
Received: by relay.tis.com; id PAA09111; Thu, 22 Feb 1996 15:29:06 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma009107; Thu, 22 Feb 96 15:28:38 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA16455; Thu, 22 Feb 96 15:27:36 EST
Received: by relay.tis.com; id PAA09102; Thu, 22 Feb 1996 15:28:36 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma009091; Thu, 22 Feb 96 15:28:10 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA00276; Thu, 22 Feb 1996 12:29:13 -0800
Date: Thu, 22 Feb 1996 12:29:13 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199602222029.MAA00276@puli.cisco.com>
To: ipsec@tis.com
Subject: Regarding Bill's draft
X-Orig-Sender: ipsec-request@neptune.tis.com
Precedence: bulk
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
- Regarding Bill's draft Ran Atkinson
- Re: Regarding Bill's draft William Allen Simpson