[secdir] secdir review of draft-ietf-dime-rfc3588bis-25

"Carl Wallace" <CWallace@cygnacom.com> Wed, 24 November 2010 18:58 UTC

Return-Path: <CWallace@cygnacom.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 94B4C3A697E; Wed, 24 Nov 2010 10:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1C2BKkJkC6Fc; Wed, 24 Nov 2010 10:58:17 -0800 (PST)
Received: from mail75.messagelabs.com (mail75.messagelabs.com []) by core3.amsl.com (Postfix) with SMTP id 28E1A3A6944; Wed, 24 Nov 2010 10:58:17 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: CWallace@cygnacom.com
X-Msg-Ref: server-8.tower-75.messagelabs.com!1290625155!106478554!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: []
Received: (qmail 18452 invoked from network); 24 Nov 2010 18:59:16 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) ( by server-8.tower-75.messagelabs.com with SMTP; 24 Nov 2010 18:59:16 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8C09.B021AA0B"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 24 Nov 2010 13:59:13 -0500
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48011D49ED@scygexch1.cygnacom.com>
Thread-Topic: secdir review of draft-ietf-dime-rfc3588bis-25
Thread-Index: AcuMCUtS7iwykT0kT0GDC8IqMHmmbQ==
From: Carl Wallace <CWallace@cygnacom.com>
To: secdir@ietf.org, iesg@ietf.org, ietf@ietf.org
Cc: john.loughney@nokia.com, vf0213@gmail.com, jari.arkko@ericsson.com
Subject: [secdir] secdir review of draft-ietf-dime-rfc3588bis-25
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: Wed, 24 Nov 2010 18:58:18 -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.


This is a fairly long document and my review has been conducted in
chunks, answers to some of the questions may be apparent on a subsequent
reading.  My primary concern is with authorization of nodes.  Comments,
questions and a few nits are below:


- Section 2.1 should state TLS usage requires mutual authentication.  At
present, this is not mentioned until section 13.


- In 2.6, there appears to be a stray sentence fragment: "Additional
security information, when needed (e.g., keys, certificates)".  Suggest
adding a sentence two beneath if this is another item in the list.


- In section 2.9, authorization checks are mandated but no mechanisms
are defined.  How is authorization performed?  Is this related to the
authorization checks described in 2.9? 


- What does this mean: "the domain name in the SRV query and the domain
name in the target in the SRV record MUST both be valid based on the
same site certificate"?


- Should expand CA acronym in 5.2.  


- In 5.2, including OIDs in a certificate is not a useful authorization
mechanism unless those values are processed across the path from the
trust anchor to the server certificate (or there are some restrictions
on the nature of the path or trust anchor store).  What OIDs are meant
here, extended key usage or certificate policy OIDs?  


- In 13.2, Are trust anchor stores per realm?  If not how will relays be
able to determine how to use authorization information?


- May want to reference RFC 5280 to ensure full path validation
(including revocation status determination) is performed.


- In 5.1, the first bullet correlates to the state table in section 5.6.
The second bullet does not.  Should it?


- Is the deprecation in 6.10 worth a SHOULD NOT?


- The security considerations should include some words describing the
consequences of inappropriately authenticating or authorizing a diameter


- Should relays, agents etc. be required to authenticate to clients with
the same identity used to authenticate to servers?