From nobody Fri Feb 6 07:43:03 2015 Return-Path: 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 09DE81A1BAF; Fri, 6 Feb 2015 07:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 xQ8VXLzRedi6; Fri, 6 Feb 2015 07:43:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C79031A1BAD; Fri, 6 Feb 2015 07:43:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206154301.31967.50182.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 07:43:01 -0800 Archived-At: Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-10.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:43:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML Authors : Josh Howlett Sam Hartman Alejandro Perez-Mendez Filename : draft-ietf-abfab-aaa-saml-10.txt Pages : 24 Date : 2015-02-06 Abstract: This document describes the use of the Security Assertion Mark-up Language (SAML) with RADIUS in the context of the ABFAB architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request, enabling a Relying Party to request authentication of, or assertions for, users or machines (Clients). These Clients may be named using a NAI name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. These artifacts have been defined to permit application in AAA scenarios other than ABFAB, such as network access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 6 08:00:15 2015 Return-Path: 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 7ACCF1A1BDB for ; Fri, 6 Feb 2015 08:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 TdtR25aJbU5U for ; Fri, 6 Feb 2015 08:00:07 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89E1A1BBF for ; Fri, 6 Feb 2015 08:00:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 0F57CBACB for ; Fri, 6 Feb 2015 17:00:03 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RJ8YwDgkPOow for ; Fri, 6 Feb 2015 17:00:02 +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 xenon23.um.es (Postfix) with ESMTPSA id C4C3DF88 for ; Fri, 6 Feb 2015 17:00:02 +0100 (CET) Message-ID: <54D4E501.5020701@um.es> Date: Fri, 06 Feb 2015 17:00:01 +0100 From: Alejandro Perez Mendez 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> In-Reply-To: <20150206154301.31967.50182.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070602020507050009080000" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:00:11 -0000 This is a multi-part message in MIME format. --------------070602020507050009080000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have generated a new version of the draft including the following changes: * General editorial work (typo correction and wordsmithing) on the document. * Addressing of the editorial comments provided by Troy Shields. * Made terminology more consistent with ABFAB. Everything now is explained in terms of Clients, RPs, and IdPs. * Extended description of the SAML-Message and SAML-Assertion attributes (following the typical procedure with the figure and the description of each field). * Changes to the Privacy and the Security Considerations sections. * Changes to the IANA Considerations section dealing with the registration of the new attributes. * Completed the Acknowledgement section. Best regards, Alejandro > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. > > Title : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML > Authors : Josh Howlett > Sam Hartman > Alejandro Perez-Mendez > Filename : draft-ietf-abfab-aaa-saml-10.txt > Pages : 24 > Date : 2015-02-06 > > Abstract: > This document describes the use of the Security Assertion Mark-up > Language (SAML) with RADIUS in the context of the ABFAB architecture. > It defines two RADIUS attributes, a SAML binding, a SAML name > identifier format, two SAML profiles, and two SAML confirmation > methods. The RADIUS attributes permit encapsulation of SAML > assertions and protocol messages within RADIUS, allowing SAML > entities to communicate using the binding. The two profiles describe > the application of this binding for ABFAB authentication and > assertion query/request, enabling a Relying Party to request > authentication of, or assertions for, users or machines (Clients). > These Clients may be named using a NAI name identifier format. > Finally, the subject confirmation methods allow requests and queries > to be issued for a previously authenticated user or machine without > needing to explicitly identify them as the subject. These artifacts > have been defined to permit application in AAA scenarios other than > ABFAB, such as network access. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------070602020507050009080000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear all,

we have generated a new version of the draft including the following changes:
  • General editorial work (typo correction and wordsmithing)  on the document.
  • Addressing of the editorial comments provided by Troy Shields.
  • Made terminology more consistent with ABFAB. Everything now is explained in terms of Clients, RPs, and IdPs.
  • Extended description of the SAML-Message and SAML-Assertion attributes (following the typical procedure with the figure and the description of each field).
  • Changes to the Privacy and the Security Considerations sections.
  • Changes to the IANA Considerations section dealing with the registration of the new attributes.
  • Completed the Acknowledgement section.
Best regards,
Alejandro


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.

        Title           : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML
        Authors         : Josh Howlett
                          Sam Hartman
                          Alejandro Perez-Mendez
	Filename        : draft-ietf-abfab-aaa-saml-10.txt
	Pages           : 24
	Date            : 2015-02-06

Abstract:
   This document describes the use of the Security Assertion Mark-up
   Language (SAML) with RADIUS in the context of the ABFAB architecture.
   It defines two RADIUS attributes, a SAML binding, a SAML name
   identifier format, two SAML profiles, and two SAML confirmation
   methods.  The RADIUS attributes permit encapsulation of SAML
   assertions and protocol messages within RADIUS, allowing SAML
   entities to communicate using the binding.  The two profiles describe
   the application of this binding for ABFAB authentication and
   assertion query/request, enabling a Relying Party to request
   authentication of, or assertions for, users or machines (Clients).
   These Clients may be named using a NAI name identifier format.
   Finally, the subject confirmation methods allow requests and queries
   to be issued for a previously authenticated user or machine without
   needing to explicitly identify them as the subject.  These artifacts
   have been defined to permit application in AAA scenarios other than
   ABFAB, such as network access.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab

--------------070602020507050009080000-- From nobody Mon Feb 9 03:44:42 2015 Return-Path: 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 5F4861A035F for ; Mon, 9 Feb 2015 03:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 a6LoNBM0oXFG for ; Mon, 9 Feb 2015 03:44:37 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id A06BD1A0358 for ; Mon, 9 Feb 2015 03:44:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 9D435487D9; Mon, 9 Feb 2015 12:44:33 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KWEutVAzEaKs; Mon, 9 Feb 2015 12:44:33 +0100 (CET) Received: from [155.54.205.116] (inf-205-116.inf.um.es [155.54.205.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 4B3943F864; Mon, 9 Feb 2015 12:44:31 +0100 (CET) Message-ID: <54D89D9F.3050307@um.es> Date: Mon, 09 Feb 2015 12:44:31 +0100 From: Alejandro Perez Mendez 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> In-Reply-To: <54D4E501.5020701@um.es> Content-Type: multipart/alternative; boundary="------------050500040408080603000706" Archived-At: Cc: Klaas Wierenga 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 11:44:40 -0000 This is a multi-part message in MIME format. --------------050500040408080603000706 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, 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. Best regards, Alejandro El 06/02/15 a las 17:00, Alejandro Perez Mendez escribió: > Dear all, > > we have generated a new version of the draft including the following > changes: > > * General editorial work (typo correction and wordsmithing) on the > document. > * Addressing of the editorial comments provided by Troy Shields. > * Made terminology more consistent with ABFAB. Everything now is > explained in terms of Clients, RPs, and IdPs. > * Extended description of the SAML-Message and SAML-Assertion > attributes (following the typical procedure with the figure and > the description of each field). > * Changes to the Privacy and the Security Considerations sections. > * Changes to the IANA Considerations section dealing with the > registration of the new attributes. > * Completed the Acknowledgement section. > > Best regards, > Alejandro > > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. >> >> Title : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML >> Authors : Josh Howlett >> Sam Hartman >> Alejandro Perez-Mendez >> Filename : draft-ietf-abfab-aaa-saml-10.txt >> Pages : 24 >> Date : 2015-02-06 >> >> Abstract: >> This document describes the use of the Security Assertion Mark-up >> Language (SAML) with RADIUS in the context of the ABFAB architecture. >> It defines two RADIUS attributes, a SAML binding, a SAML name >> identifier format, two SAML profiles, and two SAML confirmation >> methods. The RADIUS attributes permit encapsulation of SAML >> assertions and protocol messages within RADIUS, allowing SAML >> entities to communicate using the binding. The two profiles describe >> the application of this binding for ABFAB authentication and >> assertion query/request, enabling a Relying Party to request >> authentication of, or assertions for, users or machines (Clients). >> These Clients may be named using a NAI name identifier format. >> Finally, the subject confirmation methods allow requests and queries >> to be issued for a previously authenticated user or machine without >> needing to explicitly identify them as the subject. These artifacts >> have been defined to permit application in AAA scenarios other than >> ABFAB, such as network access. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-10 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------050500040408080603000706 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

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.

Best regards,
Alejandro


El 06/02/15 a las 17:00, Alejandro Perez Mendez escribió:
Dear all,

we have generated a new version of the draft including the following changes:
  • General editorial work (typo correction and wordsmithing)  on the document.
  • Addressing of the editorial comments provided by Troy Shields.
  • Made terminology more consistent with ABFAB. Everything now is explained in terms of Clients, RPs, and IdPs.
  • Extended description of the SAML-Message and SAML-Assertion attributes (following the typical procedure with the figure and the description of each field).
  • Changes to the Privacy and the Security Considerations sections.
  • Changes to the IANA Considerations section dealing with the registration of the new attributes.
  • Completed the Acknowledgement section.
Best regards,
Alejandro


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.

        Title           : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML
        Authors         : Josh Howlett
                          Sam Hartman
                          Alejandro Perez-Mendez
	Filename        : draft-ietf-abfab-aaa-saml-10.txt
	Pages           : 24
	Date            : 2015-02-06

Abstract:
   This document describes the use of the Security Assertion Mark-up
   Language (SAML) with RADIUS in the context of the ABFAB architecture.
   It defines two RADIUS attributes, a SAML binding, a SAML name
   identifier format, two SAML profiles, and two SAML confirmation
   methods.  The RADIUS attributes permit encapsulation of SAML
   assertions and protocol messages within RADIUS, allowing SAML
   entities to communicate using the binding.  The two profiles describe
   the application of this binding for ABFAB authentication and
   assertion query/request, enabling a Relying Party to request
   authentication of, or assertions for, users or machines (Clients).
   These Clients may be named using a NAI name identifier format.
   Finally, the subject confirmation methods allow requests and queries
   to be issued for a previously authenticated user or machine without
   needing to explicitly identify them as the subject.  These artifacts
   have been defined to permit application in AAA scenarios other than
   ABFAB, such as network access.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab




_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab

--------------050500040408080603000706-- From nobody Sun Feb 15 03:56:33 2015 Return-Path: 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 098BD1A1AF0 for ; Sun, 15 Feb 2015 03:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 JKO4CeBVkLHk for ; Sun, 15 Feb 2015 03:56:28 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338AB1A1A6F for ; Sun, 15 Feb 2015 03:56:27 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1FBuPLN027368 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Feb 2015 12:56:25 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t1FBuLQ4015280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2015 12:56:23 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1424001384; bh=0BXXXiGoh1ZDaAqFEFwZ9p30pxU00DGNDf8gzFIPGRo=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Y32QI5o7HCLD3tWuThK/WmBYGMDVgIqGdP7LoJ+dsM774kNF4aOcKx7NVbBIn19In o9F72Jy2Rtf+lSEKeYWF6dLMBF26yQ82i/PjM80x4IfU3RoupL16dFvRnO0qu3H8T9 M0Dx0yRUXVj7wG4uPunpfO7Vtsmmflt0ZlUb5UQs= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Sun, 15 Feb 2015 12:56:20 +0100 Message-ID: <54E08964.4040102@sunet.se> Date: Sun, 15 Feb 2015 12:56:20 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alejandro Perez Mendez , abfab@ietf.org References: <20150206154301.31967.50182.idtracker@ietfa.amsl.com> <54D4E501.5020701@um.es> <54D89D9F.3050307@um.es> In-Reply-To: <54D89D9F.3050307@um.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09NQzUpWD - f77b25fe637b - 20150215 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: Klaas Wierenga 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 11:56:31 -0000 On 02/09/2015 12:44 PM, Alejandro Perez Mendez wrote: > Dear all, > > 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. > > Best regards, > Alejandro > Hmm, I'd feel more comfortable if we'd had one or two reviewers... From nobody Tue Feb 17 00:43:50 2015 Return-Path: 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 2EE161A01C6 for ; Tue, 17 Feb 2015 00:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ODjwL7nQmxhc for ; Tue, 17 Feb 2015 00:43:47 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108DD1A0023 for ; Tue, 17 Feb 2015 00:43:47 -0800 (PST) Received: by labgf13 with SMTP id gf13so34364672lab.9 for ; Tue, 17 Feb 2015 00:43:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xi3xHAU8aghQbp2MHLmpPF2/NJ0AKw6kHmtKa2Pv74s=; b=ftj7V2st0mjfQjgFvNqUcnR4mXFWttz0sscLOdHLcwOfnfpHCF90S5lk/EBTWEoxFY E1JKYiRPi1mumYoKjGGdSsUaTNFwX12pnW0x9f0hYCdlhwRfsKXj0M5GXhvrMVGHNCD4 xJqjIyGWQyqzay/tSLvThT5W4JFFHLLX8yCpqIiNvEbb9eEfseHQLNy5/UmCCwDmQvdR sQFscOGkNui7z0QGL3eJSHy+vPmzArS2YtJS03MVxXOQAxmvaOuyBgNVjpQgVIAjYuSN VTBesHgGmKnBV5xmO1w6hhzff0uAm+FV5mWRmTsm5PnpDVTq/Gdjk3OkW0BsLgUFjwYY /8Rg== X-Gm-Message-State: ALoCoQmFdOE0MIcmpmdS4ZV/EiKfWdVjZ83m+lqdXwHvwgccvxi8nTQ36xwVJP2GEZXoR4KiuOn3 X-Received: by 10.152.180.202 with SMTP id dq10mr8136898lac.74.1424162625120; Tue, 17 Feb 2015 00:43:45 -0800 (PST) Received: from [109.105.104.237] ([109.105.104.237]) by mx.google.com with ESMTPSA id am8sm3420776lac.5.2015.02.17.00.43.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 00:43:44 -0800 (PST) Message-ID: <54E2FF40.4040406@mnt.se> Date: Tue, 17 Feb 2015 09:43:44 +0100 From: Leif Johansson 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> In-Reply-To: <54E08964.4040102@sunet.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 08:43:49 -0000 On 02/15/2015 12:56 PM, Leif Johansson wrote: > On 02/09/2015 12:44 PM, Alejandro Perez Mendez wrote: >> Dear all, >> >> 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. >> >> Best regards, >> Alejandro >> > > Hmm, I'd feel more comfortable if we'd had one or two reviewers... In case somebody missed the hint... that was a call for volunteers :-) From stefan@eons.net Tue Feb 17 10:59:45 2015 Return-Path: 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 F110C1A907C for ; Tue, 17 Feb 2015 10:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 fVfMzc9B4QZE for ; Tue, 17 Feb 2015 10:59:43 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5786A1A908A for ; Tue, 17 Feb 2015 10:59:28 -0800 (PST) Received: by iebtr6 with SMTP id tr6so32541614ieb.7 for ; Tue, 17 Feb 2015 10:59:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=qvoH3P2PWKSiFHg7yO5K1543LJ/62r4/OIyJCAgGLIs=; b=Q/C25gWA0jaJ126SdIbPVjXDo5w8oglhQBsgEduw+ZgOmCvewiq1M5RBPQehYFsjZs cgljVoSDli+Z+L2+lSc/4L3t34SWRmqyC6cX1zfweGFvBp972+Hj9RhZw5gzia+a69Fc +99FL3O0l71sDp2xh+v188snVQKSsTWBfFDPRYatQJLQhE2feLn3gDCzCkMlxv0yv1sW jonR3mbtdHfOLIo8oBMyeibD2c5FQkjj5Tn1d1NBCLyLMhSFck/r1h9FkDAw6Cg2q+5G Ao3Is6oS8gg2m4HI54RQSI3e6BLr42LhCirJb2rim6pLUb8Mfc2SfHo0A5yOTx132PfK w11A== X-Gm-Message-State: ALoCoQmlb7WgurQnb1coQ/4lVfqTd6STA2Sy310FNU7O7LQMsXhIoyWIkKcvteK82Dw8xBMBF4Le X-Received: by 10.50.50.140 with SMTP id c12mr29619907igo.5.1424199566468; Tue, 17 Feb 2015 10:59:26 -0800 (PST) MIME-Version: 1.0 Sender: stefan@eons.net Received: by 10.107.17.38 with HTTP; Tue, 17 Feb 2015 10:59:06 -0800 (PST) In-Reply-To: <54E08964.4040102@sunet.se> References: <20150206154301.31967.50182.idtracker@ietfa.amsl.com> <54D4E501.5020701@um.es> <54D89D9F.3050307@um.es> <54E08964.4040102@sunet.se> From: Stefan Paetow Date: Tue, 17 Feb 2015 18:59:06 +0000 X-Google-Sender-Auth: SW5oNwGMV2N23nBe6bbA9mjy6gE Message-ID: To: abfab@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 19:01:57 -0000 > > 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... Ok, mostly grammatical and syntax nits: 1. Introduction: Two sets of bullets in the introduction. The first set ends each bullet with a full-stop. The second doesn't. Thus the corrected text is: 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. 2. Section 4.3.2: Missing full-stop after . Thus the corrected text is (in keeping with the later Relying Parties paragraph): Identity Providers MAY apply policy based on the Relying Party's SAML . 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: 3. Section 4.3.4: Is a comma missing after 'provide policy' in the last sentence of this section, i.e: 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. 4. Section 6.2: Again a missing comma, this time after 'this scenario', i.e: 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. 5. Finally, Section 9: Is that a Relaying or a Relying Party in the first sentence of the first paragraph in this section? Based on the remainder of the text, it should 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. I haven't spotted anything else... feel free to tell me I'm wrong :-) With Regards Stefan From nobody Tue Feb 17 14:50:29 2015 Return-Path: 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 9EE4B1A895E for ; Tue, 17 Feb 2015 14:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-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 qRUllHTU6j7P for ; Tue, 17 Feb 2015 14:50:26 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1F71A8956 for ; Tue, 17 Feb 2015 14:50:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9036920610 for ; Tue, 17 Feb 2015 17:49:38 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeaRejxsS9jZ for ; Tue, 17 Feb 2015 17:49:38 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (gain1-180.nortex.net [63.160.158.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Tue, 17 Feb 2015 17:49:37 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6A21F8043B; Tue, 17 Feb 2015 17:49:52 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Tue, 17 Feb 2015 17:49:52 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 22:50:27 -0000 Section 4: I thought we were going to make RADIUS over TLS a MUST not a SHOULD. Current text says recommended. Section 6.3.3: I would like to state for the record that I believe interlinking the SAML and EAP authentications to permit the SAML request to affect things like TLS resumption and authentication freshness is problematic and will lead to implementation failures (or simply be ignored). I would prefer we not take that approach. However the sense of the room was against me when this was last discussed. I do think an explicit consensus call by chairs if we have not already made such a call would be valuable. I expect that it's likely I'm in the rough. Section 6.4.3: o Assume that the Client's identifier implied by a SAML 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. This draft still does not provide a mechanism to meet the conditions specified in section 4.3.2. In particular, we don't describe how to embed AAA names in requests, responses or metadata. --Sam From stefan.paetow@jisc.ac.uk Wed Feb 18 08:50:02 2015 Return-Path: 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 82B111A8A1A for ; Wed, 18 Feb 2015 08:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 T6qqVz28vAUj for ; Wed, 18 Feb 2015 08:49:58 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1106B1A1BD1 for ; Wed, 18 Feb 2015 08:49:57 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0081.outbound.protection.outlook.com [213.199.154.81]) (Using TLS) by uk-mta-12.uk.mimecast.lan; Wed, 18 Feb 2015 16:49:54 +0000 X-MC-Unique: 1Y4QHqhgSNGdyqUwmcrwGg-1 Received: from AM3PR07MB226.eurprd07.prod.outlook.com (10.242.18.146) by AM3PR07MB0519.eurprd07.prod.outlook.com (10.141.47.19) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 16:49:53 +0000 Received: from AM3PR07MB228.eurprd07.prod.outlook.com (10.242.18.148) by AM3PR07MB226.eurprd07.prod.outlook.com (10.242.18.146) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 16:49:53 +0000 Received: from AM3PR07MB228.eurprd07.prod.outlook.com ([10.242.18.148]) by AM3PR07MB228.eurprd07.prod.outlook.com ([10.242.18.148]) with mapi id 15.01.0087.013; Wed, 18 Feb 2015 16:49:53 +0000 From: Stefan Paetow To: "abfab@ietf.org" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-10.txt Thread-Index: AQHQSRaBlw/AmIcAKEa1fuNBxNIKj5z2o+IA Date: Wed, 18 Feb 2015 16:49:53 +0000 Message-ID: References: <20150206154301.31967.50182.idtracker@ietfa.amsl.com> <54D4E501.5020701@um.es> <54D89D9F.3050307@um.es> <54E08964.4040102@sunet.se> In-Reply-To: <54E08964.4040102@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [212.219.210.246] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB226;UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB226; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(87936001)(230783001)(74482002)(92566002)(66066001)(107886001)(50226001)(86362001)(110136001)(2351001)(62966003)(77156002)(450100001)(46102003)(2501002)(19580405001)(40100003)(99936001)(82746002)(2950100001)(83716003)(36756003)(102836002)(50986999)(76176999)(122556002)(33656002)(106116001)(77096005)(93886004)(2900100001)(19580395003)(2656002)(57306001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB226; H:AM3PR07MB228.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_089443E8-D05F-428B-B5A2-85AE3EE4F802"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 16:49:53.0977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB226 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB0519; X-OriginatorOrg: jisc.ac.uk Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:53:51 -0000 --Apple-Mail=_089443E8-D05F-428B-B5A2-85AE3EE4F802 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> 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,=20 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 in the first paragraph. It = should be: Identity Providers MAY apply policy based on the Relying Party's SAML . 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:=20 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. [...] > o Assume that the Client's identifier implied by a SAML > element, if present, takes precedence over an identifier > implied > by the RADIUS User-Name attribute. >=20 >=20 > *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 may refer to the actual user (I assume that's = the inner?), in which case, 6.4.3 makes sense where the , if it = exists, overrides whatever was in the original request's User-Name = attribute? Or am I mixing things up? Just a question... :-) 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 =20 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=92s 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. --Apple-Mail=_089443E8-D05F-428B-B5A2-85AE3EE4F802 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU5MLiAAoJEBlaw7k/zlFC21cIAKXSolRxmbJ4LtN6chUYLvoe dyqPKbwDzZ6OQtuE5IJTM3xGE2AnCE1hRKktAb7JrigFEbI7xKipPpK2s4szfMTn 6QeEWKXmfs1Jz452/eMJWtz11TM6H36i6OuwbQpezyY51LE3FSpp31XTq3HLR+qZ u/DFC9fRCLvsHGZvRhMyArbPmfmgJgTXHm58DARiJO8/zSEuuChQz5AzZWirHb94 DtsZeGZWWBnrBt/sJXoAfsrl0JF+9+zRo+gslWCEwreCYXbvCF0ES55Pfmh72CVm JA3faFnyj0nDu3YX7RFDLtrsO99NCMSiRhQSkMvp2kY/mGd0NsTXnriqs0+GG4Q= =ZJWt -----END PGP SIGNATURE----- --Apple-Mail=_089443E8-D05F-428B-B5A2-85AE3EE4F802-- From nobody Wed Feb 18 23:07:54 2015 Return-Path: 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 E71711A8882 for ; Wed, 18 Feb 2015 23:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 V8VY4h5VSAcJ for ; Wed, 18 Feb 2015 23:07:50 -0800 (PST) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id C01F01A8880 for ; Wed, 18 Feb 2015 23:07:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 7C2F931C7 for ; Thu, 19 Feb 2015 08:07:46 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UKKKfjy4AmDk for ; Thu, 19 Feb 2015 08:07:46 +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 xenon24.um.es (Postfix) with ESMTPSA id 4F85F2FEC for ; Thu, 19 Feb 2015 08:07:45 +0100 (CET) Message-ID: <54E58BC1.5040405@um.es> Date: Thu, 19 Feb 2015 08:07:45 +0100 From: Alejandro Perez Mendez 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 07:07:53 -0000 Hi Stefan, thanks for the review. I will apply the changes for the next version. Regards, Alejandro El 17/02/15 a las 19:59, 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... > > Ok, mostly grammatical and syntax nits: > > 1. Introduction: > > Two sets of bullets in the introduction. The first set ends each > bullet with a full-stop. The second doesn't. Thus the corrected text > is: > > 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. > > 2. Section 4.3.2: > > Missing full-stop after . Thus the corrected text is (in > keeping with the later Relying Parties paragraph): > > Identity Providers MAY apply policy based on the Relying Party's SAML > . 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: > > 3. Section 4.3.4: > > Is a comma missing after 'provide policy' in the last sentence of this > section, i.e: > > 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. > > 4. Section 6.2: > > Again a missing comma, this time after 'this scenario', i.e: > > 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. > > 5. Finally, Section 9: > > Is that a Relaying or a Relying Party in the first sentence of the > first paragraph in this section? Based on the remainder of the text, > it should 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. > > I haven't spotted anything else... feel free to tell me I'm wrong :-) > > With Regards > > Stefan > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Thu Feb 19 00:00:58 2015 Return-Path: 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 23A241A88C2 for ; Thu, 19 Feb 2015 00:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xBR8rOaY0ewd for ; Thu, 19 Feb 2015 00:00:55 -0800 (PST) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id DC32F1A88C1 for ; Thu, 19 Feb 2015 00:00:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 1EBE9FDA8 for ; Thu, 19 Feb 2015 09:00:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WiUw1T+XP8hI for ; Thu, 19 Feb 2015 09:00: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 xenon24.um.es (Postfix) with ESMTPSA id E6EA5E5C for ; Thu, 19 Feb 2015 09:00:50 +0100 (CET) Message-ID: <54E59831.10108@um.es> Date: Thu, 19 Feb 2015 09:00:49 +0100 From: Alejandro Perez Mendez 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: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 08:00:57 -0000 Hi Sam, thanks for the review. See my comments below. El 17/02/15 a las 23:49, Sam Hartman escribió: > > Section 4: > > I thought we were going to make RADIUS over TLS a MUST not a SHOULD. > Current text says recommended. Whereas version -09 stated once (in section 5.2) that the use of TLS was REQUIRED, along the rest of text it indicated several times this support as RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just homogenized them to the prevailing one. Nevertheless, I think that making TLS a MUST might be limiting. There might be some use case scenarios for this profile where using TLS is not actually required (e.g. other security mechanisms apply). I would see that kind of requirement more for the ABFAB architecture level than for this I-D level. Moreover, in the saml-profiles-2.0-os document, the use of TLS is indicated as RECOMMENDED. > > Section 6.3.3: > > I would like to state for the record that I believe interlinking the > SAML and EAP authentications to permit the SAML request to affect things > like TLS resumption and authentication freshness is problematic and > will lead to implementation failures (or simply be ignored). > > I would prefer we not take that approach. However the sense of the room > was against me when this was last discussed. > I do think an explicit consensus call by chairs if we have not already > made such a call would be valuable. I expect that it's likely I'm in > the rough. I'm ok with such a call, but I'd like to know more about the problems you would expect. As I see it, if the IdP cannot/won't address the constraints called in the AuthnRequest message, it MUST (SHOULD perhaps?) generate an authentication error. > > Section 6.4.3: > > o Assume that the Client's identifier implied by a SAML > 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. This section is dealing with the Client's identifier (Subject), whereas 4.3.1 deals with names of the AAA entities (i.e. RP and IdP, related with Issuer and Recipient at the SAML level). Hence, I don't think section 6.4.3 has a direct impact on what 4.3.1 says. > > > This draft still does not provide a mechanism to meet the conditions > specified in section 4.3.2. In particular, we don't describe how to > embed AAA names in requests, responses or metadata. You're right. I think we should focus on representing this information in the metadata, which is controlled by the recipient, rather than on the information on the wire, which might have been forged by the sender. Regards, Alejandro > > --Sam > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Thu Feb 19 00:06:59 2015 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 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> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080602060208070203090802" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 08:06:58 -0000 This is a multi-part message in MIME format. --------------080602060208070203090802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 in the first paragraph. It should be: > > Identity Providers MAY apply policy based on the Relying Party's SAML > . 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 >> 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 may refer to the actual user (I assume that's the inner?), in which case, 6.4.3 makes sense where the , 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 --------------080602060208070203090802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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

--------------080602060208070203090802-- From nobody Thu Feb 19 00:57:06 2015 Return-Path: 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 678A11A8930 for ; Thu, 19 Feb 2015 00:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 yFaBje0RqJOL for ; Thu, 19 Feb 2015 00:57:03 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6251A892A for ; Thu, 19 Feb 2015 00:57:03 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1J8v0L4022827 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 19 Feb 2015 09:57:00 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t1J8uvlH018768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Feb 2015 09:57:00 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1424336220; bh=Yj7adLN6XuKj0NPHvFRMg3g2Yebnlig5w2Cq7XqD1So=; h=Date:From:To:Subject:References:In-Reply-To; b=32zV8V3pRyvg33DsGMPiwSoxzWeMCgjCqi5iVK7bFlyZ9RkutcHVZ1yTpn3zSxkZV y2wfmkdbt+EYm7zTp3tWB40f8iHyLmwK9P9xdaAFboYksCtZATz0e6USC6vhIhK4hH KysOnpwy5cEEiBwHRUBhqlr2gty37hgGo1HfcYVU= X-Footer: c3VuZXQuc2U= Received: from [193.10.95.116] ([193.10.95.116]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for abfab@ietf.org; Thu, 19 Feb 2015 09:56:56 +0100 Message-ID: <54E5A557.3090603@sunet.se> Date: Thu, 19 Feb 2015 09:56:55 +0100 From: Leif Johansson 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: <54E59831.10108@um.es> In-Reply-To: <54E59831.10108@um.es> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09NS8V0vK - 53061222727f - 20150219 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 08:57:05 -0000 On 02/19/2015 09:00 AM, Alejandro Perez Mendez wrote: > Hi Sam, > > thanks for the review. See my comments below. > > El 17/02/15 a las 23:49, Sam Hartman escribió: >> >> Section 4: >> >> I thought we were going to make RADIUS over TLS a MUST not a SHOULD. >> Current text says recommended. > > Whereas version -09 stated once (in section 5.2) that the use of TLS was > REQUIRED, along the rest of text it indicated several times this support > as RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just homogenized them > to the prevailing one. > > Nevertheless, I think that making TLS a MUST might be limiting. There > might be some use case scenarios for this profile where using TLS is not > actually required (e.g. other security mechanisms apply). I would see > that kind of requirement more for the ABFAB architecture level than for > this I-D level. Moreover, in the saml-profiles-2.0-os document, the use > of TLS is indicated as RECOMMENDED. Speaking as an individual I don't think there are any sane reasons not to use TLS if you relax the requirements on credentials administration (eg run oportunistic TLS). Having said that I think probably RECOMMENDED is strong enough anyway. > >> >> Section 6.3.3: >> >> I would like to state for the record that I believe interlinking the >> SAML and EAP authentications to permit the SAML request to affect things >> like TLS resumption and authentication freshness is problematic and >> will lead to implementation failures (or simply be ignored). >> >> I would prefer we not take that approach. However the sense of the room >> was against me when this was last discussed. >> I do think an explicit consensus call by chairs if we have not already >> made such a call would be valuable. I expect that it's likely I'm in >> the rough. > > I'm ok with such a call, but I'd like to know more about the problems > you would expect. > As I see it, if the IdP cannot/won't address the constraints called in > the AuthnRequest message, it MUST (SHOULD perhaps?) generate an > authentication error. I can make such a call if we have a clear enough statement to call consensus on. MVH leifj From nobody Thu Feb 19 01:17:05 2015 Return-Path: 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 967FB1A8967 for ; Thu, 19 Feb 2015 01:17:03 -0800 (PST) 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 xUPEJdDXZ8Td for ; Thu, 19 Feb 2015 01:16:59 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9981A894C for ; Thu, 19 Feb 2015 01:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1621; q=dns/txt; s=iport; t=1424337418; x=1425547018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=88AW7UOqQJSJCh0rrvFDyX4CuckIDSy3PlALD+1/Vl0=; b=MegiRpZc594F+rBLrCvp558JJ4/9hZN4t1uSF6jC/Fms/MkpfYf4VK6F TKRfuvArvsAGXUAkaFHFRwdaFfuHPLM7Kl1FPX/jwunM89ybRr8vdOV32 huEoXOuOv9Iu4Tfu9f/73RLKnEKiZUt+u6v3NIj9QM2IAqDJIMQX4K8FF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CUBQCcqeVU/4YNJK1bgwaBLATAQYgbAoEXQwEBAQEBAXyEDAEBAQMBeQULAgEIEgYuMhcOAgQOBYgnCNJXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sPhDszB4MWgRQBBI9EiT+TFyKCAhyBUG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,607,1418083200"; d="scan'208";a="125001083" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 19 Feb 2015 09:16:58 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1J9GwYe019716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 09:16:58 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.223]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 03:16:57 -0600 From: "Klaas Wierenga (kwiereng)" To: Leif Johansson Thread-Topic: [abfab] Review of draft-ietf-abfab-aaa-saml-10 Thread-Index: AQHQSwQiq5cBLnmLkEahigu2n+aVb5z4AuWAgAAPrYCAAAWWgA== Date: Thu, 19 Feb 2015 09:16:57 +0000 Message-ID: References: <54E59831.10108@um.es> <54E5A557.3090603@sunet.se> In-Reply-To: <54E5A557.3090603@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.180] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "abfab@ietf.org" Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 09:17:03 -0000 > On 19 Feb 2015, at 09:56, Leif Johansson wrote: >=20 > On 02/19/2015 09:00 AM, Alejandro Perez Mendez wrote: >> Hi Sam, >>=20 >> thanks for the review. See my comments below. >>=20 >> El 17/02/15 a las 23:49, Sam Hartman escribi=F3: >>>=20 >>> Section 4: >>>=20 >>> I thought we were going to make RADIUS over TLS a MUST not a SHOULD. >>> Current text says recommended. >>=20 >> Whereas version -09 stated once (in section 5.2) that the use of TLS was >> REQUIRED, along the rest of text it indicated several times this support >> as RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just homogenized them >> to the prevailing one. >>=20 >> Nevertheless, I think that making TLS a MUST might be limiting. There >> might be some use case scenarios for this profile where using TLS is not >> actually required (e.g. other security mechanisms apply). I would see >> that kind of requirement more for the ABFAB architecture level than for >> this I-D level. Moreover, in the saml-profiles-2.0-os document, the use >> of TLS is indicated as RECOMMENDED. >=20 > Speaking as an individual I don't think there are any sane reasons not > to use TLS if you relax the requirements on credentials administration > (eg run oportunistic TLS). Having said that I think probably RECOMMENDED > is strong enough anyway. speaking as another individual, you could go the route that other drafts ha= ve taken and say something like: TLS is REQUIRED unless alternative methods are used to ensure confidentiali= ty like IPSEC tunnels or a sufficiently secure internal network. Klaas From nobody Thu Feb 19 06:16:32 2015 Return-Path: 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 D17791A8784 for ; Thu, 19 Feb 2015 06:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 pFh0NDj22zjp for ; Thu, 19 Feb 2015 06:16:28 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 353891A1A9A for ; Thu, 19 Feb 2015 06:16:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 8D20348F76 for ; Thu, 19 Feb 2015 15:16:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id awWPBoG5ZWdV for ; Thu, 19 Feb 2015 15:16:26 +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 xenon21.um.es (Postfix) with ESMTPSA id 600DE416C8 for ; Thu, 19 Feb 2015 15:16:25 +0100 (CET) Message-ID: <54E5F038.1080800@um.es> Date: Thu, 19 Feb 2015 15:16:24 +0100 From: Alejandro Perez Mendez 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: <54E59831.10108@um.es> <54E5A557.3090603@sunet.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:16:31 -0000 El 19/02/15 a las 10:16, Klaas Wierenga (kwiereng) escribió: > >> On 19 Feb 2015, at 09:56, Leif Johansson wrote: >> >> On 02/19/2015 09:00 AM, Alejandro Perez Mendez wrote: >>> Hi Sam, >>> >>> thanks for the review. See my comments below. >>> >>> El 17/02/15 a las 23:49, Sam Hartman escribió: >>>> Section 4: >>>> >>>> I thought we were going to make RADIUS over TLS a MUST not a SHOULD. >>>> Current text says recommended. >>> Whereas version -09 stated once (in section 5.2) that the use of TLS was >>> REQUIRED, along the rest of text it indicated several times this support >>> as RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just homogenized them >>> to the prevailing one. >>> >>> Nevertheless, I think that making TLS a MUST might be limiting. There >>> might be some use case scenarios for this profile where using TLS is not >>> actually required (e.g. other security mechanisms apply). I would see >>> that kind of requirement more for the ABFAB architecture level than for >>> this I-D level. Moreover, in the saml-profiles-2.0-os document, the use >>> of TLS is indicated as RECOMMENDED. >> Speaking as an individual I don't think there are any sane reasons not >> to use TLS if you relax the requirements on credentials administration >> (eg run oportunistic TLS). Having said that I think probably RECOMMENDED >> is strong enough anyway. > speaking as another individual, you could go the route that other drafts have taken and say something like: > > TLS is REQUIRED unless alternative methods are used to ensure confidentiality like IPSEC tunnels or a sufficiently secure internal network. That text sounds quite reasonable to me. I was also thinking in including DTLS as an alternative. Regards, Alejandro > > Klaas > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Thu Feb 19 10:55:02 2015 Return-Path: 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 2CD211A0158 for ; Thu, 19 Feb 2015 10:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] 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 vKoHurYk8bIR for ; Thu, 19 Feb 2015 10:54:59 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69181A001C for ; Thu, 19 Feb 2015 10:54:58 -0800 (PST) Received: from Philemon (96-41-163-75.dhcp.mdfd.or.charter.com [96.41.163.75]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 11AB52CA48; Thu, 19 Feb 2015 10:54:57 -0800 (PST) From: "Jim Schaad" To: Date: Thu, 19 Feb 2015 10:54:07 -0800 Message-ID: <021501d04c75$711f84c0$535e8e40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AdBFkzRab7KburqvQxaFeYcI9p7XRA== Content-Language: en-us Archived-At: Cc: abfab@ietf.org Subject: [abfab] Comments on draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 18:55:01 -0000 I really want to see this document done as it is now the document holding up the ABFAB cluster of documents in the RFC editor queue. 1. Section 1 - Paragraph 3 - There is no longer a document I-D.jones-diameter-abfab and there is currently no prospect of such a document coming back into existence anytime soon. The paragraph and the reference should be killed. 2. Section 4.2 - Please change the MAY back to a can 'this profile can take' There is no real protocol statement here. If you wanted to make one then it should be a lot higher than MAY as the odds are that SAML statements are not going to be transportable in a large number of cases without either this or the big packet size draft being implemented. 3. Given the way that messages and assertions are being separated in section 4.2, I think that we should consider renaming SAML-Message to be SAML-Protocol. This makes it clearer that protocol messages go here and assertions go in SAML-Assertion. It is a bit confusing to talk about SAML protocol messages, SAML-Message and RADIUS Access-Request message in proximity. Making both of the SAML items be protocol I think would clarify things. 4. Section 4.2 - s/Therefore, other arbitrary RADIUS attributes MAY be used in either the request or response./Therefore, other arbitrary RADIUS attributes will be used in requests and responses./ 5. Section 4.3.2 - Last three paragraphs - If the SAML Issuer entityID is of the form of an NAI and the realms match between the IdP and the SAML NAI, are these statements still true or can the SAML policy still be applied or is that just a match for what happens in section 4.3.1? 6. Section 4.3.3 - Can we really say that XML signatures are outside of the scope of the binding given that section 4.3.2 is saying that there are cases where signatures are going to be needed? I think we can just delete everything following ", but this". 7. Section 5 - I would like to add the following paragraph: There are cases where the RP does not have a full NAI name or the IdP will not release a full NAI name to the RP due to policy. In these cases, the domain only form of the NAI can be used. 8. Section 6 - I am having a problem with the overview in this section. It is quite clear from the overview that this is designed to be a query/response protocol. It is not clear from the overview that any such thing as an IdP spontaneously returning a SAML statement or responding with a SAML statement that has nothing to do with the query is part of the profile. I will be honest, I would prefer that the binding be exactly what is stated in the overview. If the binding is to be adhered to, then the bad behavior should not be permitted. 9. Should section 6.1 Conformation Method identifiers also refer to the ones in section 8? I think so 10. Section 6.2 - If one is using this binding, is it really optional to issue the message in step 2? It would seem that if you are using this binding one is going to do the SAML stuff. If is not doing the SAML stuff then one is not using this binding. 11. Section 6.2 - Bindings - s/not require the use of/not use/ The use of require seems to me to imply there are cases where HTTP based bindings could be used. 12. Section 6.2 step 2 - s/may optionally issue/issues/ 13. Section 6.3.2 - s/MAY include/includes/ s/this RADIUS/the RADIUS/ s/SAML RADIUS binding/SAML-Message RADIUS attribute/ s/destination MAY be/destination may be/ 14. Section 6.3.3 - What is "RADIUS authentication"? We have said that you need to do EAP for ABFAB however no restrictions for non-ABFAB methods. Do we consider any RADIUS authentication method to be sufficient? 13. Section 6.3.4 - I would prefer that this read The IdP MUST issue a message to the RP that is consistent with the authentication results, as described in [OASIS.saml-core-2.0-os]. This SAML response is delivered to the Relying Party using the SAML RADIUS binding described in Section 4. If a response message is not returned by the IdP, the RP MUST NOT assume that the authentication was performed in a manner consistent with the request. 14. Section 6.4.2 - If the IdP cannot or will not satisfy the request, it MUST either respond with a message containing an appropriate error status code or codes and/or respond with a RADIUS access denied message. 15. Section 6.4.2 - Is the last bullet item normal for a SAML provider? Specifically, that one can authenticate, but ignore any of the actual requests from the RP. If not, should we make some statements about telling the RP that we did not follow the instructions? Possibly by either an error or no response (if the IdP does not support the binding). 16. Section 6.4.4 - I think that this should become a completely separate binding. Let's make the spontaneous stuff be a single separate binding. 17. Section 7.3.1 - Bullet #1 - I am having problems with this because it would potentially kill the machine confirmation type as a request. I am not even sure what it means for the identifiers to be different, you might want to discuss that instead. Do you really mean to say that these names need to be, in some way, consistent instead? 18. Neither in section 6 or section 7 is it made clear which RADIUS attribute is to be used in sending the request and the response. This should be made explicit even if we don't create a new binding for the spontaneous sending of SAML from the IdP to the RP. 19. These are not RADIUS State confirmation methods - they are SAML Subject Confirmation methods. As it currently stands, it is not clear where these go. 20. I want to sit down with the authors in Dallas and talk about the change in names that was made for revision -10. I think that many of these changes are potentially harmful for clarity of the document. Jim From nobody Thu Feb 19 11:13:55 2015 Return-Path: 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 5AE4A1A00A7 for ; Thu, 19 Feb 2015 11:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 OpElmkDtzJHk for ; Thu, 19 Feb 2015 11:13:44 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35AA1A00A8 for ; Thu, 19 Feb 2015 11:13:41 -0800 (PST) Received: from Philemon (96-41-163-75.dhcp.mdfd.or.charter.com [96.41.163.75]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 40CEE38F57; Thu, 19 Feb 2015 11:13:41 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , References: <54E59831.10108@um.es> In-Reply-To: <54E59831.10108@um.es> Date: Thu, 19 Feb 2015 11:12:09 -0800 Message-ID: <021601d04c78$0e91b140$2bb513c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQJZq/H8Ui9x/9Wg310zZknKKkTVXQD7W0kKm928GwA= Content-Language: en-us Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:13:46 -0000 > -----Original Message----- > From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Alejandro = Perez > Mendez > Sent: Thursday, February 19, 2015 12:01 AM > To: abfab@ietf.org > Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 >=20 > Hi Sam, >=20 > thanks for the review. See my comments below. >=20 > El 17/02/15 a las 23:49, Sam Hartman escribi=F3: > > > > Section 4: > > > > I thought we were going to make RADIUS over TLS a MUST not a SHOULD. > > Current text says recommended. >=20 > Whereas version -09 stated once (in section 5.2) that the use of TLS = was > REQUIRED, along the rest of text it indicated several times this = support as > RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just homogenized them = to > the prevailing one. >=20 > Nevertheless, I think that making TLS a MUST might be limiting. There might > be some use case scenarios for this profile where using TLS is not actually > required (e.g. other security mechanisms apply). I would see that kind = of > requirement more for the ABFAB architecture level than for this I-D = level. > Moreover, in the saml-profiles-2.0-os document, the use of TLS is indicated > as RECOMMENDED. >=20 > > > > Section 6.3.3: > > > > I would like to state for the record that I believe interlinking the > > SAML and EAP authentications to permit the SAML request to affect > > things like TLS resumption and authentication freshness is > > problematic and will lead to implementation failures (or simply be ignored). > > > > I would prefer we not take that approach. However the sense of the > > room was against me when this was last discussed. > > I do think an explicit consensus call by chairs if we have not = already > > made such a call would be valuable. I expect that it's likely I'm = in > > the rough. >=20 > I'm ok with such a call, but I'd like to know more about the problems = you > would expect. > As I see it, if the IdP cannot/won't address the constraints called in = the > AuthnRequest message, it MUST (SHOULD perhaps?) generate an > authentication error. If we don't make TLS a MUST, then we probably need to strengthen the = privacy considerations to talk about the fact that eavesdroppers on the wire = will be able to get to the contents of the SAML statements being made. It is = not just an issue of RADIUS Proxies. In any event I don't know how this = can be enforced for anything but the first and last steps in a multi-proxy = world. This probably also needs to be stressed. >=20 >=20 > > > > Section 6.4.3: > > > > o Assume that the Client's identifier implied by a SAML = > > 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. >=20 > This section is dealing with the Client's identifier (Subject), = whereas > 4.3.1 deals with names of the AAA entities (i.e. RP and IdP, related = with > Issuer and Recipient at the SAML level). Hence, I don't think section 6.4.3 has > a direct impact on what 4.3.1 says. >=20 > > > > > > This draft still does not provide a mechanism to meet the conditions > > specified in section 4.3.2. In particular, we don't describe how to > > embed AAA names in requests, responses or metadata. >=20 > You're right. I think we should focus on representing this information = in the > metadata, which is controlled by the recipient, rather than on the > information on the wire, which might have been forged by the sender. Why do you not think that the NAI name form is sufficient for this = purpose? >=20 > Regards, > Alejandro >=20 > > > > --Sam > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Thu Feb 19 11:16:38 2015 Return-Path: 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 E50A91A0039 for ; Thu, 19 Feb 2015 11:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 AEzjIN0WX41N for ; Thu, 19 Feb 2015 11:16:35 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FE31A0023 for ; Thu, 19 Feb 2015 11:16:35 -0800 (PST) Received: from Philemon (96-41-163-75.dhcp.mdfd.or.charter.com [96.41.163.75]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A391B2CA49; Thu, 19 Feb 2015 11:16:34 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , References: <54E59831.10108@um.es> <54E5A557.3090603@sunet.se> <54E5F038.1080800@um.es> In-Reply-To: <54E5F038.1080800@um.es> Date: Thu, 19 Feb 2015 11:15:44 -0800 Message-ID: <021701d04c78$75eeb8b0$61cc2a10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQJZq/H8Ui9x/9Wg310zZknKKkTVXQD7W0kKASR6v6gAzTka3wIXypPdm71xgJA= Content-Language: en-us Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:16:37 -0000 > -----Original Message----- > From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Alejandro = Perez > Mendez > Sent: Thursday, February 19, 2015 6:16 AM > To: abfab@ietf.org > Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 >=20 >=20 > El 19/02/15 a las 10:16, Klaas Wierenga (kwiereng) escribi=F3: > > > >> On 19 Feb 2015, at 09:56, Leif Johansson wrote: > >> > >> On 02/19/2015 09:00 AM, Alejandro Perez Mendez wrote: > >>> Hi Sam, > >>> > >>> thanks for the review. See my comments below. > >>> > >>> El 17/02/15 a las 23:49, Sam Hartman escribi=F3: > >>>> Section 4: > >>>> > >>>> I thought we were going to make RADIUS over TLS a MUST not a > SHOULD. > >>>> Current text says recommended. > >>> Whereas version -09 stated once (in section 5.2) that the use of = TLS > >>> was REQUIRED, along the rest of text it indicated several times = this > >>> support as RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just > >>> homogenized them to the prevailing one. > >>> > >>> Nevertheless, I think that making TLS a MUST might be limiting. > >>> There might be some use case scenarios for this profile where = using > >>> TLS is not actually required (e.g. other security mechanisms = apply). > >>> I would see that kind of requirement more for the ABFAB = architecture > >>> level than for this I-D level. Moreover, in the = saml-profiles-2.0-os > >>> document, the use of TLS is indicated as RECOMMENDED. > >> Speaking as an individual I don't think there are any sane reasons > >> not to use TLS if you relax the requirements on credentials > >> administration (eg run oportunistic TLS). Having said that I think > >> probably RECOMMENDED is strong enough anyway. > > speaking as another individual, you could go the route that other = drafts > have taken and say something like: > > > > TLS is REQUIRED unless alternative methods are used to ensure > confidentiality like IPSEC tunnels or a sufficiently secure internal network. >=20 > That text sounds quite reasonable to me. I was also thinking in = including DTLS > as an alternative. In my mind DTLS would be acceptable if one says TLS is required. They = are the same basic mechanism in my mind. However the use of DTLS in this scenario is going to be somewhat problematic as it would lead to even = more fragmenting. The big reason for using TLS/IP rather than DTLS is the upcoming support for large packets. =20 Not clear that the large packet draft is written to allow it to be used = in a non-TLS situation. Probably need to verify that it is if we want to = include things like IPsec as options Jim >=20 > Regards, > Alejandro > > > > Klaas > > > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Thu Feb 26 03:00:59 2015 Return-Path: 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 1CBCE1A3BA4 for ; Thu, 26 Feb 2015 03:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 pPDdZvAQTqni for ; Thu, 26 Feb 2015 03:00:53 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3001A1AC6 for ; Thu, 26 Feb 2015 03:00:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 728C4BA51; Thu, 26 Feb 2015 12:00:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AO5tV-NE+GSj; Thu, 26 Feb 2015 12:00: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 xenon23.um.es (Postfix) with ESMTPSA id 5EF582031; Thu, 26 Feb 2015 12:00:45 +0100 (CET) Message-ID: <54EEFCDD.5030705@um.es> Date: Thu, 26 Feb 2015 12:00:45 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jim Schaad , draft-ietf-abfab-aaa-saml@tools.ietf.org References: <021501d04c75$711f84c0$535e8e40$@augustcellars.com> In-Reply-To: <021501d04c75$711f84c0$535e8e40$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 11:00:58 -0000 Hi Jim, thank you for the review. See my comments inline. El 19/02/15 a las 19:54, Jim Schaad escribió: > I really want to see this document done as it is now the document holding up > the ABFAB cluster of documents in the RFC editor queue. > > 1. Section 1 - Paragraph 3 - There is no longer a document > I-D.jones-diameter-abfab and there is currently no prospect of such a > document coming back into existence anytime soon. The paragraph and the > reference should be killed. Agree. > 2. Section 4.2 - Please change the MAY back to a can 'this profile can > take' There is no real protocol statement here. If you wanted to make one > then it should be a lot higher than MAY as the odds are that SAML statements > are not going to be transportable in a large number of cases without either > this or the big packet size draft being implemented. Makes sense. > 3. Given the way that messages and assertions are being separated in > section 4.2, I think that we should consider renaming SAML-Message to be > SAML-Protocol. This makes it clearer that protocol messages go here and > assertions go in SAML-Assertion. It is a bit confusing to talk about SAML > protocol messages, SAML-Message and RADIUS Access-Request message in > proximity. Making both of the SAML items be protocol I think would clarify > things. I would like to hear the opinion of the original authors on this. > 4. Section 4.2 - s/Therefore, other arbitrary RADIUS attributes MAY be used > in either the request or response./Therefore, other arbitrary RADIUS > attributes will be used in requests and responses./ Makes sense, since there will be always at least an User-Name, etc. > 5. Section 4.3.2 - Last three paragraphs - If the SAML Issuer entityID is of > the form of an NAI and the realms match between the IdP and the SAML NAI, > are these statements still true or can the SAML policy still be applied or > is that just a match for what happens in section 4.3.1? I think this would be somehow similar to what Josh proposed in IETF 90 (http://tools.ietf.org/agenda/90/slides/slides-90-abfab-3.pdf), but he was defining a different naming scheme instead of NAI name format. Then, the linking between SAML and AAA names would be done implicitly, when both names match, and no metadata or signatures would be required. But this proposal got some objections due to its complexity, preferring the "have metadata" option, if I recall correctly. Anyway, I'm not sure whether the NAI Name format can be directly applied to IdPs and RPs rather and only to Clients. > 6. Section 4.3.3 - Can we really say that XML signatures are outside of the > scope of the binding given that section 4.3.2 is saying that there are cases > where signatures are going to be needed? I think we can just delete > everything following ", but this". I agree. > 7. Section 5 - I would like to add the following paragraph: > > There are cases where the RP does not have a full NAI name or the IdP will > not release a full NAI name to the RP due to policy. In these cases, the > domain only form of the NAI can be used. The domain-only representation seems to be included in [I-D.ietf-radext-nai]. Is it really required to mention it here? I'm not against it, just asking. > 8. Section 6 - I am having a problem with the overview in this section. It > is quite clear from the overview that this is designed to be a > query/response protocol. It is not clear from the overview that any such > thing as an IdP spontaneously returning a SAML statement or responding with > a SAML statement that has nothing to do with the query is part of the > profile. I will be honest, I would prefer that the binding be exactly what > is stated in the overview. If the binding is to be adhered to, then the bad > behavior should not be permitted. Umm. The overview does not mention anything about the SAML AuthnRequest, does it? It only mentions that the IdP will generate an authentication assertion as a result. It can be as a result of a explicit or just spontaneously. > 9. Should section 6.1 Conformation Method identifiers also refer to the > ones in section 8? I think so Section 8 specifies that "the Subject is the system entity (either the user or machine) authenticated by a previously transmitted RADIUS Access-Accept message". However, as section 6.1 describes the authentication profile, there is no previous RADIUS State attribute to be used for identification yet. In my opinion, the identifiers in section 8 are more intended for the Assertion Query/Request profile, that happens after the authentication process was completed. > > 10. Section 6.2 - If one is using this binding, is it really optional to > issue the message in step 2? It would seem that if you > are using this binding one is going to do the SAML stuff. If is not doing > the SAML stuff then one is not using this binding. It is optional as it is stated that way in section 4.2, where two modes are described. The first one is a request-response model, where the second one is just a spontaneous response . Said that, I see your point. However, I'm not aware of the reasons why this was allowed in the first place. I guess the reason is simplicity (as in this profile an AuthnRequest will typically contain no useful information other than just signalling the intention of obtaining a SAML Assertion as a result), and avoiding sending AuthnRequest and SAML-Message attributes to a RADIUS server which is not able to understand this, as it might return an error when the attributes cannot be understood. Nevertheless, the original authors might provide a better response. > > 11. Section 6.2 - Bindings - s/not require the use of/not use/ The use of > require seems to me to imply there are cases where HTTP based bindings could > be used. Right. > > 12. Section 6.2 step 2 - s/may optionally issue/issues/ > 13. Section 6.3.2 - s/MAY include/includes/ > s/this RADIUS/the RADIUS/ > s/SAML RADIUS binding/SAML-Message RADIUS attribute/ > s/destination MAY be/destination may be/ They are related to the previous comments. We need some discussion on this. > > 14. Section 6.3.3 - What is "RADIUS authentication"? We have said that you > need to do EAP for ABFAB however no restrictions for non-ABFAB methods. Do > we consider any RADIUS authentication method to be sufficient? Section 6.2 states that "This profile does not require the use of any particular authentication method. The ABFAB architecture does require the use of EAP [RFC3579], but this specification may be used in other non-ABFAB scenarios." I think this would be similar to what happens in the Web world. When the User is redirected to the IdP, there isn't any restriction on how the IDP authenticates the User. The SAML Web-SSO profile states that "....the identity provider may use any means to authenticate the user agent, subject to any requirements included in the in the form of the element." Although, in the context of ABFAB, we need an EAP authentication. > > 13. Section 6.3.4 - I would prefer that this read > The IdP MUST issue a message to the RP that is consistent > with the authentication results, as described in [OASIS.saml-core-2.0-os]. > This SAML response is delivered to the > Relying Party using the SAML RADIUS binding described in Section 4. If a > response message is not returned by the IdP, the RP MUST NOT assume that the > authentication was performed in a manner consistent with the request. I agree with this new text, but only if we agree on making the AuthnRequest mandatory. Otherwise, the RP might not receive a SAML response when no request has been sent, and still being consistent with the request. > Section 6.4.2 - If the IdP cannot or will not satisfy the request, it > MUST either respond with a message containing an > appropriate error status code or codes and/or respond with a RADIUS access > denied message. I think it makes sense to make this mandatory rather than optional. > > 15. Section 6.4.2 - Is the last bullet item normal for a SAML provider? > Specifically, that one can authenticate, but ignore any of the actual > requests from the RP. If not, should we make some statements about telling > the RP that we did not follow the instructions? Possibly by either an error > or no response (if the IdP does not support the binding). I think that's allowed by SAML specification. In fact, this paragraph is almost word-by-word copied from section 4.1.4.2 of the saml-profiles-2.0-os. > 16. Section 6.4.4 - I think that this should become a completely separate > binding. Let's make the spontaneous stuff be a single separate binding. Currently, spontaneous stuff is a separated model of the same binding. We could make this more clear by creating subsections in section 4.2. I'm not sure how creating an additional binding would increase the complexity of the document, since we might need also to duplicate profiles, etc. > > 17. Section 7.3.1 - Bullet #1 - I am having problems with this because it > would potentially kill the machine confirmation type as a request. I am > not even sure what it means for the identifiers to be different, you might > want to discuss that instead. Do you really mean to say that these names > need to be, in some way, consistent instead? Yes, I think that makes more sense. > > 18. Neither in section 6 or section 7 is it made clear which RADIUS > attribute is to be used in sending the request and the response. This > should be made explicit even if we don't create a new binding for the > spontaneous sending of SAML from the IdP to the RP. Right, that needs to be clarified. > > 19. These are not RADIUS State confirmation methods - they are SAML Subject > Confirmation methods. As it currently stands, it is not clear where these > go. I think a better name would be "SAML V2.0 RADIUS State Subject Confirmation Methods", being more consistent with others such as the "SAML V2.0 Kerberos Subject Confirmation Method". > 20. I want to sit down with the authors in Dallas and talk about the change > in names that was made for revision -10. I think that many of these > changes are potentially harmful for clarity of the document. The idea behind this change was to make it consistent with the ABFAB terminology (as this is an ABFAB WG document). Before the change, we had in the document: Client = Principal/User Agent/Client IDP = SAML responder/SAML Issuer/IDP RP = SAML requester/SAML comsumer/RP At some points it was difficult for a non SAML expert to know who the SAML Issuer or the requester was, for instance. Sadly, I will not be in Dallas. I don't know whether Sam or Josh will be there. In any case, we can make an audio conference at a time that suits us both. Regards, Alejandro > > Jim > > > > From nobody Thu Feb 26 03:03:57 2015 Return-Path: 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 BDF221A6F38 for ; Thu, 26 Feb 2015 03:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zWlXuxu7jDWq for ; Thu, 26 Feb 2015 03:03:54 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id B34611A6F20 for ; Thu, 26 Feb 2015 03:03:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 8F0706B; Thu, 26 Feb 2015 12:03:52 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dL9YEyUfI2pt; Thu, 26 Feb 2015 12:03:52 +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 xenon23.um.es (Postfix) with ESMTPSA id D2A7BB9F8; Thu, 26 Feb 2015 12:03:50 +0100 (CET) Message-ID: <54EEFD96.3030500@um.es> Date: Thu, 26 Feb 2015 12:03:50 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jim Schaad , abfab@ietf.org References: <54E59831.10108@um.es> <021601d04c78$0e91b140$2bb513c0$@augustcellars.com> In-Reply-To: <021601d04c78$0e91b140$2bb513c0$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 11:03:55 -0000 El 19/02/15 a las 20:12, Jim Schaad escribió: > >> -----Original Message----- >> From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Alejandro Perez >> Mendez >> Sent: Thursday, February 19, 2015 12:01 AM >> To: abfab@ietf.org >> Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 >> >> Hi Sam, >> >> thanks for the review. See my comments below. >> >> El 17/02/15 a las 23:49, Sam Hartman escribió: >>> Section 4: >>> >>> I thought we were going to make RADIUS over TLS a MUST not a SHOULD. >>> Current text says recommended. >> Whereas version -09 stated once (in section 5.2) that the use of TLS was >> REQUIRED, along the rest of text it indicated several times this support > as >> RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just homogenized them to >> the prevailing one. >> >> Nevertheless, I think that making TLS a MUST might be limiting. There > might >> be some use case scenarios for this profile where using TLS is not > actually >> required (e.g. other security mechanisms apply). I would see that kind of >> requirement more for the ABFAB architecture level than for this I-D level. >> Moreover, in the saml-profiles-2.0-os document, the use of TLS is > indicated >> as RECOMMENDED. >> >>> Section 6.3.3: >>> >>> I would like to state for the record that I believe interlinking the >>> SAML and EAP authentications to permit the SAML request to affect >>> things like TLS resumption and authentication freshness is >>> problematic and will lead to implementation failures (or simply be > ignored). >>> I would prefer we not take that approach. However the sense of the >>> room was against me when this was last discussed. >>> I do think an explicit consensus call by chairs if we have not already >>> made such a call would be valuable. I expect that it's likely I'm in >>> the rough. >> I'm ok with such a call, but I'd like to know more about the problems you >> would expect. >> As I see it, if the IdP cannot/won't address the constraints called in the >> AuthnRequest message, it MUST (SHOULD perhaps?) generate an >> authentication error. > If we don't make TLS a MUST, then we probably need to strengthen the privacy > considerations to talk about the fact that eavesdroppers on the wire will be > able to get to the contents of the SAML statements being made. It is not > just an issue of RADIUS Proxies. In any event I don't know how this can be > enforced for anything but the first and last steps in a multi-proxy world. > This probably also needs to be stressed. Right. I will add that to the considerations. Regards, Alejandro > >> >>> Section 6.4.3: >>> >>> o Assume that the Client's identifier implied by a SAML >>> 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. >> This section is dealing with the Client's identifier (Subject), whereas >> 4.3.1 deals with names of the AAA entities (i.e. RP and IdP, related with >> Issuer and Recipient at the SAML level). Hence, I don't think section > 6.4.3 has >> a direct impact on what 4.3.1 says. >> >>> >>> This draft still does not provide a mechanism to meet the conditions >>> specified in section 4.3.2. In particular, we don't describe how to >>> embed AAA names in requests, responses or metadata. >> You're right. I think we should focus on representing this information in > the >> metadata, which is controlled by the recipient, rather than on the >> information on the wire, which might have been forged by the sender. > Why do you not think that the NAI name form is sufficient for this purpose? > >> Regards, >> Alejandro >> >>> --Sam >>> >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab From nobody Thu Feb 26 03:05:09 2015 Return-Path: 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 6BF6D1A6FF9 for ; Thu, 26 Feb 2015 03:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9RW5QQk_yHPC for ; Thu, 26 Feb 2015 03:05:06 -0800 (PST) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id C48411A6F20 for ; Thu, 26 Feb 2015 03:05:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 09216A79E; Thu, 26 Feb 2015 12:05:04 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bWBDueXwWVRG; Thu, 26 Feb 2015 12:05:03 +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 xenon24.um.es (Postfix) with ESMTPSA id 514CFA792; Thu, 26 Feb 2015 12:05:02 +0100 (CET) Message-ID: <54EEFDDE.5050401@um.es> Date: Thu, 26 Feb 2015 12:05:02 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jim Schaad , abfab@ietf.org References: <54E59831.10108@um.es> <54E5A557.3090603@sunet.se> <54E5F038.1080800@um.es> <021701d04c78$75eeb8b0$61cc2a10$@augustcellars.com> In-Reply-To: <021701d04c78$75eeb8b0$61cc2a10$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 11:05:08 -0000 El 19/02/15 a las 20:15, Jim Schaad escribió: > >> -----Original Message----- >> From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Alejandro Perez >> Mendez >> Sent: Thursday, February 19, 2015 6:16 AM >> To: abfab@ietf.org >> Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-10 >> >> >> El 19/02/15 a las 10:16, Klaas Wierenga (kwiereng) escribió: >>>> On 19 Feb 2015, at 09:56, Leif Johansson wrote: >>>> >>>> On 02/19/2015 09:00 AM, Alejandro Perez Mendez wrote: >>>>> Hi Sam, >>>>> >>>>> thanks for the review. See my comments below. >>>>> >>>>> El 17/02/15 a las 23:49, Sam Hartman escribió: >>>>>> Section 4: >>>>>> >>>>>> I thought we were going to make RADIUS over TLS a MUST not a >> SHOULD. >>>>>> Current text says recommended. >>>>> Whereas version -09 stated once (in section 5.2) that the use of TLS >>>>> was REQUIRED, along the rest of text it indicated several times this >>>>> support as RECOMMENDED (sections 7.4.5, 8.3.2, and 10). I just >>>>> homogenized them to the prevailing one. >>>>> >>>>> Nevertheless, I think that making TLS a MUST might be limiting. >>>>> There might be some use case scenarios for this profile where using >>>>> TLS is not actually required (e.g. other security mechanisms apply). >>>>> I would see that kind of requirement more for the ABFAB architecture >>>>> level than for this I-D level. Moreover, in the saml-profiles-2.0-os >>>>> document, the use of TLS is indicated as RECOMMENDED. >>>> Speaking as an individual I don't think there are any sane reasons >>>> not to use TLS if you relax the requirements on credentials >>>> administration (eg run oportunistic TLS). Having said that I think >>>> probably RECOMMENDED is strong enough anyway. >>> speaking as another individual, you could go the route that other drafts >> have taken and say something like: >>> TLS is REQUIRED unless alternative methods are used to ensure >> confidentiality like IPSEC tunnels or a sufficiently secure internal > network. >> That text sounds quite reasonable to me. I was also thinking in including > DTLS >> as an alternative. > In my mind DTLS would be acceptable if one says TLS is required. They are > the same basic mechanism in my mind. However the use of DTLS in this > scenario is going to be somewhat problematic as it would lead to even more > fragmenting. The big reason for using TLS/IP rather than DTLS is the > upcoming support for large packets. > > Not clear that the large packet draft is written to allow it to be used in a > non-TLS situation. Probably need to verify that it is if we want to include > things like IPsec as options We have our fragmentation draft for UDP, so that should not be a problem. Regards, Alejandro > > Jim > >> Regards, >> Alejandro >>> Klaas >>> >>> >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab