Last Call Review of draft-santesson-auth-context-extension-09
review-santesson-auth-context-extension-09-secdir-lc-miller-2015-10-22-00
Request | Review of | draft-santesson-auth-context-extension |
---|---|---|
Requested revision | No specific revision (document currently at 12) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-10-27 | |
Requested | 2015-10-01 | |
Authors | Stefan Santesson | |
I-D last updated | 2015-10-22 | |
Completed reviews |
Genart Last Call review of -09
by Jouni Korhonen
(diff)
Genart Last Call review of -11 by Jouni Korhonen (diff) Secdir Last Call review of -09 by Matthew A. Miller (diff) Opsdir Last Call review of -09 by Éric Vyncke (diff) Opsdir Telechat review of -11 by Éric Vyncke (diff) |
|
Assignment | Reviewer | Matthew A. Miller |
State | Completed | |
Request | Last Call review on draft-santesson-auth-context-extension by Security Area Directorate Assigned | |
Reviewed revision | 09 (document currently at 12) | |
Result | Has issues | |
Completed | 2015-10-22 |
review-santesson-auth-context-extension-09-secdir-lc-miller-2015-10-22-00
I have reviewed draft-santesson-auth-context-extension-09 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. SUMMARY: This document defines two things: 1) a PKIX extension for specifying a number of authentication contexts a CA used in issuing the certificate, and 2) a SAML-based authentication context. The authentication context(s) are intended to provide additional information to the software verifying the certificate on how the subject -- and possibly various identifying attributes -- was assured. I believe this document is almost ready. I would like to see discussion around my major issue. MAJOR ISSUE: To me, allowing for multiple authentication contexts so generically seems ripe for confusion. Do you have particular scenarios in mind for when multiple contexts ought to be present? I speculate one intent behind multiple authentication contexts is to represent individual SAML AuthnContextClassRef's (e.g., for two-factor authentication). This model of expression seems potentially confusing unless there are further restrictions on the sequence of AuthenticationContext instances (e.g., all instances SHOULD/MUST be for the same contextType?). Alternatively, a more radical approach could be to change the structure to group all information for a particular contextType into the same AuthenticationContext (e.g., sequence of UTF8Strings). MINOR ISSUES: 1) I don't see any specific discussion about security considerations oriented at issuers of such certificates. One consideration I can imagine is around mixing such outsourced assurance with more traditional methods. I do realize this might look too much like dictating CA policy, it seems to me there would be some concerns about such mixing, and therefore might be worth at least noting. 2) I notice that contextInfo is optional. I assume it is envisioned that some contextTypes would not have any contextInfo. I think it would be worthwhile to include some guidance for those that define future contextTypes as to when contextInfo is not necessary, or consider requiring contextInfo always be present (even if it is UTF8String("")) if a missing contextInfo is likely to be rare. I am personally struggling to envision a context type that wouldn't need additional information, but I've admittedly not been thinking about it much. 3) The enforcement of XML (and XML Schema) in Section 2 seems a bit odd to me. It is certainly required for the contextType defined in Section 3, but it seems overly restrictive to me for all possible contextTypes to be XML. For instance, I can see a contextType defined based on an OpenID-Connect claims token, which is JSON. Instead of mandating XML in section 2, I suggest the mandate for XML be moved to Section 3. The definition of contextType then simply be a URI that describes the type, and that contextInfo (if present) be of an appropriate format for (and defined by) the contextType. 4) From my reading, it appears the following is a valid SAML contextInfo: <saci:SAMLAuthContext xmlns:saci=" http://id.elegnamnden.se/auth-cont/1.0/saci" ; xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"/ > Is this intended? If so, can you explain what benefit there is to such a SAML contextInfo; if not, consider mandating at least one of <AuthContextInfo/> and/or <IdAttributes/> MUST be present. I understand expressing this is difficult in XML Schema, but it seems reasonable to me to add text to that effect in Section 3.1. 5) In "3.1.1. AuthContextInfo Element", the definition for AuthenticationInstant points to a non-existent section 3.3. Some of the examples in Appendix C illustrate XML Schema's dateTime data type (XMLSchema-2 § 3.2.7), but I wonder if that is enough and the missing section intended to clarify or augment the basics of dateTime. At the least the reference to Section 3.3 needs to be removed. NITS: * In "4. Security Considerations", the phrase "may differ form certificate to certificate" should be "may differ from certificate to certificate". * In "B.1 XML Schema", ref="saci:AuthContextInfo" and ref="saci:IdAttribues" does not specify maxOccurs. I realize that by default maxOccurs=1, but I always find myself looking it up every time I deal with XSD. I find being explicit helps with humans understanding. Thank you for your consideration, -- - m&m Matt Miller <mamille2 at cisco.com> Cisco Systems, Inc. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail