[secdir] review of draft-hollenbeck-rfc4933bis-02
Catherine Meadows <catherine.meadows@nrl.navy.mil> Mon, 06 July 2009 15:53 UTC
Return-Path: <catherine.meadows@nrl.navy.mil>
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 7BC0328C37C; Mon, 6 Jul 2009 08:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.265
X-Spam-Level:
X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 3j3ofFvDd9Xn; Mon, 6 Jul 2009 08:53:56 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 7616C28C275; Mon, 6 Jul 2009 08:53:56 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n66FrM7e018762; Mon, 6 Jul 2009 11:53:22 -0400 (EDT)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n66FrLaj013161; Mon, 6 Jul 2009 11:53:21 -0400 (EDT)
Received: from gilgamesh.fw5540.net ([10.0.3.67]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009070611532016993 ; Mon, 06 Jul 2009 11:53:20 -0400
Message-Id: <897517DC-2F59-440A-BD63-BD71E1AF4421@nrl.navy.mil>
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
To: secdir@ietf.org, iesg@ietf.org, "Hollenbeck, Scott" <shollenbeck@verisign.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-11-152943827"
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Mon, 06 Jul 2009 11:53:19 -0400
X-Mailer: Apple Mail (2.935.3)
Subject: [secdir] review of draft-hollenbeck-rfc4933bis-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: Mon, 06 Jul 2009 15:53:57 -0000
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. Quote from last review: "The draft updates RFC 4933, the EPP Contacts Mapping spec. The updates listed are relatively minor - updates to references and a few minor updates to text." Version 1 has reviewed recently (June 10, by Sandy Murphy) and the author already made the changes that were agreed upon in following discussion. Everything mostly looks OK to me, but there is one issue that never got completely resolved as far as I can tell from what I saw online. This is the question of channel binding issues as described RFC 4953. I'm having trouble accessing that document right now, but apparently the issue is that low-level authentication mechanisms will not provide any distinction between channels at a higher level. This can make it possible for someone with access to the authentication mechanisms to spoof different channels. In particular, if the EPP authorization information is protected with lower-level authentication mechanisms this could be the case. Unless there is good reason to believe that this sort of attack is impossible (in which case it would be a good idea to say why) it might be good that >> Both client and server MUST ensure that authorization >> information is stored and exchanged with high-grade encryption >> mechanisms to provide privacy services. be changed to Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy and authentication services at the appropriate level of granularity. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil
- [secdir] review of draft-hollenbeck-rfc4933bis-02 Catherine Meadows
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Hollenbeck, Scott
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Catherine Meadows
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Hollenbeck, Scott
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Sandra Murphy
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Polk, William T.
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Hollenbeck, Scott
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Alexey Melnikov
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Polk, William T.
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Polk, William T.
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Nicolas Williams
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Sandra Murphy
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Hollenbeck, Scott
- Re: [secdir] review of draft-hollenbeck-rfc4933bi… Nicolas Williams