Last Call Review of draft-ietf-dime-rfc3588bis-

Request Review of draft-ietf-dime-rfc3588bis
Requested rev. no specific revision (document currently at 34)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-11-16
Requested 2010-10-29
Authors Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn
Draft last updated 2010-11-30
Completed reviews Secdir Last Call review of -?? by Carl Wallace
Assignment Reviewer Carl Wallace
State Completed
Review review-ietf-dime-rfc3588bis-secdir-lc-wallace-2010-11-30
Review completed: 2010-11-30


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 node.  


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