Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Fri, 12 Feb 2010 23:12:52 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > There we're in complete agreement. However, I view the need=20 > to support this sort of trust path discovery as very much a=20 > next stage issue. The rest of the project seems squarely in=20 > the category of engineering work. Agreed. It would be nice to have a story for 3 to 5 years hence, but as you say it is important that we focus on engineering solutions to demonstrable problems of today. I will try to control my enthusiasm for fixing tomorrow's poorly-defined problems :-) josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Fri, 12 Feb 2010 22:10:50 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > I think we're on the same page regarding actors. I didn't=20 > see anything new in your definition of actors. That's good. What followed that is the brain dump, and so I'm not too surprised that you raise a number of issues with that. I understand, in particular, your skepticism concerning trust path discovery. I guess this boils down to personal opinion about the likely future scale of federated systems. You're probably right that we could live without trust path discovery purely within the European Higher Education community over the next 2 or 3 years. However - on the evidence of the adoption of federated identity within the HE community - I believe that we're in the early stages of exponential growth. While the absolute numbers are nowhere near Internet-scale at the moment, I believe that it's only a matter of time. It will escape the petri dishes of .gov, .edu, large .com, etc, and it I think it would be prudent to be prepared. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From alex@um.es Wed Jan 4 01:14:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D63921F8646 for ; Wed, 4 Jan 2012 01:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JKQQoMHmaq9 for ; Wed, 4 Jan 2012 01:14:53 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1600E21F860F for ; Wed, 4 Jan 2012 01:14:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id A658053602 for ; Wed, 4 Jan 2012 10:14:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id myknL+qvGAVa for ; Wed, 4 Jan 2012 10:14:51 +0100 (CET) Received: from [192.168.1.130] (165.247.221.87.dynamic.jazztel.es [87.221.247.165]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id E2F82535CC for ; Wed, 4 Jan 2012 10:14:49 +0100 (CET) Message-ID: <4F041888.8030105@um.es> Date: Wed, 04 Jan 2012 10:14:48 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "abfab@ietf.org" References: <4F041846.1020200@um.es> In-Reply-To: <4F041846.1020200@um.es> X-Forwarded-Message-Id: <4F041846.1020200@um.es> Content-Type: multipart/mixed; boundary="------------040203070409080707090405" Subject: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2012 09:14:54 -0000 This is a multi-part message in MIME format. --------------040203070409080707090405 Content-Type: multipart/alternative; boundary="------------000606070000080507080005" --------------000606070000080507080005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Mensaje original -------- Asunto: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted Fecha: Wed, 04 Jan 2012 10:13:42 +0100 De: Alejandro Perez Mendez Para: ietf-krb-wg@lists.anl.gov Dear all, We have submitted a new version of draft-perez-krb-wg-gss-preauth (pre-authentication mechanism for Kerberos based on the GSS-API). The abstract of the document is the following: This document describes a pre-authentication mechanism for Kerberos based on the Generic Security Service Application Program Interface (GSS-API), which allows a Key Distribution Center (KDC) to authenticate clients by using any GSS mechanism. Changes include: * Added motivation section indicating why this is required. * Added summary of the dicussion about statefull vs. stateless of the KDC when using the GSS-API. You can access the document following this link: http://www.ietf.org/id/draft-perez-krb-wg-gss-preauth-01.txt Best regards, Alejandro --------------000606070000080507080005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI

-------- Mensaje original --------
Asunto: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted
Fecha: Wed, 04 Jan 2012 10:13:42 +0100
De: Alejandro Perez Mendez <alex@um.es>
Para: ietf-krb-wg@lists.anl.gov <ietf-krb-wg@lists.anl.gov>


Dear all,

We have submitted a new version of draft-perez-krb-wg-gss-preauth (pre-authentication mechanism for Kerberos based on the GSS-API). The abstract of the document is the following:

   This document describes a pre-authentication mechanism for Kerberos
   based on the Generic Security Service Application Program Interface
   (GSS-API), which allows a Key Distribution Center (KDC) to
   authenticate clients by using any GSS mechanism.

Changes include:
  • Added motivation section indicating why this is required.
  • Added summary of the dicussion about statefull vs. stateless of the KDC when using the GSS-API.

You can access the document following this link:
http://www.ietf.org/id/draft-perez-krb-wg-gss-preauth-01.txt

Best regards,
Alejandro

--------------000606070000080507080005-- --------------040203070409080707090405 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Parte del mensaje adjunto" _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg@lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg --------------040203070409080707090405-- From Josh.Howlett@ja.net Wed Jan 4 01:42:56 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C310A21F8682 for ; Wed, 4 Jan 2012 01:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw71wqlw6V64 for ; Wed, 4 Jan 2012 01:42:56 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1FADA21F85D2 for ; Wed, 4 Jan 2012 01:42:56 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B3AB61A9B7C3_F041F1EB; Wed, 4 Jan 2012 09:42:54 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 8D86E1A9B7CD_F041F1EF; Wed, 4 Jan 2012 09:42:54 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Wed, 4 Jan 2012 09:42:54 +0000 From: Josh Howlett To: Alejandro Perez Mendez , "abfab@ietf.org" Thread-Topic: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted Thread-Index: AQHMysFgxIovpkEhe0uYLej5ge1KI5X79PEA Date: Wed, 4 Jan 2012 09:42:53 +0000 Message-ID: In-Reply-To: <4F041888.8030105@um.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C488A5F8D8D8B4DB863DDE03DCC42E3@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2012 09:42:56 -0000 Hi Alex, Thanks for the update. > Changes include: >=20=20=20=20 >=20=20=20=20=20=20 >* Added motivation section indicating why this is required. This is a definitely a good addition; however, I don't believe that it is complete. Ideally I think it needs to consider the questions that I raised previously in the context of the previous discussion that Sam initiated about generic gss pre-auth versus gss-eap pre-auth: > What are the practical benefits of a generic gss pre-auth mechanism when > Kerberos pre-auth itself provides an extensible framework? I can see that > there is value in the re-using deployed gss mechanisms if this avoids > having to create functionally-equivalent but redundant pre-auth >mechanisms > in the case where an equivalent gss mechanism already exists, but are > there really so many of these that this is a compelling argument? It > sounds as though there is potentially a trade-off that we could make > between complexity and generality. FWIW I haven't developed an opinion on these yet, but I would be interested to hear if you have any... Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From alex@um.es Wed Jan 4 01:43:30 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823B21F86F9 for ; Wed, 4 Jan 2012 01:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX0Igx8rvqTs for ; Wed, 4 Jan 2012 01:43:30 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id D72C921F8682 for ; Wed, 4 Jan 2012 01:43:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 8E0C35D458 for ; Wed, 4 Jan 2012 10:43:28 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Hk3K0ivHwHFh for ; Wed, 4 Jan 2012 10:43:28 +0100 (CET) Received: from [192.168.1.130] (165.247.221.87.dynamic.jazztel.es [87.221.247.165]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id E16895D456 for ; Wed, 4 Jan 2012 10:43:26 +0100 (CET) Message-ID: <4F041F3D.4030505@um.es> Date: Wed, 04 Jan 2012 10:43:25 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "abfab@ietf.org" References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> In-Reply-To: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020902050405090409000109" Subject: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2012 09:43:30 -0000 This is a multi-part message in MIME format. --------------020902050405090409000109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. We have submitted this draft to RADEXT WG. It aims to overcome the 4K limit per packet in RADIUS. It enables the fragmentation of any RADIUS attribute across several RADIUS packets. http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-00.txt Regards, Alejandro -------- Mensaje original -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Fecha: Wed, 04 Jan 2012 01:21:53 -0800 De: internet-drafts@ietf.org Para: alex@um.es A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 00 Title: Fragmentation support across RADIUS packets Creation date: 2012-01-04 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes a mechanism providing fragmentation support of RADIUS attributes across several RADIUS packets. This is intended to support attributes that exceed the 4 KB limit per RADIUS packet. The IETF Secretariat --------------020902050405090409000109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI.

We have submitted this draft to RADEXT WG. It aims to overcome the 4K limit per packet in RADIUS. It enables the fragmentation of any RADIUS attribute across several RADIUS packets.

http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-00.txt

Regards,
Alejandro

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt
Fecha: Wed, 04 Jan 2012 01:21:53 -0800
De: internet-drafts@ietf.org
Para: alex@um.es 


A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS attributes across several RADIUS packets.  This is intended
   to support attributes that exceed the 4 KB limit per RADIUS packet.

                                                                                  


The IETF Secretariat
--------------020902050405090409000109-- From alex@um.es Wed Jan 4 01:56:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65A21F8719 for ; Wed, 4 Jan 2012 01:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgQW-JlHucD9 for ; Wed, 4 Jan 2012 01:56:46 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7047321F8715 for ; Wed, 4 Jan 2012 01:56:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id A4E7A535B9; Wed, 4 Jan 2012 10:56:44 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id e4HlIpDTfKwh; Wed, 4 Jan 2012 10:56:44 +0100 (CET) Received: from [192.168.1.130] (165.247.221.87.dynamic.jazztel.es [87.221.247.165]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id D888853600; Wed, 4 Jan 2012 10:56:41 +0100 (CET) Message-ID: <4F042256.5080805@um.es> Date: Wed, 04 Jan 2012 10:56:38 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2012 09:56:47 -0000 Hi Josh, > Hi Alex, > > Thanks for the update. > > >> Changes include: >> >> >> * Added motivation section indicating why this is required. > This is a definitely a good addition; however, I don't believe that it is > complete. Ideally I think it needs to consider the questions that I raised > previously in the context of the previous discussion that Sam initiated > about generic gss pre-auth versus gss-eap pre-auth: > >> What are the practical benefits of a generic gss pre-auth mechanism when >> Kerberos pre-auth itself provides an extensible framework? I can see that >> there is value in the re-using deployed gss mechanisms if this avoids >> having to create functionally-equivalent but redundant pre-auth >> mechanisms >> in the case where an equivalent gss mechanism already exists, but are >> there really so many of these that this is a compelling argument? It >> sounds as though there is potentially a trade-off that we could make >> between complexity and generality. > > FWIW I haven't developed an opinion on these yet, but I would be > interested to hear if you have any... since the principal final purpose of this draft (in conjunction with the other one submitted to the ABFAB WG) is to enable the KDC to authenticate users based on the GSS-EAP mechanism, I don't see any advantage in transporting GSS tokens on top of FAST. It adds an additional an unnecessary layer, since nor GSS-API nor EAP assume any kind of secure transport. Said that, the draft specifies that you can use it on top of FAST if that is more convenient for your requirements, nothing precludes it. Though, of course, that is not mandatory. Besides, as I see it, this draft does follow the indications of the pre-authentication framework to define new pre-authentication mechanism. What it does not do is to define a FAST factor, but IMO those are different things. Hope this clarifies something. Best regards, Alejandro > > Josh. > > > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > From aland@deployingradius.com Wed Jan 4 06:19:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92421F876F; Wed, 4 Jan 2012 06:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.874 X-Spam-Level: X-Spam-Status: No, score=-101.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3EnszwjXE0T; Wed, 4 Jan 2012 06:19:45 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 7422821F875D; Wed, 4 Jan 2012 06:19:45 -0800 (PST) Message-ID: <4F045FE2.8070804@deployingradius.com> Date: Wed, 04 Jan 2012 09:19:14 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> In-Reply-To: <4F041D09.2060905@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, "abfab@ietf.org" Subject: Re: [abfab] [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2012 14:19:46 -0000 Alejandro Perez Mendez wrote: > This motivation of this document comes from the necessity in the ABFAB > WG of sending SAML Messages transported into RADIUS attributes. These > SAML Messages can potentially be bigger than 4 KB, thus a mechanism to > fragment them is required. My $0.02 after a quick read, this stood out: --- Chunked-Attribute attribute. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBA) | Length | Ext-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total-Attribute-Length | Start-Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Ext-Type Type of the attribute that is being chunked. This field is encoded as an Ext-Type value, as described in [I-D.ietf-radext-extended-attributes], to be compatible with extended attributes. ---- That won't work. The type/ext-type is used to uniquely identify an attribute. As the RFC6158 says, the interpretation of the attribute is based solely on the type code(s). What you're doing above is changing the meaning of the attribute based on its length. That's difficult, if not impossible, to do correctly. Attributes can also occur multiple times in a packet, with different values. e.g. Proxy-State. The chunked encoding method should support that, too. Perhaps another solution would be to leverage the "flags" field. If a particular bit is 1, then the attribute contains 4 32-bit fields immediately after the "flags" field: identifier for this attribute. Allows multi-values total length of the fragments with "identifier" start as per above end as per above If this document is published soon after the extensions document, then it has a better likelihood of being implemented. Alan DeKok. From diego@tid.es Wed Jan 4 10:21:09 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D777411E807A; Wed, 4 Jan 2012 10:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZTqNF0XRIij; Wed, 4 Jan 2012 10:21:08 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5362221F86AE; Wed, 4 Jan 2012 10:21:07 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXA000LVDN5RJ@tid.hi.inet>; Wed, 04 Jan 2012 19:21:05 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 69.D1.02643.198940F4; Wed, 04 Jan 2012 19:21:05 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXA000LQDN4RJ@tid.hi.inet>; Wed, 04 Jan 2012 19:21:05 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Wed, 04 Jan 2012 19:21:04 +0100 Date: Wed, 04 Jan 2012 19:21:02 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F045FE2.8070804@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczLDZ68FEBzPaJTQLyqwDFJVlqgrg== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-07-4f049891004f X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsXCFe9nqDtxBou/wYFjwhYfr79htGh5NZPN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZt75fZSvYIlXRdeQZYwPjHckuRk4OCQETiT8/H7NA 2GISF+6tZ+ti5OIQEtjGKHH/8Qso5ymjxOKLH1ghnEZGiQ0z7jB1MXJwsAioSiw/GwHSzSag LtFy9BvYJGGBZIm7/7exgdicAsYSPz89YAWxRQS0JBasX8QC0sosUCgx9YIOSJhXwFLi+JoV bBC2oMSPyfegStQlpkzJBQkzC4hLNLfeZIGwFSWmLWpgBLEZgW7+fmoNE8T0FIlNd+axQdh6 ErO+LoOqEZW4076eEeJHAYkle84zQ9iiEi8f/4P6qolRYvnOvawTGMVnITljFsIZs5CcMQvJ GQsYWVYxihUnFWWmZ5TkJmbmpBsY6WVk6mXmpZZsYoREU+YOxuU7VQ4xCnAwKvHwerxj9Bdi TSwrrsw9xCjJwaQkysvTx+IvxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3VTtQjjclsbIqtSgf JiXDwaEkwftkOlBKsCg1PbUiLTMHmDJg0kwcnCDtPEDtD0FqeIsLEnOLM9Mh8qcYJaXEeTeD JARAEhmleXC9rxjFgY4U5l0CkuUBJje4rldAA5mABkaJgA0sSURISTUwLjsl1JC0+Nop246H es+mPs8I2ja55kr/I+avPhxsH25svu7hcFKJO0g38JftusnfTON79NiZ/xnsKNzJ2XrzfPlk tYnM91d0bPjkcPT74kbxY3rrZ6zbfDPevIVT+LaHpdZ3V5FPj3wDPsjPTvXjkVJ4VBYTMIE/ rbhs8f+84yYuJV8M5x/XUGIpzkg01GIuKk4EAAhEcjQrAwAA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2012 18:21:10 -0000 SGkgQWxhbiwNCg0KT24gNCBKYW4gMjAxMiwgYXQgMTU6MTkgLCBBbGFuIERlS29rIHdyb3RlOg0K PiAgVGhhdCB3b24ndCB3b3JrLiAgVGhlIHR5cGUvZXh0LXR5cGUgaXMgdXNlZCB0byB1bmlxdWVs eSBpZGVudGlmeSBhbg0KPiBhdHRyaWJ1dGUuICBBcyB0aGUgUkZDNjE1OCBzYXlzLCB0aGUgaW50 ZXJwcmV0YXRpb24gb2YgdGhlIGF0dHJpYnV0ZSBpcw0KPiBiYXNlZCBzb2xlbHkgb24gdGhlIHR5 cGUgY29kZShzKS4gIFdoYXQgeW91J3JlIGRvaW5nIGFib3ZlIGlzIGNoYW5naW5nDQo+IHRoZSBt ZWFuaW5nIG9mIHRoZSBhdHRyaWJ1dGUgYmFzZWQgb24gaXRzIGxlbmd0aC4NCj4NCj4gIFRoYXQn cyBkaWZmaWN1bHQsIGlmIG5vdCBpbXBvc3NpYmxlLCB0byBkbyBjb3JyZWN0bHkuDQoNCkknbSBh ZnJhaWQgdGhlcmUgaXMgYSBtaXN1bmRlcnN0YW5kaW5nLiBUaGUgQ2h1bmtlZC1BdHJyaWJ1dGUg aXMgYW4gYXR0cmlidXRlIG9uIGl0cyBvd24gdGhhdCBjb250YWlucyBvbmx5IGEgcmVmZXJlbmNl IHRvIHRoZSBhdHRyaWJ1dGUgYmVpbmcgY2h1bmtlZC4gSXQgaGFzIHRvIGFwcGVhciBpbiBhbGwg dGhlIHBhY2tldHMgY29udGFpbmluZyBjaHVua3Mgb2YgYXR0cmlidXRlcywgYXMgbWFueSBhcyBh dHRyaWJ1dGVzIHRoZXkgcmVmZXIgdG8uIENodW5rcyBhcmUgaW50ZW5kZWQgdG8gYmUgZW5jb2Rl ZCBmb2xsb3dpbmcgdGhlIHVzdWFsIGVuY29kaW5nIG1ldGhvZHMuDQoNCkl0IGlzIHRydWUgdGhh dCB0aGUgbGF5b3V0IGFuZCB0aGUgZmllbGQgbmFtZXMgdXNlZCBpbiBpdCBhcmUgbWlzbGVhZGlu ZyAoaW5zdGVhZCBvZiAiRXh0LVR5cGUiIHdlIHNob3VsZCBjYWxsIGl0ICJUeXBlLUlEIiBvciAi QXR0cmlidXRlLUlEIiBvciBzb21ldGhpbmcgc2ltaWxhciksIGFuZCB5b3UgYXJlIHJpZ2h0IGlu IHRoYXQgdGhlIHdheSBvZiBzcGVjaWZ5aW5nIHRoaXMgaWRlbnRpZmllciBzaG91bGQgYmUgYmV0 dGVyIGFsaWduZWQgd2l0aCB0aGUgd2F5IG9mIGNvZGluZyB0eXBlcyBhbmQgZXh0ZW5kZWQgdHlw ZXMuDQoNCj4gIEF0dHJpYnV0ZXMgY2FuIGFsc28gb2NjdXIgbXVsdGlwbGUgdGltZXMgaW4gYSBw YWNrZXQsIHdpdGggZGlmZmVyZW50DQo+IHZhbHVlcy4gIGUuZy4gUHJveHktU3RhdGUuDQoNCllv dSBhcmUgcmlnaHQuIFRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZC4gQSBzaW1wbGUgcHJvcG9zYWwg Y291bGQgZm9sbG93IHRoZXNlIHJ1bGVzOg0KDQoqIENodW5rZWQtQXR0cmlidXRlIG11c3QgYXBw ZWFyIGJlZm9yZSB0aGUgYXR0cmlidXRlIGl0IHJlZmVycyB0byBpbiB0aGUgcGFja2V0DQoNCiog SWYgYW4gYXR0cmlidXRlIG9jY3VycyBtdWx0aXBsZSB0aW1lcyBpbiBhIHJlcXVlc3QvcmVzcG9u c2UgKHdlIGNhbm5vdCBzcGVhayBoZXJlIG9mICJhIHBhY2tldCIpIGNodW5rcyBmb3Igb25seSBv bmUgb2YgdGhlIG9jY3VycmVuY2VzLCBhc3NvY2lhdGVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIENo dW5rZWQtQXR0cmlidXRlLCBhcmUgYWxsb3dlZCBpbiBhIGdpdmVuIHBhY2tldA0KDQoqIE5vbi1m cmFnbWVudGVkIHZhbHVlcyBmb3IgdGhpcyBhdHRyaWJ1dGUgY2FuIGFwcGVhciBpbiBhbnkgcGFj a2V0LCBidXQgYWx3YXlzIGJlZm9yZSB0aGUgQ2h1bmtlZC1BdHRyaWJ1dGUgdGhhdCByZWZlcnMg dG8gaXQNCg0KKiBBcyBtYW55IENodW5rZWQtQXR0cmlidXRlIChhbmQgcmVmZXJyZWQgYXR0cmli dXRlcykgbWF5IGFwcGVhciBpbiBhIGdpdmVuIHBhY2tldCBhcyBuZWNlc3NhcnkuDQoNCj4gIElm IHRoaXMgZG9jdW1lbnQgaXMgcHVibGlzaGVkIHNvb24gYWZ0ZXIgdGhlIGV4dGVuc2lvbnMgZG9j dW1lbnQsIHRoZW4NCj4gaXQgaGFzIGEgYmV0dGVyIGxpa2VsaWhvb2Qgb2YgYmVpbmcgaW1wbGVt ZW50ZWQuDQoNCkdvb2QgcG9pbnQhDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZh bGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25p Y2EgSStEDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICAgKzM0IDkxMyAxMjkgMDQx DQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEg c3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52 w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1 YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9y IGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFz aXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFT L2Rpc2NsYWltZXIuYXNweA0K From alex@um.es Thu Jan 5 00:29:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1D21F8757; Thu, 5 Jan 2012 00:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZG2PX1jc7nS; Thu, 5 Jan 2012 00:29:01 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4421F86B4; Thu, 5 Jan 2012 00:29:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id A37565D44E; Thu, 5 Jan 2012 09:28:59 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U6o9xokgmptp; Thu, 5 Jan 2012 09:28:59 +0100 (CET) Received: from [192.168.1.133] (178.246.221.87.dynamic.jazztel.es [87.221.246.178]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 3C99C5D446; Thu, 5 Jan 2012 09:28:54 +0100 (CET) Message-ID: <4F055F44.2010606@um.es> Date: Thu, 05 Jan 2012 09:28:52 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jan 2012 08:29:02 -0000 Hi Alan, Diego, > Hi Alan, > > On 4 Jan 2012, at 15:19 , Alan DeKok wrote: >> That won't work. The type/ext-type is used to uniquely identify an >> attribute. As the RFC6158 says, the interpretation of the attribute is >> based solely on the type code(s). What you're doing above is changing >> the meaning of the attribute based on its length. >> >> That's difficult, if not impossible, to do correctly. > I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containing chunks of attributes, as many as attributes they refer to. Chunks are intended to be encoded following the usual encoding methods. > > It is true that the layout and the field names used in it are misleading (instead of "Ext-Type" we should call it "Type-ID" or "Attribute-ID" or something similar), and you are right in that the way of specifying this identifier should be better aligned with the way of coding types and extended types. You are right. Maybe the name was not the best. We gave it 2 bytes in order to be able to refer not only to "standard" RADIUS attributes, but also to extended attributes. But after your explanation, I think that we could either include both references (Type/Ext-Type, 3 bytes in total) or just refer only to the Type (1 byte). From the point of view of fragmentation, it could be enough to know that the attribute (e.g. Vendor-Specific) is fragmented, no matter the kind of Vendor Specific attribute we are dealing with. > >> Attributes can also occur multiple times in a packet, with different >> values. e.g. Proxy-State. > You are right. That should be addressed. A simple proposal could follow these rules: > > * Chunked-Attribute must appear before the attribute it refers to in the packet Right. > > * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are allowed in a given packet I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED, X, X) you can easily assumed that the first [X,X,X] is one attribute (X1) and the second [X,X] a different one (X2), as the five Xs do not appear in sequence. Note that this situation can only occur in the packet where the last CHUNK of the first attribute coincide with the first CHUNK of the second attribute. In the example, X1 and X2 are different attributes of type X. PACKET1: CHUNCKED, X1, X1, X1, X1, X1, X1, X1, X1, X1 PACKET2: CHUNCKED, X1, X1, CHUNCKED, X2, X2, X2, X2 PACKET3: CHUNCKED, X2, X2 > > * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it I kinda don't like this one. We could force the inclusion of the CHUNCKED attribute in these situations, even when no needed. Example: CHUNCKED(type=X, total_length=200, start_pos=0, end_pos=199). As explained above, this would insert an attribute (the CHUNCKED attribute) between both occurrences of attribute X, thus breaking the misleading sequence. > > * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary. Right, as depicted in the examples above. Best regards, Alejandro > >> If this document is published soon after the extensions document, then >> it has a better likelihood of being implemented. > Good point! > > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx From aland@deployingradius.com Thu Jan 5 08:06:10 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6921F87B8; Thu, 5 Jan 2012 08:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+G2dF9mKRDc; Thu, 5 Jan 2012 08:06:10 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8B121F8688; Thu, 5 Jan 2012 08:06:10 -0800 (PST) Message-ID: <4F05CA5A.2030602@deployingradius.com> Date: Thu, 05 Jan 2012 17:05:46 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jan 2012 16:06:11 -0000 DIEGO LOPEZ GARCIA wrote: > I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containing chunks of attributes, as many as attributes they refer to. Chunks are intended to be encoded following the usual encoding methods. IMHO, that kind of solution should be avoided. > * Chunked-Attribute must appear before the attribute it refers to in the packet RADIUS doesn't impose ordering on attributes of different type. That's a strong reason to integrate chunking inside of the attribute format. > * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are allowed in a given packet Why? RADIUS allows for multiple attributes of the same type, with different value. > * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it See comment about attribute ordering. > * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary. I think this document is intended to solve one *very* limited use-case. It doesn't address any more general case. It relies on fixed attribute ordering, which is explicitly not required. I gave comments on your approach. Do you have any comments on my proposed alternative? It would seem to (a) solve the same problem, and (b) have none of the limitations. Alan DeKok. From aland@deployingradius.com Thu Jan 5 08:10:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1121F878E; Thu, 5 Jan 2012 08:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxc9Ckk6GsCk; Thu, 5 Jan 2012 08:10:30 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 091DF21F8719; Thu, 5 Jan 2012 08:10:30 -0800 (PST) Message-ID: <4F05CB4F.9010104@deployingradius.com> Date: Thu, 05 Jan 2012 17:09:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F055F44.2010606@um.es> In-Reply-To: <4F055F44.2010606@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jan 2012 16:10:31 -0000 Alejandro Perez Mendez wrote: > But after your explanation, I think that we > could either include both references (Type/Ext-Type, 3 bytes in total) > or just refer only to the Type (1 byte). From the point of view of > fragmentation, it could be enough to know that the attribute (e.g. > Vendor-Specific) is fragmented, no matter the kind of Vendor Specific > attribute we are dealing with. I don't understand how that would work. My previous proposal to use a flag field could potentially work for the new extended VSA format, too. > I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED, > X, X) you can easily assumed that the first [X,X,X] is one attribute > (X1) and the second [X,X] a different one (X2), as the five Xs do not > appear in sequence. Which relies on attribute ordering. That's a fatal flaw for any proposal. Alan DeKok. From diego@tid.es Mon Jan 9 00:55:09 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6021F8690; Mon, 9 Jan 2012 00:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-2.135, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdfasL4t6qib; Mon, 9 Jan 2012 00:55:08 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4FCF21F85E9; Mon, 9 Jan 2012 00:55:07 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXI00MPIWRT35@tid.hi.inet>; Mon, 09 Jan 2012 09:55:05 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 3A.42.02893.D4BAA0F4; Mon, 09 Jan 2012 09:54:37 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXI00MPAWRT35@tid.hi.inet>; Mon, 09 Jan 2012 09:55:05 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 09 Jan 2012 09:55:05 +0100 Date: Mon, 09 Jan 2012 09:55:05 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F05CA5A.2030602@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczOrGGit0VEh0T2SFGTBoWgI0jhFQ== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-b1-4f0aab4d537e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsXCFe/Apeu7msvf4MAbfYuP198wWrS8msnm wOSxZMlPpgDGKC6blNSczLLUIn27BK6MBx3H2AoaxCvufprP3MB4UKiLkZNDQsBE4tGTR4wQ tpjEhXvr2boYuTiEBDYwSnxqu8oI4TxllFh6ZjU7hNPIKHHl0WcWkBYWAVWJrSumsYHYbALq Ei1Hv4HFhQWSJe7+3wYW5xQwlrj48TsriC0ioCWxYP0ioBoODmaBQompF3RAwrwClhIvbx1j g7AFJX5Mvgc2hllAT+Ljn9uMELa4RHPrTai4tsSTdxfARjICXf391BomiPEpEpvuzGODsPUk tn7+yQxRIypxp3091JcCEkv2nGeGsEUlXj7+xwrx121GiTU3ZjNNYBSfheSOWUjumIXkjllI 7ljAyLKKUaw4qSgzPaMkNzEzJ93AUC8jUy8zL7VkEyMkpjJ2MC7fqXKIUYCDUYmHd0YGl78Q a2JZcWXuIUZJDiYlUV7WlUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryVfUA53pTEyqrUonyY lAwHh5IE77JVQCnBotT01Iq0zBxg4oBJM3FwgrTzALUvBqnhLS5IzC3OTIfIn2JU5bjeOPcc oxBLXn5eqpQ4bwNIkQBIUUZpHtycV4ziQAcL8yaBZHmAqQ9uwiug4UxAwx/8YQcZXpKIkJJq YBR7WLgudF1m30zlphrm/xZcB9vKF1dUqlXZvEhjNetXcrzSFRHRxdy0ZLLX3L2maz53HDxx 6O5j7al7mzjiz7nJHfbcdKI0R23tw5nhewMWeRrG7JymvsZwfY9a/1yuORs6Y94FPfROjGY6 +GXXVtvcuZWhe33exHeVGM2fHTqXfcLJ+NVxD5VYijMSDbWYi4oTARB27cY6AwAA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2012 08:55:09 -0000 On 5 Jan 2012, at 17:05 , Alan DeKok wrote: >> * Chunked-Attribute must appear before the attribute it refers to in the= packet > > RADIUS doesn't impose ordering on attributes of different type. > That's a strong reason to integrate chunking inside of the attribute form= at. Ordering constraints here are applied to related attributes. I don't see wh= y this would go beyond the requirements imposed by the current document on = extended attributes, as the recent discussion on it shows. >> * If an attribute occurs multiple times in a request/response (we cannot= speak here of "a packet") chunks for only one of the occurrences, associat= ed to the corresponding Chunked-Attribute, are allowed in a given packet > > Why? RADIUS allows for multiple attributes of the same type, with > different value. > >> * Non-fragmented values for this attribute can appear in any packet, but= always before the Chunked-Attribute that refers to it > > See comment about attribute ordering. On these issues, I agree with the latest proposal from Alejandro, that rath= er simplifies ordering constraints. >> * As many Chunked-Attribute (and referred attributes) may appear in a gi= ven packet as necessary. > > I think this document is intended to solve one *very* limited > use-case. It doesn't address any more general case. The use case is that of an AuthN/AuthZ infrastructure that requires the exc= hange of data longer that the one that fits in a RADIUS packet, and intende= d to rely on a single trust infrastructure. I do think it is general enough= . > It relies on fixed attribute ordering, which is explicitly not required. It relies in the usage of an specific attribute that defines the interpreta= tion of the values of another attribute. Ordering rules probably could be r= elaxed, but at the price of more complicated processing rules. > I gave comments on your approach. Do you have any comments on my > proposed alternative? It would seem to (a) solve the same problem, and > (b) have none of the limitations. One of the main goals of the proposal was to be compatible with current mec= hanisms for attribute encoding inside the packet (EAP-style, extended attri= butes=85) and deal only with values spanning more than one packet. Using yo= ur alternative would break this compatibility. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From aland@deployingradius.com Mon Jan 9 01:59:30 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533421F843A; Mon, 9 Jan 2012 01:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq-j42xcIMA4; Mon, 9 Jan 2012 01:59:29 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BB6D121F842C; Mon, 9 Jan 2012 01:59:27 -0800 (PST) Message-ID: <4F0ABA62.3040008@deployingradius.com> Date: Mon, 09 Jan 2012 10:58:58 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2012 09:59:30 -0000 DIEGO LOPEZ GARCIA wrote: > Ordering constraints here are applied to related attributes. RADIUS doesn't work that way. There are hundreds of thousands of deployments which assume that ordering constraints do NOT apply to related attributes. Changing such a fundamental part of the protocol is impossible. > I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows. I pointed you to RFC 2865, and explained why that restriction is impossible. Please go read those messages again. > It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules. It relies on behavior which is mandated as NOT being part of RADIUS. >> I gave comments on your approach. Do you have any comments on my >> proposed alternative? It would seem to (a) solve the same problem, and >> (b) have none of the limitations. > > One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility. Nonsense. It is incompatible with existing methods like EAP-Message. Those *already* have semantics defined. Changing them by adding a "Chunked Attribute" is impossible. The extended format hasn't been deployed, so compatibility with it is impossible. My proposal was to allow *new* attributes to span multiple packets. Changing the rules on attribute ordering is impossible. Don't even try. Changing the meaning of existing attributes to allow more than 253 octets of data is impossible. Don't even try. Alan DeKok. From aland@deployingradius.com Mon Jan 9 02:03:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416E021F8421; Mon, 9 Jan 2012 02:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW2l2NeXnY4U; Mon, 9 Jan 2012 02:03:27 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A019321F869C; Mon, 9 Jan 2012 02:03:27 -0800 (PST) Message-ID: <4F0ABB54.1040401@deployingradius.com> Date: Mon, 09 Jan 2012 11:03:00 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> In-Reply-To: <4F0ABA62.3040008@deployingradius.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2012 10:03:28 -0000 Alan DeKok wrote: > There are hundreds of thousands of deployments which assume that > ordering constraints do NOT apply to related attributes. Make that "UNrelated attributes" Alan DeKok. From diego@tid.es Mon Jan 9 03:05:19 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDF621F86C4; Mon, 9 Jan 2012 03:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI9C74SaMbxg; Mon, 9 Jan 2012 03:05:15 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id D26A221F86D7; Mon, 9 Jan 2012 03:05:14 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXJ00MDI2SOZ3@tid.hi.inet>; Mon, 09 Jan 2012 12:05:12 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 09.A4.02893.8E9CA0F4; Mon, 09 Jan 2012 12:05:12 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXJ00MDD2SOZ3@tid.hi.inet>; Mon, 09 Jan 2012 12:05:12 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 09 Jan 2012 12:05:12 +0100 Date: Mon, 09 Jan 2012 12:05:11 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F0ABA62.3040008@deployingradius.com> To: Alan DeKok Message-id: <85F68FE3-7E36-4166-A3BD-01C55EE19E08@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczOvo7Vdry86SWSTkqyDztKByxwkw== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-95-4f0ac9e8fd6d X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsXCFe/ApfviJJe/wc0pRhYfr79htGh5NZPN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ289eYy/o4qw4fPU6UwPjHPYuRg4OCQETiduzq7oY OYFMMYkL99azdTFycQgJbGCU+PN7OZTzlFHi38zrjBBOI6NE88xdTCAtLAKqEmdunWABsdkE 1CVajn4Ds4UFkiX+bNrLBLKBU8BYYuV3VpCwiICWxIL1i8BKmAUKJTa9ng82hlfAUmLC33eM ELagxI/J96Bq9CQ+/rnNCGGLSzS33oSKa0s8eXcBbCYj0NXfT61hgpifIvF+RScjhK0nMWvt fhaIGlGJO+3rGSG+FJBYsuc8M4QtKvHy8T+wOUICW5gkTkwXmsAoPgvJGbOQnDELyRmzkJyx gJFlFaNYcVJRZnpGSW5iZk66gaFeRqZeZl5qySZGSDxl7GBcvlPlEKMAB6MSD++MDC5/IdbE suLK3EOMkhxMSqK80UeBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4K/uAcrwpiZVVqUX5MCkZ Dg4lCd5oYOwLCRalpqdWpGXmAJMGTJqJgxOknQeoPQqkhre4IDG3ODMdIn+KUVJKnDcJJCEA ksgozYPrfcUoDnSkMG8wSJYHmN7gul4BDWQCGvjgDzvIwJJEhJRUA6PjzCQvIX8bVsVZr1O5 1n1q0z5gsrU1w82qdJXv9HdnbNddNG2+rc+19amo6JuJ7neVd3dNfcCc8D57kQenx5OueIeD 05maa/KeZmTKHFGcLil/gjPjVvy5sh8y/9P5WLPWHGVV+roxafVRzUJeiy3Lfb3ldz8+ME3i n/C5PV9bet4v5SvYskiJpTgj0VCLuag4EQAmRrbPLAMAAA== References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2012 11:05:19 -0000 On 9 Jan 2012, at 10:58 , Alan DeKok wrote: > Changing the rules on attribute ordering is impossible. Don't even try= . Nodoby is trying to do so. We've probably not explained well the rules for = CHUNKED and the related attribute. Let us get back to it with a (hopefully)= clearer proposal. > Changing the meaning of existing attributes to allow more than 253 > octets of data is impossible. Don't even try. Nobody is trying to do so either, but to achieve the goal of allowing attri= butes to span several packets in the simplest and cleanest way possible. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From alex@um.es Mon Jan 9 03:21:10 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5621F8471; Mon, 9 Jan 2012 03:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlqiGZhjDVPl; Mon, 9 Jan 2012 03:21:09 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEA521F846E; Mon, 9 Jan 2012 03:21:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 794254BA6A; Mon, 9 Jan 2012 12:21:06 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Bhz6-VAQffe6; Mon, 9 Jan 2012 12:21:06 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id 068C94BD17; Mon, 9 Jan 2012 12:20:58 +0100 (CET) Message-ID: <4F0ACD9A.4000809@um.es> Date: Mon, 09 Jan 2012 12:20:58 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> In-Reply-To: <4F0ABA62.3040008@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2012 11:21:10 -0000 Hi Alan, thanks for the clarifications and hints. We will think about them and their implications, and try to modify the proposal to make it address all the requirements. Regards, Alejandro El 09/01/12 10:58, Alan DeKok escribió: > DIEGO LOPEZ GARCIA wrote: >> Ordering constraints here are applied to related attributes. > RADIUS doesn't work that way. > > There are hundreds of thousands of deployments which assume that > ordering constraints do NOT apply to related attributes. Changing such > a fundamental part of the protocol is impossible. > >> I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows. > I pointed you to RFC 2865, and explained why that restriction is > impossible. Please go read those messages again. > >> It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules. > It relies on behavior which is mandated as NOT being part of RADIUS. > >>> I gave comments on your approach. Do you have any comments on my >>> proposed alternative? It would seem to (a) solve the same problem, and >>> (b) have none of the limitations. >> One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility. > Nonsense. > > It is incompatible with existing methods like EAP-Message. Those > *already* have semantics defined. Changing them by adding a "Chunked > Attribute" is impossible. The extended format hasn't been deployed, so > compatibility with it is impossible. > > My proposal was to allow *new* attributes to span multiple packets. > > Changing the rules on attribute ordering is impossible. Don't even try. > > Changing the meaning of existing attributes to allow more than 253 > octets of data is impossible. Don't even try. > > Alan DeKok. From alex@um.es Mon Jan 16 05:43:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007AD21F85DF; Mon, 16 Jan 2012 05:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoqikBLDV8ZL; Mon, 16 Jan 2012 05:43:44 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1A20D21F8516; Mon, 16 Jan 2012 05:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 2C0304BB19; Mon, 16 Jan 2012 14:43:39 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h6gzv1b-c9DN; Mon, 16 Jan 2012 14:43:34 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id ECFCE4BCE7; Mon, 16 Jan 2012 14:43:28 +0100 (CET) Message-ID: <4F142980.6040404@um.es> Date: Mon, 16 Jan 2012 14:43:28 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> In-Reply-To: <4F0ACD9A.4000809@um.es> Content-Type: multipart/alternative; boundary="------------060904040002090608040905" Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 13:43:46 -0000 This is a multi-part message in MIME format. --------------060904040002090608040905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Alan, all, we have been thinking on this topic and we realized that a different approach could be more convenient to handle inter-packet fragmentation than our first proposal. Taking draft-ietf-radext-radius-extensions as a base, we can assume that intra-packet fragmentation is already handled via the M flag. We can also assume that order between fragments is preserved when following draft-ietf-radext-radius-extensions. This may not be true now with the current spec (as Peter pointed out), but we can assume this will be solved somehow in the future (e.g. including offset field). We propose the following: 1) Extended flag attributes are used to fragment big RADIUS attributes, as specified in draft-ietf-radext-radius-extensions. 2) If a fragmented attribute cannot be completely included into the remaining space of a 4KB RADIUS packet, it is truncated, that is, only the fragments that fit into the free space of the packet to be sent are included. It is also included a new RADIUS attribute, called "More-Data-Pending". The presence of this attribute indicates to the receiver that the RADIUS packet is not complete, and more data MUST be received from the sender before processing any of the received attributes. Note that it is possible (and very likely), that the last fragment of a truncated attribute in a RADIUS packet has the M flag set. This case would be against what it is stated in draft-ietf-radext-radius-extensions. Nevertheless, we think this restriction can be easily relaxed when using the more-data-pending attribute. If it is present, it is allowed that the last fragment have the bit M set, which means the attribute is truncated. A good side effect of this is that if a server does not understand more-data-pending and its semantics, a truncated attribute will be shown as an invalid attribute, and not taking the truncated portion as the whole. The rest of the attribute fragments will be sent in successive packets, following the same procedure, using as many RADIUS packets as needed to transmit the required information. Let me illustrate this with an example, where a RADIUS client sends a packet with a size > 4 KB (to make it simpler, we assume each RADIUS packet can include 8 RADIUS attributes/fragments, instead of using bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate successive fragments of the attribute Data. The RADIUS client wants to send the following RADIUS packet: Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], Other2[M], Other3 As only 8 attributes can be included in the packet, the RADIUS client truncates "Data" to fit into the packet, and includes the More-Data-Pending attribute: Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], More-Data-Pending When the server receives the RADIUS packet containing the More-Data-Pending attribute, the processing of the packet is left until all the pending data is received. The pending data is requested by means of an Access-Challenge packet, using the State attribute to tie together this response with the subsequent request from the client. Access-Challenge1 = State1 The client continues sending the data until another RADIUS packet is completed, including again the attribute More-Data-Pending Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], More-Data-Pending The server stores the attributes into the state associated to State1 and replies: Access-Challenge1 = State2 Finally, the client sends the last fragments of the original packet: Access-Request3 = State2, Other2[M], Other3 The server now can process the totality of the received attributes as if they all had been received into a single RADIUS packet of more than 4 KB The case where the server sends a fragmented packet to the client is very similar and makes no sense to expli Best regards, Alejandro El 09/01/12 12:20, Alejandro Perez Mendez escribió: > Hi Alan, > > thanks for the clarifications and hints. We will think about them and > their implications, and try to modify the proposal to make it address > all the requirements. > > Regards, > Alejandro > > El 09/01/12 10:58, Alan DeKok escribió: >> DIEGO LOPEZ GARCIA wrote: >>> Ordering constraints here are applied to related attributes. >> RADIUS doesn't work that way. >> >> There are hundreds of thousands of deployments which assume that >> ordering constraints do NOT apply to related attributes. Changing such >> a fundamental part of the protocol is impossible. >> >>> I don't see why this would go beyond the requirements imposed by the >>> current document on extended attributes, as the recent discussion on >>> it shows. >> I pointed you to RFC 2865, and explained why that restriction is >> impossible. Please go read those messages again. >> >>> It relies in the usage of an specific attribute that defines the >>> interpretation of the values of another attribute. Ordering rules >>> probably could be relaxed, but at the price of more complicated >>> processing rules. >> It relies on behavior which is mandated as NOT being part of RADIUS. >> >>>> I gave comments on your approach. Do you have any comments on my >>>> proposed alternative? It would seem to (a) solve the same problem, >>>> and >>>> (b) have none of the limitations. >>> One of the main goals of the proposal was to be compatible with >>> current mechanisms for attribute encoding inside the packet >>> (EAP-style, extended attributes…) and deal only with values spanning >>> more than one packet. Using your alternative would break this >>> compatibility. >> Nonsense. >> >> It is incompatible with existing methods like EAP-Message. Those >> *already* have semantics defined. Changing them by adding a "Chunked >> Attribute" is impossible. The extended format hasn't been deployed, so >> compatibility with it is impossible. >> >> My proposal was to allow *new* attributes to span multiple packets. >> >> Changing the rules on attribute ordering is impossible. Don't >> even try. >> >> Changing the meaning of existing attributes to allow more than 253 >> octets of data is impossible. Don't even try. >> >> Alan DeKok. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------060904040002090608040905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Alan, all,

we have been thinking on this topic and we realized that a different approach could be more convenient to handle inter-packet fragmentation than our first proposal.

Taking draft-ietf-radext-radius-extensions as a base, we can assume that intra-packet fragmentation is already handled via the M flag. We can also assume that order between fragments is preserved when following draft-ietf-radext-radius-extensions. This may not be true now with the current spec (as Peter pointed out), but we can assume this will be solved somehow in the future (e.g. including offset field).

We propose the following:
1) Extended flag attributes are used to fragment big RADIUS attributes, as specified in draft-ietf-radext-radius-extensions.
2) If a fragmented attribute cannot be completely included into the remaining space of a 4KB RADIUS packet, it is truncated, that is, only the fragments that fit into the free space of the packet to be sent are included. It is also included a new RADIUS attribute, called "More-Data-Pending". The presence of this attribute indicates to the receiver that the RADIUS packet is not complete, and more data MUST be received from the sender before processing any of the received attributes.

Note that it is possible (and very likely), that the last fragment of a truncated attribute in a RADIUS packet has the M flag set. This case would be against what it is stated in draft-ietf-radext-radius-extensions. Nevertheless, we think this restriction can be easily relaxed when using the more-data-pending attribute. If it is present, it is allowed that the last fragment have the bit M set, which means the attribute is truncated. A good side effect of this is that if a  server does not understand more-data-pending and its semantics, a truncated attribute will be shown as an invalid attribute, and not taking the truncated portion as the whole.

The rest of the attribute fragments will be sent in successive packets, following the same procedure, using as many RADIUS packets as needed to transmit the required information.

Let me illustrate this with an example, where a RADIUS client sends a packet with a size > 4 KB (to make it simpler, we assume each RADIUS packet can include 8 RADIUS attributes/fragments, instead of using bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate successive fragments of the attribute Data.

The RADIUS client wants to send the following RADIUS packet:

Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], Other2[M], Other3


As only 8 attributes can be included in the packet, the RADIUS client truncates "Data" to fit into the packet, and includes the More-Data-Pending attribute:

Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], More-Data-Pending

When the server receives the RADIUS packet containing the More-Data-Pending attribute, the processing of the packet is left until all the pending data is received. The pending data is requested by means of an Access-Challenge packet, using the State attribute to tie together this response with the subsequent request from the client.

Access-Challenge1 = State1

The client continues sending the data until another RADIUS packet is completed, including again the attribute More-Data-Pending

Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], More-Data-Pending


The server stores the attributes into the state associated to State1 and replies:

Access-Challenge1 = State2

Finally, the client sends the last fragments of the original packet:

Access-Request3 = State2, Other2[M], Other3

The server now can process the totality of the received attributes as if they all had been received into a single RADIUS packet of more than 4 KB

The case where the server sends a fragmented packet to the client is very similar and makes no sense to expli

Best regards,
Alejandro

El 09/01/12 12:20, Alejandro Perez Mendez escribió:
Hi Alan,

thanks for the clarifications and hints. We will think about them and their implications, and try to modify the proposal to make it address all the requirements.

Regards,
Alejandro

El 09/01/12 10:58, Alan DeKok escribió:
DIEGO LOPEZ GARCIA wrote:
Ordering constraints here are applied to related attributes.
   RADIUS doesn't work that way.

   There are hundreds of thousands of deployments which assume that
ordering constraints do NOT apply to related attributes.  Changing such
a fundamental part of the protocol is impossible.

I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows.
   I pointed you to RFC 2865, and explained why that restriction is
impossible.  Please go read those messages again.

It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules.
   It relies on behavior which is mandated as NOT being part of RADIUS.

I gave comments on your approach.  Do you have any comments on my
proposed alternative?  It would seem to (a) solve the same problem, and
(b) have none of the limitations.
One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility.
   Nonsense.

   It is incompatible with existing methods like EAP-Message.  Those
*already* have semantics defined.  Changing them by adding a "Chunked
Attribute" is impossible.  The extended format hasn't been deployed, so
compatibility with it is impossible.

   My proposal was to allow *new* attributes to span multiple packets.

   Changing the rules on attribute ordering is impossible.  Don't even try.

   Changing the meaning of existing attributes to allow more than 253
octets of data is impossible.  Don't even try.

   Alan DeKok.
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
--------------060904040002090608040905-- From aland@deployingradius.com Mon Jan 16 06:24:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5182021F8582; Mon, 16 Jan 2012 06:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh5fvUvCIwn1; Mon, 16 Jan 2012 06:24:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1B321F844F; Mon, 16 Jan 2012 06:24:54 -0800 (PST) Message-ID: <4F143317.3010300@deployingradius.com> Date: Mon, 16 Jan 2012 15:24:23 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> In-Reply-To: <4F142980.6040404@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 14:24:55 -0000 Alejandro Perez Mendez wrote: > We propose the following: > 1) Extended flag attributes are used to fragment big RADIUS attributes, > as specified in draft-ietf-radext-radius-extensions. That should be possible. > 2) If a fragmented attribute cannot be completely included into the > remaining space of a 4KB RADIUS packet, it is truncated, that is, only > the fragments that fit into the free space of the packet to be sent are > included. It is also included a new RADIUS attribute, called > "More-Data-Pending". The presence of this attribute indicates to the > receiver that the RADIUS packet is not complete, and more data MUST be > received from the sender before processing any of the received attributes. I've had similar discussions with people off-list. > Note that it is possible (and very likely), that the last fragment of a > truncated attribute in a RADIUS packet has the M flag set. This case > would be against what it is stated in > draft-ietf-radext-radius-extensions. Nevertheless, we think this > restriction can be easily relaxed when using the more-data-pending > attribute. If it is present, it is allowed that the last fragment have > the bit M set, which means the attribute is truncated. A good side > effect of this is that if a server does not understand > more-data-pending and its semantics, a truncated attribute will be shown > as an invalid attribute, and not taking the truncated portion as the whole. I'm wary of that, but it's a good start. There may be additional minor fixes which could make the fragmentation explicit rather than implicit. I think this proposal would require a new document at minimum. The document would discuss how to implement the above proposal. That means that others could use this specification, even if they don't need attributes longer than 4K. A separate document could document the >4K attributes. I'll see if I can write a short proposal to the radext list. If it's acceptable to the WG, I can put a draft together. Alan DeKok. From alex@um.es Mon Jan 16 07:30:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6421F861E; Mon, 16 Jan 2012 07:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cZIPKHzUBPZ; Mon, 16 Jan 2012 07:30:31 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8C21F8625; Mon, 16 Jan 2012 07:30:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 34D87535F5; Mon, 16 Jan 2012 16:30:29 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hA61AYNRJv2D; Mon, 16 Jan 2012 16:30:28 +0100 (CET) Received: from [192.168.1.131] (49.247.221.87.dynamic.jazztel.es [87.221.247.49]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id 0E595535F7; Mon, 16 Jan 2012 16:30:22 +0100 (CET) Message-ID: <4F144287.40505@um.es> Date: Mon, 16 Jan 2012 16:30:15 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> In-Reply-To: <4F143317.3010300@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 15:30:31 -0000 Hi Alan, > Alejandro Perez Mendez wrote: >> We propose the following: >> 1) Extended flag attributes are used to fragment big RADIUS attributes, >> as specified in draft-ietf-radext-radius-extensions. > That should be possible. > >> 2) If a fragmented attribute cannot be completely included into the >> remaining space of a 4KB RADIUS packet, it is truncated, that is, only >> the fragments that fit into the free space of the packet to be sent are >> included. It is also included a new RADIUS attribute, called >> "More-Data-Pending". The presence of this attribute indicates to the >> receiver that the RADIUS packet is not complete, and more data MUST be >> received from the sender before processing any of the received attributes. > I've had similar discussions with people off-list. that's good >> Note that it is possible (and very likely), that the last fragment of a >> truncated attribute in a RADIUS packet has the M flag set. This case >> would be against what it is stated in >> draft-ietf-radext-radius-extensions. Nevertheless, we think this >> restriction can be easily relaxed when using the more-data-pending >> attribute. If it is present, it is allowed that the last fragment have >> the bit M set, which means the attribute is truncated. A good side >> effect of this is that if a server does not understand >> more-data-pending and its semantics, a truncated attribute will be shown >> as an invalid attribute, and not taking the truncated portion as the whole. > I'm wary of that, but it's a good start. There may be additional > minor fixes which could make the fragmentation explicit rather than > implicit. We also thought that a new flag "T" could indicate the attribute is truncated across several packets. > I think this proposal would require a new document at minimum. The > document would discuss how to implement the above proposal. That means > that others could use this specification, even if they don't need > attributes longer than 4K. Indeed, this proposal is not only for attributes longer than 4K, but to support that an attribute is fragmented across different packets, because the total length of the packet is longer than 4K. That could happen even when the attribute is not very long, but it is placed at the end of the package. > A separate document could document the>4K attributes. IMO support for attributes > 4K is a logic consequence of the fragmentation support given by our proposal. > I'll see if I can write a short proposal to the radext list. If it's > acceptable to the WG, I can put a draft together. Precisely we were about to modify our document to reflect this, if the idea was reasonable. That was the intention of sending it first to the list, to see if there were objections before starting writing a new draft. Regards, Alejandro > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Jan 16 07:40:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7721F8680; Mon, 16 Jan 2012 07:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwELwXoBh-T5; Mon, 16 Jan 2012 07:40:38 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 107C621F8606; Mon, 16 Jan 2012 07:40:19 -0800 (PST) Message-ID: <4F1444C7.7010909@deployingradius.com> Date: Mon, 16 Jan 2012 16:39:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> In-Reply-To: <4F144287.40505@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 15:40:38 -0000 Alejandro Perez Mendez wrote: > We also thought that a new flag "T" could indicate the attribute is > truncated across several packets. That sounds good. > Precisely we were about to modify our document to reflect this, if the > idea was reasonable. That was the intention of sending it first to the > list, to see if there were objections before starting writing a new draft. My notes about this are: - the first Access-Accept must contain Service-Type = Authorize-Only *or* a new Servicer-Type = Additional-Authorization This means that the user is not given network access when the implementation does not support the new method. - the first Access-Accept must contain a State attribute for is already required for use of Authorize-Only - additional authorization attributes are received via a series of Access-Request / Access-Challenge - each Access-Request MUST contain Service-Type = Authorize-Only and a State - the State MUST change for each Access-Challenge response I can get into that later - the final Access-Accept contains the real Service-Type for the user Alan DeKok. From dnelson@elbrys.com Mon Jan 16 07:38:59 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C7121F867A; Mon, 16 Jan 2012 07:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrsca0vIjMEM; Mon, 16 Jan 2012 07:38:58 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id 3D21521F862B; Mon, 16 Jan 2012 07:38:53 -0800 (PST) Received: from mail-vw0-f47.google.com ([209.85.212.47]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKTxREgNIimYhwQFdPeKLOO1C6KWZq/XzA@postini.com; Mon, 16 Jan 2012 07:38:53 PST Received: by mail-vw0-f47.google.com with SMTP id l22so612996vbn.20 for ; Mon, 16 Jan 2012 07:38:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.45 with SMTP id j13mr6155079vdu.115.1326728320554; Mon, 16 Jan 2012 07:38:40 -0800 (PST) Received: by 10.52.26.68 with HTTP; Mon, 16 Jan 2012 07:38:40 -0800 (PST) In-Reply-To: <4F144287.40505@um.es> References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> Date: Mon, 16 Jan 2012 10:38:40 -0500 Message-ID: From: Dave Nelson To: Alejandro Perez Mendez Content-Type: multipart/alternative; boundary=20cf307f39ac42986204b6a702a3 X-Mailman-Approved-At: Mon, 16 Jan 2012 07:42:54 -0800 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 15:38:59 -0000 --20cf307f39ac42986204b6a702a3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez wrote: > > We also thought that a new flag "T" could indicate the attribute is > truncated across several packets. Yeah. I would favor the definition of another flag bit, rather than mixing flags and "signal" attributes to accomplished related purposes. It's just more symmetrical. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --20cf307f39ac42986204b6a702a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = <alex@um.es> wrote:

We also thought that a new flag "T" could indicate the attribute = is truncated across several packets.

Yeah. = =A0I would favor the definition of another flag bit, rather than mixing fla= gs and "signal" attributes to accomplished related purposes. =A0I= t's just more symmetrical.=A0

Regards,

Dave

David B. Nelson
Sr. Software Archi= tect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--20cf307f39ac42986204b6a702a3-- From diego@tid.es Mon Jan 16 08:02:17 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6B621F8677; Mon, 16 Jan 2012 08:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.368 X-Spam-Level: X-Spam-Status: No, score=-5.368 tagged_above=-999 required=5 tests=[AWL=1.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXjOScSiP8Jz; Mon, 16 Jan 2012 08:02:16 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 50F7D21F8602; Mon, 16 Jan 2012 08:02:16 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00G4ZF7REB@tid.hi.inet>; Mon, 16 Jan 2012 17:02:15 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id BC.E6.02643.70A441F4; Mon, 16 Jan 2012 17:02:15 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXW00G4UF7QEB@tid.hi.inet>; Mon, 16 Jan 2012 17:02:15 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 16 Jan 2012 17:02:14 +0100 Date: Mon, 16 Jan 2012 17:02:13 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F1444C7.7010909@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczUaDZFBoHYHcRZT/+RlhFKCOuGJQ== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-5f-4f144a074421 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsXCFe9nqMvuJeJvsLCDx+Lj9TeMFi2vZrI5 MHksWfKTKYAxissmJTUnsyy1SN8ugSvj7MGX7AVXRCp+3JdsYJwg0sXIySEhYCJxo6eFBcIW k7hwbz1bFyMXh5DANkaJab9uMEE4Txklbl1tZodwGhkl3l3oYgdpYRFQldiw7DQziM0moC7R cvQb2ChhgWyJM3PfsYLYnALGEhf6OsFqRAS0JBasXwRUw8HBLFAoMfWCDkiYV8BSorv7GTOE LSjxY/I9qBJ1iSlTckHCzALiEs2tN1kgbEWJaYsaGEFsRqCjv59awwQxPUfi1IzDbBC2nsTt mZ+YIWpEJe60r2eEeFJAYsme88wQtqjEy8f/wK4UEjjPLDGpQWUCo/gsJFfMQrhiFpIrZiG5 YgEjyypGseKkosz0jJLcxMycdAMjvYxMvcy81JJNjJBYytzBuHynyiFGAQ5GJR7eh4XC/kKs iWXFlbmHGCU5mJREedncRPyF+JLyUyozEosz4otKc1KLDzFKcDArifC26QOV86YkVlalFuXD pGQ4OJQkeFU8gdoEi1LTUyvSMnOACQMmzcTBCdLOA9QeDVLDW1yQmFucmQ6RP8UoKSXO6wWS EABJZJTmwfW+YhQHOlKYNwokywNMbXBdr4AGMgENzGkVAhlYkoiQkmpgrOA3+rfRvr1K6MCE xK+672oKLp7/f8gn5cPrOKN+0dMnI6oVHxSLLnp11znqZa+bi26QnnTq5q2H30q5qf/OvHni k3HNhYiF2nVXQubxfHx8efn6rYrVXda5cW9bHrKmmVuld7x2Z9olvOxMxWPD9LiMT4JZk7m+ NDUY1LjPP7D3VpPrhodRSizFGYmGWsxFxYkAskgsgyoDAAA= References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 16:02:17 -0000 DQpPbiAxNiBKYW4gMjAxMiwgYXQgMTY6MzkgLCBBbGFuIERlS29rIHdyb3RlOg0KPiBBbGVqYW5k cm8gUGVyZXogTWVuZGV6IHdyb3RlOg0KPj4gV2UgYWxzbyB0aG91Z2h0IHRoYXQgYSBuZXcgZmxh ZyAiVCIgY291bGQgaW5kaWNhdGUgdGhlIGF0dHJpYnV0ZSBpcw0KPj4gdHJ1bmNhdGVkIGFjcm9z cyBzZXZlcmFsIHBhY2tldHMuDQo+DQo+ICBUaGF0IHNvdW5kcyBnb29kLg0KDQpBcGFydCB0aGF0 IEkgdGhpbmsgaXQgd291bGQgbWFrZSB0aGUgbWVjaGFuaXNtcyBzaW1wbGVyIHRvIGRlYWwgd2l0 aCwgSSBtdXN0IHNheSBJIGxpa2UgRGF2ZSdzIHN5bW1ldHJ5IGFyZ3VtZW50IGZvciB0aGUgIlQi IGZsYWcuDQoNCj4gLSB0aGUgZmlyc3QgQWNjZXNzLUFjY2VwdCBtdXN0IGNvbnRhaW4gU2Vydmlj ZS1UeXBlID0gQXV0aG9yaXplLU9ubHkNCj4gICpvciogYSBuZXcgU2VydmljZXItVHlwZSA9IEFk ZGl0aW9uYWwtQXV0aG9yaXphdGlvbg0KPg0KPiAgVGhpcyBtZWFucyB0aGF0IHRoZSB1c2VyIGlz IG5vdCBnaXZlbiBuZXR3b3JrIGFjY2VzcyB3aGVuIHRoZQ0KPiAgaW1wbGVtZW50YXRpb24gZG9l cyBub3Qgc3VwcG9ydCB0aGUgbmV3IG1ldGhvZC4NCg0KSW4gdGhlIHNhbWUgc3Bpcml0IG9mIGtl ZXBpbmcgY2xhcml0eSwgSSdkIHNheSB0aGF0IEFkZGl0aW9uYWwtQXV0aG9yaXphdGlvbiB3b3Vs ZCBiZSBtb3JlIGNvcnJlY3QgY2hvaWNlLCB1bmxlc3MgYWRkaW5nIGEgbmV3IFNlcnZpY2UtVHlw ZSB3b3VsZCBzb21laG93IGNvbXBsaWNhdGUgYWRvcHRpb24uLi4NCg0KPiAtIHRoZSBmaXJzdCBB Y2Nlc3MtQWNjZXB0IG11c3QgY29udGFpbiBhIFN0YXRlIGF0dHJpYnV0ZQ0KPiAgZm9yIGlzIGFs cmVhZHkgcmVxdWlyZWQgZm9yIHVzZSBvZiBBdXRob3JpemUtT25seQ0KPg0KPiAtIGFkZGl0aW9u YWwgYXV0aG9yaXphdGlvbiBhdHRyaWJ1dGVzIGFyZSByZWNlaXZlZCB2aWEgYSBzZXJpZXMNCj4g IG9mIEFjY2Vzcy1SZXF1ZXN0IC8gQWNjZXNzLUNoYWxsZW5nZQ0KPg0KPiAgLSBlYWNoIEFjY2Vz cy1SZXF1ZXN0IE1VU1QgY29udGFpbiBTZXJ2aWNlLVR5cGUgPSBBdXRob3JpemUtT25seQ0KPiAg ICBhbmQgYSBTdGF0ZQ0KDQpPciwgcmVzcGVjdGl2ZWx5LCBBZGRpdGlvbmFsLUF1dGhvcml6YXRp b24sIGlzbid0IGl0Pw0KDQo+ICAtIHRoZSBTdGF0ZSBNVVNUIGNoYW5nZSBmb3IgZWFjaCBBY2Nl c3MtQ2hhbGxlbmdlIHJlc3BvbnNlDQo+ICAgIEkgY2FuIGdldCBpbnRvIHRoYXQgbGF0ZXINCg0K SSBjYW4gaW1hZ2luZSB0aGlzIGlzIHdpdGggdGhlIGludGVudGlvbiBvZiBndWFyYW50ZWVpbmcg b3JkZXIgYW5kIGF2b2lkaW5nIChvciBhbGxldmlhdGluZykgTUlUTSBhdHRhY2tzLCByaWdodD8N Cg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmll cm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCg0KZS1tYWlsOiBkaWVn b0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5 MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpFc3RlIG1l bnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBj b25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3Jy ZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From aland@deployingradius.com Mon Jan 16 08:11:43 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF32D21F8508; Mon, 16 Jan 2012 08:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2FYGeuKAWOC; Mon, 16 Jan 2012 08:11:43 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0902321F84FA; Mon, 16 Jan 2012 08:11:43 -0800 (PST) Message-ID: <4F144C22.40103@deployingradius.com> Date: Mon, 16 Jan 2012 17:11:14 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 16:11:43 -0000 DIEGO LOPEZ GARCIA wrote:> > In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption... I agree. >> - each Access-Request MUST contain Service-Type = Authorize-Only >> and a State > > Or, respectively, Additional-Authorization, isn't it? The Access-Challenge should contain Additional-Authorization. The request should probably contain Authorize-Only. >> - the State MUST change for each Access-Challenge response >> I can get into that later > > I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right? It's a way to guarantee ordering. I'm not sure if MITM attacks are anything we care about. Every entity in the AAA system is trusted, and the packets are signed to prevent non-AAA systems from modifying them.. Alan DeKok. From rafa@um.es Mon Jan 16 11:04:29 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55E921F86B8; Mon, 16 Jan 2012 11:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N09NgAnpHTDd; Mon, 16 Jan 2012 11:04:29 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 994B421F86AF; Mon, 16 Jan 2012 11:04:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 3FCF95D48E; Mon, 16 Jan 2012 20:04:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vYe4fcnyybrd; Mon, 16 Jan 2012 20:04:25 +0100 (CET) Received: from inf-205-13.inf.um.es (inf-205-13.inf.um.es [155.54.205.13]) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPA id 4CF5F5D51C; Mon, 16 Jan 2012 20:04:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F" From: Rafa Marin Lopez In-Reply-To: Date: Mon, 16 Jan 2012 20:04:19 +0100 Message-Id: <67333C97-D1A5-4C81-817C-94BC0766A81B@um.es> References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> To: Dave Nelson X-Mailer: Apple Mail (2.1251.1) Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 19:04:29 -0000 --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Dave: El 16/01/2012, a las 16:38, Dave Nelson escribi=F3: > On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = wrote: >=20 > We also thought that a new flag "T" could indicate the attribute is = truncated across several packets. >=20 > Yeah. I would favor the definition of another flag bit, rather than = mixing flags and "signal" attributes to accomplished related purposes. = It's just more symmetrical.=20 Just a clarification here. Our goal (authors of = draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism = for fragmentation between RADIUS packets when they exceed 4K = (inter-packet fragmentation). If we remove the signal attribute (e.g. = "More-Data-Pending"), the flag T should mean that the RADIUS packet is = truncated (and not necessarily the attribute where the flag T is = activated). For example:=20 A,B,C,... ,Y are attributes of different types in one RADIUS packet. = Adding attribute Z exceeds 4K, so we should signal that. We could decide = to activate the bit T in the last attribute Y[T], but, actually, it does = not mean anything in the context of extended attribute Y[T], since we = want to signal that more attributes (perhaps, of any other type as, for = example, Z) are coming after this list in a different RADIUS packet. In this sense, we believe that the presence of some kind of attribute = "More-Data-Pending" (or any other type of signaling at packet level) can = inform about this situation within the context of the RADIUS packet.=20 Best regards. >=20 > Regards, >=20 > Dave >=20 > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Dave:

El 16/01/2012, a las 16:38, Dave Nelson = escribi=F3:

On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = <alex@um.es> wrote:

We also thought that a new flag "T" could indicate the attribute is = truncated across several packets.

Yeah. =  I would favor the definition of another flag bit, rather than = mixing flags and "signal" attributes to accomplished related purposes. =  It's just more = symmetrical. 

Just a = clarification here. Our goal (authors of = draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism = for fragmentation between RADIUS packets when they exceed 4K = (inter-packet fragmentation). If we remove the signal attribute = (e.g. "More-Data-Pending"), the flag T should mean that the RADIUS = packet is truncated (and not necessarily the attribute where the flag T = is activated). For = example: 

A,B,C,... ,Y are attributes of = different types in one RADIUS packet. Adding attribute Z exceeds 4K, so = we should signal that. We could decide to activate the bit T in the last = attribute Y[T], but, actually, it does not mean anything in the context = of extended attribute Y[T], since we want to signal that more attributes = (perhaps, of any other type as, for example, Z) are coming after this = list in a different RADIUS packet.

In this = sense, we believe that the presence of some kind of attribute = "More-Data-Pending" (or any other type of signaling at packet level) can = inform about this situation within the context of the RADIUS = packet. 

Best = regards.


Regards,

Dave

David B. Nelson
Sr. Software = Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
_______________________________________________
abfab mailing = list
abfab@ietf.org
https://www.ietf.org/= mailman/listinfo/abfab

-------------------------------------------------------
<= div>Rafael Marin Lopez, PhD
Dept. Information and = Communications Engineering (DIIC)
Faculty of Computer = Science-University of Murcia
30100 Murcia - = Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
----------------------= ---------------------------------




= --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F-- From arran.cudbard-bell@mancalanetworks.com Mon Jan 16 08:23:17 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0321F8690; Mon, 16 Jan 2012 08:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIrMRVEZRZOP; Mon, 16 Jan 2012 08:23:17 -0800 (PST) Received: from mail.mancalanetworks.com (mail.mancalanetworks.com [46.105.178.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4091E21F868C; Mon, 16 Jan 2012 08:23:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mancalanetworks.com (Postfix) with ESMTP id 318F31E2FA54; Mon, 16 Jan 2012 17:23:15 +0100 (CET) X-Virus-Scanned: amavisd-new at mancalanetworks.com Received: from mail.mancalanetworks.com ([127.0.0.1]) by localhost (mail.mancalanetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-9G9fsInQdF; Mon, 16 Jan 2012 17:23:14 +0100 (CET) Received: from [10.10.0.108] (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by mail.mancalanetworks.com (Postfix) with ESMTPSA id 05A6D1E2E4F5; Mon, 16 Jan 2012 17:23:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Arran Cudbard-Bell In-Reply-To: Date: Mon, 16 Jan 2012 17:23:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> To: DIEGO LOPEZ GARCIA X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Tue, 17 Jan 2012 08:07:40 -0800 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jan 2012 16:23:18 -0000 > In the same spirit of keeping clarity, I'd say that = Additional-Authorization would be more correct choice, unless adding a = new Service-Type would somehow complicate adoption... Agreed. >=20 >> - the first Access-Accept must contain a State attribute >> for is already required for use of Authorize-Only >>=20 >> - additional authorization attributes are received via a series >> of Access-Request / Access-Challenge >>=20 >> - each Access-Request MUST contain Service-Type =3D Authorize-Only >> and a State >=20 > Or, respectively, Additional-Authorization, isn't it? No it's an extension/reworking of the concept described in RFC 3576 3.1, = but the trigger is an Access-Accept packet with the = Service-Type/Additional-Authorization attribute. >=20 >> - the State MUST change for each Access-Challenge response >> I can get into that later >=20 > I can imagine this is with the intention of guaranteeing order and = avoiding (or alleviating) MITM attacks, right? Yes, correct. The packets don't contain any explicit ordering = information, so the attributes are just concatenated together in the = order they're received. -Arran= From hartmans@painless-security.com Wed Jan 18 05:33:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A05921F872E for ; Wed, 18 Jan 2012 05:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLCGApF-i6w4 for ; Wed, 18 Jan 2012 05:33:13 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8E94921F8715 for ; Wed, 18 Jan 2012 05:33:13 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 73E752043D for ; Wed, 18 Jan 2012 08:32:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 76BE34664; Wed, 18 Jan 2012 08:33:00 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Wed, 18 Jan 2012 08:33:00 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] [#31] need help with errors for draft-ietf-abfab-gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2012 13:33:14 -0000 Folks, one of the big stumbling blocks in being done with the core mechanism spec is handling of errors. To remind you, the current error token format is as follows; The acceptor may always end the exchange by generating an error subtoken. The error subtoken has the following format: +--------+----------------------------------------------------------+ | Pos | Description | +--------+----------------------------------------------------------+ | 0..3 | 0x80 00 00 01 | | | | | 4..7 | length of error token | | | | | 8..11 | major status from RFC 2744 as 32-bit network byte order | | | | | 12..15 | GSS EAP error code as 32-bit network byte order; see | | | Section 8.4 | +--------+----------------------------------------------------------+ Initiators MUST ignore octets beyond the GSS EAP error code for future extensibility. As indicated, the error token is always marked critical. Here are the error codes we can currently send back. I'd appreciate comments on whether these are reasonable and on whether we need more. error_code GSSEAP_WRONG_SIZE, "Buffer is incorrect size" error_code GSSEAP_WRONG_MECH, "Mechanism OID is incorrect" error_code GSSEAP_BAD_TOK_HEADER, "Token header is malformed or corrupt" error_code GSSEAP_TOK_TRUNC, "Token is missing data" error_code GSSEAP_BAD_DIRECTION, "Packet was replayed in wrong direction" error_code GSSEAP_WRONG_TOK_ID, "Received token ID does not match expected token ID" error_code GSSEAP_CRIT_ITOK_UNAVAILABLE, "Critical inner token type unavailable" error_code GSSEAP_MISSING_REQUIRED_ITOK, "Missing required inner token" error_code GSSEAP_DUPLICATE_ITOK, "Duplicate inner token received" error_code GSSEAP_WRONG_ITOK, "Recieved invalid inner token for current state" error_code GSSEAP_KEY_UNAVAILABLE, "EAP key unavailable" error_code GSSEAP_KEY_TOO_SHORT, "EAP key too short" error_code GSSEAP_RADIUS_AUTH_FAILURE, "Authentication rejected by RADIUS server" error_code GSSEAP_UNKNOWN_RADIUS_CODE, "Received unknown response code from RADIUS server" error_code GSSEAP_MISSING_EAP_REQUEST, "RADIUS response is missing EAP request" error_code GSSEAP_RADIUS_PROT_FAILURE, "Generic RADIUS failure" From klaas@cisco.com Fri Jan 20 02:01:52 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C7F21F854D for ; Fri, 20 Jan 2012 02:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.355 X-Spam-Level: X-Spam-Status: No, score=-8.355 tagged_above=-999 required=5 tests=[AWL=2.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAUSFcEuwhsZ for ; Fri, 20 Jan 2012 02:01:48 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 956F021F8522 for ; Fri, 20 Jan 2012 02:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=192; q=dns/txt; s=iport; t=1327053708; x=1328263308; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=nLho2NVP+iIH+OV5oaz5giM7e9p8hPaSsA93+RclnCU=; b=RbXgxM3yFKe/s91a8zy7bUSyb0w4nDQKWBZ29avUcQ1Fq+Xd2MOGxw0c wM823ctNIutF5fsx6eToYkFYQVtjCfTk3gaxYqqwFC1tqqAwv1n1wJu7j RvTuCtL6SOnhW3Z5YqFQEBg7Q+1NEBjNpJdWEVG2zySRf0DS74VBlOMTq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAIg6GU+tJV2Y/2dsb2JhbABDrXuBBYILAQodP4FzohkBnkSJCoI5YwSVGJJM X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="52605144" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jan 2012 10:01:48 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0KA1lbo024635; Fri, 20 Jan 2012 10:01:47 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2012 11:01:46 +0100 Message-Id: <3960E2A3-DF75-4054-97FC-D092456A1BE7@cisco.com> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: abfab-chairs@tools.ietf.org Subject: [abfab] call for agenda items abfab@ietf83 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jan 2012 10:01:52 -0000 Hi, We have requested a 1,5 hour slot for IETF83 and at this time would like = to solicit presentations. If you want to present can you please let us = know? Cheers, Klaas & Leif= From hartmans@painless-security.com Wed Jan 25 10:50:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79FE1F0C3E for ; Wed, 25 Jan 2012 10:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WC6g7a8ywow for ; Wed, 25 Jan 2012 10:50:14 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4B74D1F0C35 for ; Wed, 25 Jan 2012 10:50:13 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9E24920424; Wed, 25 Jan 2012 13:49:22 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 083484690; Wed, 25 Jan 2012 13:50:11 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <4F042256.5080805@um.es> Date: Wed, 25 Jan 2012 13:50:11 -0500 In-Reply-To: <4F042256.5080805@um.es> (Alejandro Perez Mendez's message of "Wed, 04 Jan 2012 10:56:38 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jan 2012 18:50:14 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: >>> * Added motivation section indicating why this is required. >> This is a definitely a good addition; however, I don't believe >> that it is complete. Ideally I think it needs to consider the >> questions that I raised previously in the context of the previous >> discussion that Sam initiated about generic gss pre-auth versus >> gss-eap pre-auth: >> >>> What are the practical benefits of a generic gss pre-auth >>> mechanism when Kerberos pre-auth itself provides an extensible >>> framework? I can see that there is value in the re-using >>> deployed gss mechanisms if this avoids having to create >>> functionally-equivalent but redundant pre-auth mechanisms in the >>> case where an equivalent gss mechanism already exists, but are >>> there really so many of these that this is a compelling >>> argument? It sounds as though there is potentially a trade-off >>> that we could make between complexity and generality. >> >> FWIW I haven't developed an opinion on these yet, but I would be >> interested to hear if you have any... Alejandro> since the principal final purpose of this draft (in Alejandro> conjunction with the other one submitted to the ABFAB WG) Alejandro> is to enable the KDC to authenticate users based on the Alejandro> GSS-EAP mechanism, I don't see any advantage in Alejandro> transporting GSS tokens on top of FAST. It adds an Alejandro> additional an unnecessary layer, since nor GSS-API nor Alejandro> EAP assume any kind of secure transport. Josh and I are not asking about FAST. We're asking about whether GSS-API is the right layer for this. To me this is the big open question in whether I personally thing this draft should be advanced and any discussion you can provide of the issues I brought up buth in general and with regard to the use case of a service wanting to obtain a service ticket regardless of client support would be valuable in making my own determination about this draft. --Sam From alex@um.es Wed Jan 25 23:31:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0BD21F8661 for ; Wed, 25 Jan 2012 23:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2wrbWbJ64SV for ; Wed, 25 Jan 2012 23:31:21 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0102521F8650 for ; Wed, 25 Jan 2012 23:31:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 429AE5D4D2; Thu, 26 Jan 2012 08:31:17 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aTZuxxZXGjS8; Thu, 26 Jan 2012 08:31:17 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id B31155D4CF; Thu, 26 Jan 2012 08:31:16 +0100 (CET) Message-ID: <4F210143.50103@um.es> Date: Thu, 26 Jan 2012 08:31:15 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Sam Hartman References: <4F042256.5080805@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2012 07:31:22 -0000 El 25/01/12 19:50, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > >>> * Added motivation section indicating why this is required. > >> This is a definitely a good addition; however, I don't believe > >> that it is complete. Ideally I think it needs to consider the > >> questions that I raised previously in the context of the previous > >> discussion that Sam initiated about generic gss pre-auth versus > >> gss-eap pre-auth: > >> > >>> What are the practical benefits of a generic gss pre-auth > >>> mechanism when Kerberos pre-auth itself provides an extensible > >>> framework? I can see that there is value in the re-using > >>> deployed gss mechanisms if this avoids having to create > >>> functionally-equivalent but redundant pre-auth mechanisms in the > >>> case where an equivalent gss mechanism already exists, but are > >>> there really so many of these that this is a compelling > >>> argument? It sounds as though there is potentially a trade-off > >>> that we could make between complexity and generality. > >> > >> FWIW I haven't developed an opinion on these yet, but I would be > >> interested to hear if you have any... > > > Alejandro> since the principal final purpose of this draft (in > Alejandro> conjunction with the other one submitted to the ABFAB WG) > Alejandro> is to enable the KDC to authenticate users based on the > Alejandro> GSS-EAP mechanism, I don't see any advantage in > Alejandro> transporting GSS tokens on top of FAST. It adds an > Alejandro> additional an unnecessary layer, since nor GSS-API nor > Alejandro> EAP assume any kind of secure transport. > > Josh and I are not asking about FAST. > We're asking about whether GSS-API is the right layer for this. > > To me this is the big open question in whether I personally thing this > draft should be advanced and any discussion you can provide of the > issues I brought up buth in general and with regard to the use case of a > service wanting to obtain a service ticket regardless of client support > would be valuable in making my own determination about this draft. Hi Sam, I don't see why the applicability of this proposal to a very specific use case should influence on its adoption. The draft proposes a pre-authentication mechanism based on GSS-API. It may be useful for many use cases other than the one you proposed. Specifically, it is required for the use case proposed in draft-perez-abfab-eap-gss-preauth. If it does not correctly address the requirements of the use case you have in mind, I can agree it may not be the most adequate selection for that specific use case. But as I see it, it does not directly convert it into unusable, as other use cases can still be satisfied using it. Best regards, Alejandro > > --Sam From rafa@um.es Thu Jan 26 04:14:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EDC21F8685 for ; Thu, 26 Jan 2012 04:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzerT7fPrUen for ; Thu, 26 Jan 2012 04:14:25 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id A2E1A21F8666 for ; Thu, 26 Jan 2012 04:14:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 59F61535B7; Thu, 26 Jan 2012 13:14:23 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zz0iq8b5Idsk; Thu, 26 Jan 2012 13:14:22 +0100 (CET) Received: from inf-205-13.inf.um.es (inf-205-13.inf.um.es [155.54.205.13]) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPA id 45F5A53600; Thu, 26 Jan 2012 13:14:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Thu, 26 Jan 2012 13:14:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85C1CAD0-3544-440A-9924-1F4EE24583A1@um.es> References: <4F042256.5080805@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1251.1) Cc: "abfab@ietf.org" Subject: Re: [abfab] [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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 Jan 2012 12:14:25 -0000 Hi Sam: Besides Alex's comments, I believe I had provided some clarifications to = these questions in: http://www.ietf.org/mail-archive/web/abfab/current/msg01098.html Since there was no answer back, I thought it was clarified. Otherwise, I = would suggest to read it to see if there is agreement on the comments. Having said that, we already sketched/discussed = (http://www.ietf.org/mail-archive/web/abfab/current/msg00040.html)=20 an EAP pre-authentication over KRB solution without using GSS-API, with = the same goal: to define a flexible pre-authentication mechanism for = Kerberos. If the WG considers more interesting to re-take this line of work = providing an EAP pre-authentication in Kerberos, we can collaborate in = defining it. Regarding your use case, our intention has not been to define any = transport for EAP in the backend. Again, if the WG believes this should be considered as well (I hope we all agree that they are = completely different goals), then people interested on it (maybe Josh = and you) may contribute in defining it.=20 Best regards. =20 El 25/01/2012, a las 19:50, Sam Hartman escribi=F3: >>>>>> "Alejandro" =3D=3D Alejandro Perez Mendez writes: >=20 >>>> * Added motivation section indicating why this is required. >>> This is a definitely a good addition; however, I don't believe >>> that it is complete. Ideally I think it needs to consider the >>> questions that I raised previously in the context of the previous >>> discussion that Sam initiated about generic gss pre-auth versus >>> gss-eap pre-auth: >>>=20 >>>> What are the practical benefits of a generic gss pre-auth >>>> mechanism when Kerberos pre-auth itself provides an extensible >>>> framework? I can see that there is value in the re-using >>>> deployed gss mechanisms if this avoids having to create >>>> functionally-equivalent but redundant pre-auth mechanisms in the >>>> case where an equivalent gss mechanism already exists, but are >>>> there really so many of these that this is a compelling >>>> argument? It sounds as though there is potentially a trade-off >>>> that we could make between complexity and generality. >>>=20 >>> FWIW I haven't developed an opinion on these yet, but I would be >>> interested to hear if you have any... >=20 >=20 > Alejandro> since the principal final purpose of this draft (in > Alejandro> conjunction with the other one submitted to the ABFAB = WG) > Alejandro> is to enable the KDC to authenticate users based on the > Alejandro> GSS-EAP mechanism, I don't see any advantage in > Alejandro> transporting GSS tokens on top of FAST. It adds an > Alejandro> additional an unnecessary layer, since nor GSS-API nor > Alejandro> EAP assume any kind of secure transport. >=20 > Josh and I are not asking about FAST. > We're asking about whether GSS-API is the right layer for this. >=20 > To me this is the big open question in whether I personally thing this > draft should be advanced and any discussion you can provide of the > issues I brought up buth in general and with regard to the use case of = a > service wanting to obtain a service ticket regardless of client = support > would be valuable in making my own determination about this draft. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es -------------------------------------------------------