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-
- [secdir] Secdir review of draft-hollenbeck-rfc493… Catherine Meadows
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Hollenbeck, Scott
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Catherine Meadows
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Hollenbeck, Scott
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Sandra Murphy
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Sandra Murphy
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Sandra Murphy
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Alexey Melnikov
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Hollenbeck, Scott
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Nicolas Williams
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Nicolas Williams
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Hollenbeck, Scott
- Re: [secdir] Secdir review of draft-hollenbeck-rf… Hollenbeck, Scott