Re: [secdir] secdir review of draft-santesson-auth-context-extension-09

["Matt Miller (mamille2)" <[e-mail]>]

> On Nov 25, 2015, at 09:01, Stefan Santesson <[e-mail]> wrote:
> 
> Hi Matt,
> 
> I’m sorry for this late response. I missed it until Stephen Farrel reminded me of this review.
> 
> 
> 
> 
> On 19/10/15 19:43, "secdir on behalf of Matt Miller (mamille2)" <[e-mail] on behalf of [e-mail]> wrote:
> 
>> 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?
> 
> 
> This mainly to keep the specification future proof.
> 
> There is however a real possible use case.
> This extension is currently used to enhance signing certificates that are issued at the instance of singing using a central signing service.
> A signed document may be widely distributed to many relying parties.
> 
> If we at some point get into a situation where another context information structure is defined and some applications can use one type and another application can use the other type, then at least we have the option to provide both, making the same signature certificate useful for both systems.
> 
> Consequently this also allows fro transition to a new context info type even within the same community, taking into account that it is hard to update all systems at the same time.
> 

Thank you for describing the intent.  It was not clear to me in the document.  I would suggest adding something like the above to be explicit on the intent.

Then I'm concerned about how the processing of this extension changes based on whether it's marked critical.  I'm not sure your intent is compatible with the current text:

   Applications that find an authentication context information type
   they do not understand MUST ignore it if the extension is non-
   critical, and MUST reject the certificate if the extension is marked
   critical. If an application requires that an authentication context
   exist, and either the extension is absent, or none of the provided
   authentication contexts can be used, the end user certificate fails
   validation.

As I read this and the intent, if a CA issues a cert with multiple AuthenticationContexts (one for the SACI typed define therein, and one for some hypothetical "foo" type): if this extension is present and marked critical, and if my software understands SACI but not "foo", my software is to reject.

Also, what does it mean if there are AuthenticationContexts of type SACI 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?).
> 
> No this is not the intent. The intent is the one described above.
> 
>> 
>> 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).
> 
> No that would not work. Each context information may need a different type declaration.
> 

I think this is moot given the intent.

>> 
>> 
>> 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.
> 
> I’m not sure I understand what you would like to see here.
> 
> All CAs have a registration process where data about the user is received and validated before entered into the certificate.
> This extension simply allows the CA to express information about this in the certificate.
> 
> I’m not sure how that adds security concerns.
> 

To be fair, I can't remember now what I'd like to see (-:

Please ignore this one.

> 
>> 
>> 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.
> 
> It is optional since it is not the place of this standard to impose a certain policy on the CA.
> The goal of the CA is to provide sufficient information about the certificate to allow it to be trusted.
> 
> The usage of the certificate in the community where it is used knows what information is needed.
> It’s is very hard on this level of specification to provide any guidance on that.
> 

I don't understand how this is dictating policy; I see it as providing recommendations to those that define future context types.

I note that the SACI contextType therein mandates that contextInfo not be empty (When this URI is specified as contextType, then associated XML data MUST be provided in contextInfo).

> 
>> 
>> 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.
> 
> At some stage, this was the design. It was eventually abandoned to simplify the design.
> JSON was abandoned due to having no defined format for time information no well developed schema at the time.
> 

I'm not suggesting that you support JSON now; this was just meant to be an example for some future "foo" contextType.

>> 
>> 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.
> 
> I actually agree with you now when looking at this again, I came to the same conclusion.
> There might be reasons for using new more compressed data formats, such as CBOR in the future.
> 
> This can be done without chaining the syntax of the data, which is important given the many independent implementations of this.
> 

Great!

>> 
>> 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.
> 
> There are pros and cons with this. I’m reluctant to change the XML schema given the existing implementations.
> This is not a good enough reason for it.
> 

Then can you add some of those pros and cons to the document?  I think it would greatly benefit implementers that need to validate such certificates.

>> 
>> 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.
>> 
> 
> 
> This is fixed in the latest version, and so are th
> 
> 
>> 
>> 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.
> 
> This will be used for machine processing by compilers, they will get this right.
> I’d rather keep what comes out of my XML schema editor than to add things by hand.
> 
> Unless this is very important.
> 

I see it as a nit, but something my experience with the XMPP Standards Foundation leads me to do for my own documents.

> 
>> 
>> 
>> Thank you for your consideration,
> 
> 
> Thanks for this. Sorry for the late response.
> 

And thank you for responding!

--
- m&m

Matt Miller
Cisco Systems, Inc.