[abfab] Review of draft-ietf-abfab-aaa-saml-11

"Cantor, Scott" <cantor.2@osu.edu> Fri, 16 October 2015 03:12 UTC

Return-Path: <cantor.2@osu.edu>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EA31B2DB4 for <abfab@ietfa.amsl.com>; Thu, 15 Oct 2015 20:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 NOMW0M-_7Q_W for <abfab@ietfa.amsl.com>; Thu, 15 Oct 2015 20:12:22 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FF21B2DB2 for <abfab@ietf.org>; Thu, 15 Oct 2015 20:12:22 -0700 (PDT)
Received: from BN1AFFO11FD051.protection.gbl (10.58.52.30) by BN1AFFO11HUB030.protection.gbl (10.58.52.140) with Microsoft SMTP Server (TLS) id 15.1.293.9; Fri, 16 Oct 2015 03:12:21 +0000
Authentication-Results: spf=pass (sender IP is 164.107.81.210) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu;
Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.210 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.210; helo=cio-krc-pf03.osuad.osu.edu;
Received: from cio-krc-pf03.osuad.osu.edu (164.107.81.210) by BN1AFFO11FD051.mail.protection.outlook.com (10.58.53.66) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Fri, 16 Oct 2015 03:12:21 +0000
Received: from CIO-TNC-HT08.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by cio-krc-pf03.osuad.osu.edu (Postfix) with ESMTPS id 6497F20172 for <abfab@ietf.org>; Thu, 15 Oct 2015 23:12:20 -0400 (EDT)
Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT08.osuad.osu.edu ([fe80::8431:784b:bd14:3d8%18]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 23:12:19 -0400
From: "Cantor, Scott" <cantor.2@osu.edu>
To: "abfab@ietf.org" <abfab@ietf.org>
Thread-Topic: Review of draft-ietf-abfab-aaa-saml-11
Thread-Index: AdEHswO8BUpjHdymSS6jZh1XsrZH3Q==
Date: Fri, 16 Oct 2015 03:12:19 +0000
Message-ID: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [75.179.164.143]
x-header-sapphire: true
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD051; 1:zVQ5Vn64VcsfrnAKj2DOjnc+vrtWropDXwgieAB9ors3oDcPpN28whHTaQK0tefNsATC4KllF2Hc9BR3vhHwR0cxGZlmYMJ9OAX8feX5BPhipxdM7FY/185qnSIgoszENSIXnYvoF/UT5/FLCucY86rHTWZWtGVj5na5WsT6q0cvxCzGsOH0gdK5JdO6uxuMpAPAPGFnIKIzXFaUUtC3XgFH1w2GbUUW9C7BZCIGCfR4zwnjS1KgU58z+bFwrnywvTM9/5kMcSvqvQTz3kxgugIfJT8nU4v1v9rZK7RIHOJlE7+d1QlDSp5HZQl+vi2ZAHd9mGQy0MK/lKNMClNi+myViBzTmGbWpReLRjNIkwc=
X-Forefront-Antispam-Report: CIP:164.107.81.210; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(93346002)(2920100001)(2900100001)(5003600100002)(5007970100001)(2930100002)(86362001)(102836002)(50466002)(11100500001)(5004730100002)(6806005)(19580395003)(66066001)(450100001)(54356999)(50986999)(189998001)(107886002)(110136002)(47776003)(92566002)(64706001)(55846006)(87936001)(23726002)(33656002)(106466001)(97756001)(75432002)(229853001)(90282001)(109096001)(2501003)(2351001)(15975445007)(5250100002)(5008740100001)(46406003)(230783001)(89122001)(88552001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB030; H:cio-krc-pf03.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf03.osuad.osu.edu; A:1; MX:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 2:J5NventbZUGBD7ygFZYPHb6sSoiBB4zVia9tewJpn0onpoduCEqZpWak4nTmY9RUqAnH/3fimE0akiuDX6KRTUENNvJ4o/SLjjTKqIGWixuiSJ9qIG9W3IGbtYhDLm8s6+QUq+EtVOz34dJGtRnY9LMkFArRY6eL5ZvcV+efkBo=; 3:Ji1LF3nHH61xrw5hG25mMon5dHWYyeG0vjEA+5jXCwpcG70jqLu9MmLIXOfeWSLk1ARlAxd4hmLKn/MRBOzygc5UPg10OhG0mN7bY/6Qn7vCYoEogGm1yTc24yjlROVYLTp5BgwbFQtJ10dYrhZQkIkqJox5Zeb/9SbZ+ExFmiYXYdVLXsJMcOVOUvOgjzhJuvS7jsP62UluNZ1j3tCju6pZC/deZJstI23eiQ4TOgLVaxqen15QrgiMZYk/60ywaslYg2LE2vyEDD8MDEP7gw==; 25:WGx97pBK4MFYhknG9UH70Gearl0wm3SvCBKIhfHnQ2/ywl7bML/SVq6Ho1WCM3IsZ4OiPpDWV3q4lKmk5ctLBB7m6Qx9YWJCO1SxMbqT0pprTYK/LuVi/L3MR//y0bbVK9RhEhVwDSXPF5IGNggoTMtW0HnvGPIsjlJE9tggaFGmuSPZPmiwrabA1pqbL93yEbgMe5N+smaw8ersW1/1qXDiTMdxV0wKki5cTJSYTT1lmjQ+aoHVaI2fBm8YnsCN5+LHNlrKCd54aEZbdXvswQ==
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001)(12001); SRVR:BN1AFFO11HUB030;
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 20:+r21hperVSGUak2jyHt4W8EtblJbUAkcc2JdkIcFlUQs1ZyfCOU2aFYxNzSImGMysqp4A6Y2KTbMMUTSAK+2fA231q3m0WRHdnR+ayyCSpg6+qcQsZDlNfewGTzEOGE+UauOcM15lPZwVQw/yjTk1DrGrWog6BCnpuN0EnSDxXI754bSag1hUddj2ZTP6H0/KSt4UDjc/jXOnsQ+ujSMPAKOEZ3DOjNnIAsxVutjjGQIQMdrPMDvJCqq0vU4wEpifBMlUry8bHJLFLVV+WWWR3Gv3SEhYAw0PsYJOQaot3J4gIqoUpgkJXJMVCPOWZVq9IjtWBEErmJ7Za5I6w3oiRlhLQVZ7QY+2IBSqxyFlTFwL+zRXTynxtzpqSkNeYcqdA/ncLolrqBOQKSZHaGKKU73pp0bnOhM6Hiqac0StKdcwEE1i1z3rQdtdB3Mw85GJUt/nK9LvAjcqJk7ZByNIXtcwhxooXURoko5eLPM+eUGCsxZoSGnrht8q0KAioGy; 4:4mbtehhMTeNerdh+2jfpKG8scJ2jBvbYi80E1c+BfloYUhUEXbM25w09D9221OpexLH1VhroyjVEwa9limpSV3u2BJInC0bGyxi+ThjgxqBvxZbzBU4GcfQZScemPboZkXceGa9CeptWMg7zQRQpuP5EIQQJNuGypQZOWJkVGAom41pAtCBtOsTyYFmbZWdL5D1kxw3ovK1t7ssz5Hj7xCkhbl3Io0XfbNuc+yoz8QlpRHkmlIy2h7K65dkqSADc1gBNBHqbeFRrbHOwy2c22369xkLtA9MfycpRmk8g3PDhqOCRXVpO7EyZYT8gbUAnljaqBdKd/0/kqvkCr23yC+ttsdFYDOBZ9ILa5vj+3wE0XnB6WOqz5/CIfJBOGHo/
X-Microsoft-Antispam-PRVS: <BN1AFFO11HUB0305EA1BEF7A98535BFA9D4D03D0@BN1AFFO11HUB030.protection.gbl>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10115024); SRVR:BN1AFFO11HUB030; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB030;
X-Forefront-PRVS: 0731AA2DE6
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB030; 23:pZKkung+JV+SQj/ItZM1YE75f255rE0g6cHU8pQ?= =?us-ascii?Q?s1NfEF3wNZvRu3/NPIHtyUVCMqTCIdq+jsz4MhYRsP4fCq1csHAKcSMhOVEy?= =?us-ascii?Q?VMwtje2AxhBzH7ktTYBxUjHT/SfeAgaUfEiynOVYgLk0aEpEPnMYDLvzPGrN?= =?us-ascii?Q?NJ97Vs/vZLTgDuIpy6MrJPlOND76feNhoiq8BOVZKDJJq3bUGJD/M+HzwWMt?= =?us-ascii?Q?rEClGum0hDZXhDP6XYlYROcSb8fCUytRH9vgJ145LucvMvt9ce29ZXR579bf?= =?us-ascii?Q?/0LVhoJtRBIWTi9cYKbLgKpV2Sd6J+dx6G5ozo0kjC5/KujLx4QSy6C8qD5a?= =?us-ascii?Q?NlBm16b3Rw99S4IdOH7EOow31dhNVjYXoNzaP2SV4IeExexb1BYD6lBfas6X?= =?us-ascii?Q?DRCzgRGvRn+VlKfXGJd7Yus2OGw5hK/kb6GvgavTjmeBZYOhNcUy4LI5vrsa?= =?us-ascii?Q?q+r6xxVGaiFK7AECzJLVu0USMnQTGxdRsNqjvVGI1U5IbCtOsV3ljkStnhCb?= =?us-ascii?Q?Fncol+lyys3QAKD1LE5R1Vyk2yOiIz19Om5KUc0lTR3CP0OyhYBJU7YJQZS3?= =?us-ascii?Q?EyMXs18dJdqBaaoD428F+dET/qFrSMePx+lUdm2L2WlrRfdmZt0huwNxK0NB?= =?us-ascii?Q?iuhTd9HVCNgf6+SxBf5J/Bfihp2vtY8JvqADBv/u3ESL8cfyZwBPIwXnkfb6?= =?us-ascii?Q?t/8HqqGOzlZPD6CHD+zG+d/dFTKKeMM9Bwo7lFBic/Pggu697fio/J2GVcRN?= =?us-ascii?Q?SWg5AgJaeHsYQ/K5sHbnZOSf+QBWEGsMmmuJBpfi+KI6RHEnNBjeQiDOV94o?= =?us-ascii?Q?tqVqTNPQBa20v6LnSfXE+j/wLxOO+WMGjOOEylNLhKM6yEDHtnchC1No8tix?= =?us-ascii?Q?FjmTu8Q7kJg51928cED23w8z6h3iJfqzmGJMS+1ee9SS1ZPYRqmmz5hI9ieg?= =?us-ascii?Q?zBu3sWXIIEN/B1c/sXxkCrTkvAVRicDYUBaGorsXqy7M2wOB+yLBXXMMHJyn?= =?us-ascii?Q?cZWXphzK8n2TWNw+RTCPYdj7xhPHCKf2+OgpSVyV3fB2z4GZHf69KVX/6quv?= =?us-ascii?Q?nNpa7gNV9W0NmBC/Lv/ZKJVIeQLXZX89cizshpszscxt7u420/BNiphK0+AC?= =?us-ascii?Q?WxL0flAk8SfceOVzQFe883sTrKqCsEclYKHlRunoM117M/eJR1NArHuPaJvY?= =?us-ascii?Q?zjyWzQtH5pscZgvm0X0tmTBiwvzXM5UXKr0WEX1qnTIPfmCo4+3PTsqZGutQ?= =?us-ascii?Q?fog2KjG2J+RmTR6+Ggow=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 5:Ks6LtCAex4nF3DpLPTtSirVNY7fSHe1L4mU8g5eS/g9IeGOAOpfp10SCFD+IxhtAt/AZbnCzrXME6HXGQCPBq+tOPRIs/Zc2QAMHF5aSebbidxgGgRjYASuGyAtj5BRh/xguOuhogWqhiG8qF4xtkA==; 24:hsYd+BfnFbvW6j8frIxk1Gi1LEKxGztZnEJCpeMkRCHqsKZ4Od0+lxPrlTSZ4dH456b5x3WUBFzeTPN4j+8U3lO+L5KYCP4fiR4I4KbsG4I=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: osu.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2015 03:12:21.3080 (UTC)
X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.210]; Helo=[cio-krc-pf03.osuad.osu.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB030
Archived-At: <http://mailarchive.ietf.org/arch/msg/abfab/1QHqBBdpLoPFETEFvJSKDXB_zs4>
Subject: [abfab] Review of draft-ietf-abfab-aaa-saml-11
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/abfab/>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 03:12:25 -0000

Sorry this is a little late. I gave it a pretty thorough read.

Substantive:

Is it useful to say something in section 3 along the lines that apart from the binding defined in section 4, the spec doesn't prescribe any particular pattern/usage/constraint/etc. on the use of the two RADIUS attributes it defines? I ask because of the statement in section 4 about the two attributes not being used in the same RADIUS message, and wondered if that should be stated in section 3, but then thought maybe that wasn't something being constrained by the spec, but just the binding.

In 4.2 where it talks about the Status element, if the message is one that includes the Status element, then by definition it has to have a Status element in it, but you probably mean to say that the Status element should have an appropriate value in it. I'm not sure that's a SHOULD or MAY, really. Seems like a MUST, in that if you're including a response, it's going to have to have a Status whether you want one or not. And obviously it shouldn't be something silly. Just reads kind of oddly to me. Was there some point this was trying to make that I'm not getting?

Some metadata corrections in section 4.3.3:

In 4.3.3.1 and 4.3.3.2, it's saying that it's defining elements (and using the <element> notation), but there actually isn't much point in defining those role elements. They can't appear in a metadata file because EntityDescriptor doesn't allow for extension role *elements*, only extension role types via <RoleDescriptor xsi:type="...">

Up to you guys, but I think it will create more confusion than help anything by defining the elements. And in fact, your examples in 4.3.4 are wrong for this reason, the elements can't appear in the EntityDescriptor. Should look like this:

     <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
                       entityID="https://IdentityProvider.com/SAML">
         <RoleDescriptor xsi:type="abfab:RADIUSIDPDescriptorType" protocolSupportEnumeration=
                                 "urn:oasis:names:tc:SAML:2.0:protocol">
etc.

If you need me to, I can edit the draft appropriately to reflect all this XML correction if it will save you time. It's critical that the examples don't have errors, obviously.

Also, I don't see an actual schema appendix. As I understood it, the RFC has to stand alone, so I think the schema has to be included in full form in an appendix. That's what I did in the SAML-EC work. We need a namespace defined as well (and I guess that would also be added to the ABFAB URN registry in Section 11?), your schema fragments don't specify it. So it's not quite done. Again, I'm happy to do that bit if you wanted to pass me the pen.

In 7.4.2, it mentions including an <Assertion> using the element notation. Sorry if this is old ground, but is XML Encryption intended to be ruled out? One might infer that because of the literal mention of <Assertion> but not <EncryptedAssertion>. Don't know if that's intentional.

Also in 7.4.2, it mentions InResponseTo, and I think it's talking about the SubjectConfirmationData element's attribute by that name, not the Response element's attribute. You probably want both though.

In 7.4.7 and 8.3.4, I think it should read "particular to this profile", but maybe it should say something more to the effect that there are none aside from those applying to the use of the RADIUS binding?

Nits:

Section 1 intro:
s/In particular where this document provides/In particular, this document provides/

Section 4.2 (and 7.4.5):
s/provide confidentiality and improve integrity protection/provide confidentiality and integrity protection/

s/other arbitrary RADIUS attributes will be used/other arbitrary RADIUS attributes MAY be used/

Section 4.3:
The verbage "profiles of this binding" appears a few times. I think it's more accurate in SAML terms to say "profiles making use of this binding".

Section 4.3.2:
s/<entityId>/"entity ID"/
s/establish a relation/establish a relationship/
s/SAML federation metadata/SAML metadata/

Section 4.3.3:
s/represent AAA names associated to a particular/represent AAA names associated with a particular/

Section 4.3.3.1/4.3.3.2:
s/associated to this Entity/associated with the entity/

The reference link to section 3.4 of RFC7055 is not linking to the RFC in the HTML version of the draft.

Section 7.3:
"Where this specification conflicts with it, the former takes precedence."
A little muddy which spec is meant to take precedence. I think you mean the ABFAB profile does?

Section 7.4.2:
s/is subject conform to the following/is subject to the following constraints/

Section 9:
s/required to being able to route/required to route/
s/Other kind of attributes/Other kinds of attributes/

-- Scott