Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 14 July 2009 16:22 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77D63A6E44; Tue, 14 Jul 2009 09:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydm6g25IcSFr; Tue, 14 Jul 2009 09:22:24 -0700 (PDT)
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 8FFD23A68EC; Tue, 14 Jul 2009 09:22:24 -0700 (PDT)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n6EEMHVj006324; Tue, 14 Jul 2009 10:22:17 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 15:34:28 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0490.3183C49A"
Date: Tue, 14 Jul 2009 10:34:28 -0400
Message-ID: <046F43A8D79C794FA4733814869CDF0702B8DD4F@dul1wnexmb01.vcorp.ad.vrsn.com>
In-Reply-To: <73F6E47F-B165-4018-A822-F49908F8A8DD@nrl.navy.mil>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Secdir review of draft-hollenbeck-rfc4930bis-02
Thread-Index: AcoEivxuuqfvDOJxTFq72OhjLV1NNAABQylg
References: <73F6E47F-B165-4018-A822-F49908F8A8DD@nrl.navy.mil>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>, secdir@ietf.org, iesg@ietf.org
X-OriginalArrivalTime: 14 Jul 2009 14:34:28.0935 (UTC) FILETIME=[31B6DD70:01CA0490]
Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Subject: Re: [secdir] Secdir review of draft-hollenbeck-rfc4930bis-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2009 16:22:25 -0000

________________________________

From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil] 
Sent: Tuesday, July 14, 2009 9:56 AM
To: secdir@ietf.org; iesg@ietf.org; Hollenbeck, Scott
Cc: Catherine Meadows
Subject: Secdir review of draft-hollenbeck-rfc4930bis-02



	I have reviewed this document as part of the security
directorate's ongoing effort to review all IETF documents being
processed by the IESG. These comments were written primarily for the
benefit of the security area directors.  Document editors and WG chairs
should treat these comments just like any other last call comments. 

	Note:  I recently submitted a review of
draft-hollenbeck-rfc4933bis-02.  That was a mistake on my part; that was
not the document I was supposed to review.
	Sandy Murphy is down for reviewing that one.  I am supposed to
review this one.  This document is the update of the based specification
of  EPP, and so is related to rfc4933bis-02.

	I've also had some discussion with Sandy about the issue she
raised with respect to draft-hollenbeck-rfc4933bis-02.  That is actually
what I first thought it was:  EPP only does a weak form of
authentication.
	So it depends on strong authentication done at the transport
level or application level.  However there is nothing in the document
that I can see
	that says that the EPP ID must match the transport ID.  Thus, if
it is relying on the
	authentication being done at the transport level, there appears
to be nothing to prevent the transport level channel being replaced by
another one at some point.  I am not enough of an expert on EPP
	to make a definite recommendation as to how or whether this
needs to be addressed, but I feel that this is something that needs to
be brought to the attention of the IESG and discussed in the next
telechat.   If the
	issue does need to be addressed, rfc4930bis is the place where
it should be handled. 
	 
	 
	Please help me understand what you mean by "EPP ID" and
"transport ID".
	 
	-Scott-