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

"Matt Miller (mamille2)" <mamille2@cisco.com> Mon, 19 October 2015 17:44 UTC

Return-Path: <mamille2@cisco.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 8F4A31AD369; Mon, 19 Oct 2015 10:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 1H70VtSC46lG; Mon, 19 Oct 2015 10:44:10 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662BC1AD368; Mon, 19 Oct 2015 10:44:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5825; q=dns/txt; s=iport; t=1445276651; x=1446486251; h=from:to:subject:date:message-id:mime-version; bh=CnseqRTGIJ+z1urxsJ0Kf9Wwed6+KZ62RnoMf/eCx+k=; b=DMeTvv3muH75NivRRSvjI8r/xOxsyG6JFxhI1IRWGupni5JhPwStSO/q 4I5OPnFdw+NzGSb/8RjAbyyLw/4xu9LxTcUvHnuWgjiziQ0bsQ11kvEge czR9AdlJfp4vTRJiRuHtPYqIL+axdSMT1L81gedbDHNSyj7SwTPNeOmt+ I=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C6AgA1KyVW/4sNJK1egzZUbwa+CQ6BWiGCQ4M6gT44FAEBAQEBAQGBCoQ0I2gBSgI0JwQBEg6IIg2xPJJlAQEBAQEBAQMBAQEBAQEUCYkHiASCZzGBFAWWIwGCTYFhaoVMgjiBWBWWPINuAR8BQ4QDcgGEYIEGAQEB
X-IronPort-AV: E=Sophos;i="5.17,703,1437436800"; d="asc'?scan'208";a="198952339"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP; 19 Oct 2015 17:44:10 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t9JHi9gj015912 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 17:44:09 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 12:43:51 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 12:43:51 -0500
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: "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>
Thread-Topic: secdir review of draft-santesson-auth-context-extension-09
Thread-Index: AQHRCpW3AW+Vkot/x0KVGTHsSjvgZw==
Date: Mon, 19 Oct 2015 17:43:51 +0000
Message-ID: <69233D17-A670-4A59-833E-F314661C71DA@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-pgp-agent: GPGMail 2.5.2
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [64.101.72.32]
Content-Type: multipart/signed; boundary="Apple-Mail=_D6E76A2E-224A-4785-8FBF-CFF39AAC3B47"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/B_6HIrGTA1G9dd4hPI11zGL1IDQ>
Subject: [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: Mon, 19 Oct 2015 17:44:12 -0000

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@cisco.com>
Cisco Systems, Inc.