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

Stefan Santesson <stefan@aaa-sec.com> Wed, 25 November 2015 16:09 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CDE1B2E6B for <secdir@ietfa.amsl.com>; Wed, 25 Nov 2015 08:09:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqVZ0iV6EJWO for <secdir@ietfa.amsl.com>; Wed, 25 Nov 2015 08:08:59 -0800 (PST)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3251B2E3C for <secdir@ietf.org>; Wed, 25 Nov 2015 08:08:59 -0800 (PST)
Received: from s314.loopia.se (localhost [127.0.0.1]) by s314.loopia.se (Postfix) with ESMTP id 3D3BE1642281 for <secdir@ietf.org>; Wed, 25 Nov 2015 17:01:33 +0100 (CET)
X-Loopia-Auth: user
X-Loopia-Originating-IP: 90.228.174.201
X-Loopia-User: stefan@fiddler.nu
Received: from s498.loopia.se (unknown [172.21.200.96]) by s314.loopia.se (Postfix) with ESMTP id D755D20068E9; Wed, 25 Nov 2015 17:01:30 +0100 (CET)
Received: from s406.loopia.se (unknown [172.21.200.105]) by s498.loopia.se (Postfix) with ESMTP id 4666D45E630; Wed, 25 Nov 2015 17:01:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s500.loopia.se ([172.21.200.105]) by s406.loopia.se (s406.loopia.se [172.21.200.136]) (amavisd-new, port 10024) with LMTP id 4nQcrDDqkYk2; Wed, 25 Nov 2015 17:01:29 +0100 (CET)
Received: from [192.168.0.111] (unknown [90.228.174.201]) (Authenticated sender: stefan@fiddler.nu) by s500.loopia.se (Postfix) with ESMTPSA id 0B47BA98501; Wed, 25 Nov 2015 17:01:29 +0100 (CET)
User-Agent: Microsoft-MacOutlook/0.0.0.151105
Date: Wed, 25 Nov 2015 17:01:27 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>, "draft-santesson-auth-context-extension.all@ietf.org" <draft-santesson-auth-context-extension.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Message-Id: <4E62EBD1-F1AE-4FD5-B592-C451EAF64706@aaa-sec.com>
Thread-Topic: [secdir] secdir review of draft-santesson-auth-context-extension-09
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/in9qQjK8nCJUDjrfMIL9JKWFlXI>
Subject: Re: [secdir] secdir review of draft-santesson-auth-context-extension-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 25 Nov 2015 16:09:01 -0000

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)" <secdir-bounces@ietf.org on behalf of mamille2@cisco.com> 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.

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

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


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


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

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

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

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


>
>
>Thank you for your consideration,


Thanks for this. Sorry for the late response.

/Stefan