Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-10.txt

Alejandro Perez Mendez <alex@um.es> Thu, 19 February 2015 08:06 UTC

Return-Path: <alex@um.es>
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 51E191A88D2 for <abfab@ietfa.amsl.com>; Thu, 19 Feb 2015 00:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vPFf6puWaEe7 for <abfab@ietfa.amsl.com>; Thu, 19 Feb 2015 00:06:54 -0800 (PST)
Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 904CE1A88D4 for <abfab@ietf.org>; Thu, 19 Feb 2015 00:06:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 846AB37C2 for <abfab@ietf.org>; Thu, 19 Feb 2015 09:06:51 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon22.um.es
Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Zj+ycEzXqf+O for <abfab@ietf.org>; Thu, 19 Feb 2015 09:06:51 +0100 (CET)
Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id 4C7032725 for <abfab@ietf.org>; Thu, 19 Feb 2015 09:06:50 +0100 (CET)
Message-ID: <54E5999A.3080502@um.es>
Date: Thu, 19 Feb 2015 09:06:50 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: abfab@ietf.org
References: <20150206154301.31967.50182.idtracker@ietfa.amsl.com> <54D4E501.5020701@um.es> <54D89D9F.3050307@um.es> <54E08964.4040102@sunet.se> <D9060A2A-A131-4FED-9411-A4B8523CD6B0@jisc.ac.uk>
In-Reply-To: <D9060A2A-A131-4FED-9411-A4B8523CD6B0@jisc.ac.uk>
Content-Type: multipart/alternative; boundary="------------080602060208070203090802"
Archived-At: <http://mailarchive.ietf.org/arch/msg/abfab/xyM7FDVSY3k0NW7qkbn8MtHuMCE>
Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-10.txt
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: <http://www.ietf.org/mail-archive/web/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: Thu, 19 Feb 2015 08:06:58 -0000

Hi Stefan,

thanks again for the review. See my comments below.

El 18/02/15 a las 17:49, Stefan Paetow escribió:
>>> with the submission of the updated version of the aaa-saml
>>> (draft-ietf-abfab-aaa-saml-10), we consider the document is now ready
>>> for a Last Call.
> [...]
>> Hmm, I'd feel more comfortable if we'd had one or two reviewers...
> Hi,
>
> I read through the draft and have a couple of nits that you're welcome to tell me to go away with:
>
> - Introduction:
>
> The introduction contains two bulleted lists. The first terminates each bullet with a fullstop. The second doesn't. Elsewhere in the document, other bulleted lists follow the format of the first. For consistency, the second list in the introduction should follow the same format:
>
>     o  A URI that uniquely identifies the protocol binding or profile.
>
>     o  Postal or electronic contact information for the author.
>
>     o  A reference to previously defined bindings or profiles that the
>        new binding updates or obsoletes.
>
>     o  In the case of a profile, any SAML confirmation method identifiers
>        defined and/or utilized by the profile.
>
> - Section 4.3.2:
>
> A fullstop is missing after the <entityId> in the first paragraph. It should be:
>
>     Identity Providers MAY apply policy based on the Relying Party's SAML
>     <entityId>. In such cases, at least one of the following methods is
>     required in order to establish a relation between the SAML name and
>     the AAA name of the Relying Party:
>
> - Section 4.3.4:
>
> A missing comma in the last sentence of this section. It should be:
>
>     [...] RADIUS configuration is used to provide policy, including
>     which attributes are accepted from a Relying Party and which
>     attributes are sent by an Identity Provider.
>
> - Section 6.2:
>
> A missing comma in the first sentence of this section. It should be:
>
>     To implement this scenario, a profile of the SAML Authentication
>     Request protocol is used in conjunction with the SAML RADIUS binding
>     defined in Section 4.
>
> - Section 9:
>
> The first sentence refers to a 'Relaying Party', while the remainder of this section refers to a 'Relying Party'. I can only assume that 'Relaying' should actually be 'Relying'. Corrected text:
>
>     The profiles defined in this document allow a Relying Party to
>     request specific information about the Client, and allow an IdP to
>     disclose information about that Client. [...]

Thanks for these. I will include them for the next version.

>
>>    o  Assume that the Client's identifier implied by a SAML <Subject>
>>          element, if present, takes precedence over an identifier
>>          implied
>>                by the RADIUS User-Name attribute.
>>
>>
>> *what*?!  This flies in the face of 4.3.1.
> Does 4.3.1 refer to the outer identity of a request (I assume so)? AFAIK, 4.3.1 refers only to the NAI realm (the RP doesn't have access to the full identity). 6.4.2 specifies that if the IdP issues an assertion, the assertion's <Subject> may refer to the actual user (I assume that's the inner?), in which case, 6.4.3 makes sense where the <Subject>, if it exists, overrides whatever was in the original request's User-Name attribute? Or am I mixing things up? Just a question... :-)

Actually, 4.3.1 does not refer to Client's identity, but RP's and IdP's 
identities, whereas 6.4.3 does refer to Client's identity.

Regards,
Alejandro

>
> Stefan Paetow
> Moonshot Industry & Research Liaison Coordinator
>
> t: +44 (0)1235 822 125
> gpg: 0x3FCE5142
> xmpp: stefanp@jabber.dev.ja.net
> skype: stefan.paetow.janet
> Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG
>
> jisc.ac.uk
>   
> Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
> Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
>
>
>
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab