[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