Last Call Review of draft-santesson-auth-context-extension-09
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&quot

;
        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