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: Sat, 13 Feb 2010 16:58:55 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" Sam wrote: > > Ah! My terminology failure. Can we include a hash of the SAML=20 > > message in the artifact or along side the artifact to get=20 > authenticity=20 > > of the SAML message? Josh wrote: > Probably. I've discovered an issue in the specification which=20 > might prevent this (there is a requirement to "authenticate"=20 > the issuer, which to me implies a demonstration of authority=20 > to wield a name; whereas in this instance we only need to=20 > demonstrate authority to wield a SAML message). I've emailed=20 > the SSTC list for clarification. Bad news. As I suspected, it is a requirement that the call-back used to the resolve the artifact is authenticated at the transport layer. Scott's advice was to avoid artifact resolution "at all costs". I see two possible options: 1. Ignore the RADIUS spec's MTU requirement, and use RadSec to transport the SAML message by value over TCP. The argument for doing this is that the RADIUS MTU makes sense for UDP, but not for TCP, and being dogmatic about the RADIUS spec is going to significantly increase complexity. There are sufficiently few RadSec implementations at the moment that we're realistically unlikely to cause any actual harm. Most importantly, it is also simple and robust. The argument for not doing this is that we're abusing the RADIUS spec. 2. TAS and TAC derive a new key for the artifact call-back from the established AAA context. TAS replicates a copy to S with the Access-Accept, together with the artifact. S uses the key and the artifact to resolve the SAML message. Any other ideas? 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 klaas@cisco.com Wed Jan 2 04:44:17 2013 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 1601921F90BF for ; Wed, 2 Jan 2013 04:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMfnBRF+zYfw for ; Wed, 2 Jan 2013 04:44:16 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 37FD621F90B9 for ; Wed, 2 Jan 2013 04:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=265; q=dns/txt; s=iport; t=1357130656; x=1358340256; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=D6cUTane2IBwR1l06LSMI6W1PeRRoFF2+pnXN/QpHsY=; b=QnwoxbanH2og2429YBN+89+y9c6VIRDanssvD5yJ0t/lqXNgYpEpNq9+ SkyGM/5SUmzX9olU7dQnsq0v+IVOzNE0lN39GIbrnkw3od89EjvnM7sbg 9TAFKQ9VFQn02xXGxV2U8RzDyKgy2NOHlwLVEQAkyflNxj1Eqsf9l6zwA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao2KAAMq5FCQ/khM/2dsb2JhbABFgX+BSbkHBAJ3FnOCX4F9iCaZHZ8dkDlhA5YMkEiCdQ X-IronPort-AV: E=Sophos;i="4.84,395,1355097600"; d="scan'208";a="148934955" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 02 Jan 2013 12:44:15 +0000 Received: from dhcp-10-61-103-2.cisco.com (dhcp-10-61-103-2.cisco.com [10.61.103.2]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r02Ci9kP011989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 2 Jan 2013 12:44:11 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0AB733FA-2600-4183-A8C9-42B1456BEFB0@cisco.com> Date: Wed, 2 Jan 2013 13:44:12 +0100 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [abfab] abfab meeting in Orlando 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, 02 Jan 2013 12:44:17 -0000 Hi all, First of all, Happy Newyear!=20 We have requested a 2 hour slot for the coming IETF, with as main agenda = items the remaining documents and a rechartering discussion. Please let us know if you want to be on the agenda! Cheers, Klaas & Leif= From smith@Cardiff.ac.uk Tue Jan 8 03:54:18 2013 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 400E221F8CD1 for ; Tue, 8 Jan 2013 03:54:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee7-o4Gz74sd for ; Tue, 8 Jan 2013 03:54:17 -0800 (PST) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 75F9121F8CF0 for ; Tue, 8 Jan 2013 03:54:15 -0800 (PST) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1TsXl0-0007Rp-7N for abfab@ietf.org; Tue, 08 Jan 2013 11:54:14 +0000 Received: from [86.185.254.224] (helo=penelope.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1TsXl0-0002j1-4e for abfab@ietf.org; Tue, 08 Jan 2013 11:54:14 +0000 From: Rhys Smith Content-Type: multipart/alternative; boundary="Apple-Mail=_890C0FC2-D86C-4C5B-B101-AED930322BD1" Date: Tue, 8 Jan 2013 11:54:10 +0000 References: <20130108115054.28165.44903.idtracker@ietfa.amsl.com> To: abfab@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] Fwd: New Version Notification for draft-smith-abfab-usability-ui-considerations-03.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: Tue, 08 Jan 2013 11:54:18 -0000 --Apple-Mail=_890C0FC2-D86C-4C5B-B101-AED930322BD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FYI. I've bumped the version of the usability/UI draft just to keep it = alive, as it was due to expire in a couple of days. No real changes from = -02. But, I'm going to be updating it over the next week or so and submitting = an updated version, so if anyone has any input into that process above = that which I've already received it would be most welcome=85=20 Best, Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-smith-abfab-usability-ui-considerations-03.txt > Date: 8 January 2013 11:50:54 GMT > To: smith@cardiff.ac.uk >=20 >=20 > A new version of I-D, = draft-smith-abfab-usability-ui-considerations-03.txt > has been successfully submitted by Rhys Smith and posted to the > IETF repository. >=20 > Filename: draft-smith-abfab-usability-ui-considerations > Revision: 03 > Title: Application Bridging for Federated Access = Beyond web (ABFAB) Usability and User Interface Considerations > Creation date: 2013-01-08 > WG ID: Individual Submission > Number of pages: 15 > URL: = http://www.ietf.org/internet-drafts/draft-smith-abfab-usability-ui-conside= rations-03.txt > Status: = http://datatracker.ietf.org/doc/draft-smith-abfab-usability-ui-considerati= ons > Htmlized: = http://tools.ietf.org/html/draft-smith-abfab-usability-ui-considerations-0= 3 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-abfab-usability-ui-consider= ations-03 >=20 > Abstract: > The use of ABFAB-based technologies requires that each user's device > is configured with the user's identities that they wish to use in > ABFAB transactions. This will require something on that device, > either built into the operating system or a standalone utility, that > will manage the user's identities and identity to service mappings. > Anyone designing that "something" will face the same set of > challenges. This document aims to document these challenges with = the > aim of producing well-thought out UIs with some degree of > consistency. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_890C0FC2-D86C-4C5B-B101-AED930322BD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 FYI. = I've bumped the version of the usability/UI draft just to keep it alive, = as it was due to expire in a couple of days. No real changes from = -02.

But, I'm going to be updating it over the next = week or so and submitting an updated version, so if anyone has any input = into that process above that which I've already received it would be = most = welcome=85 

Best,
Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware = Specialist
Cardiff University & Janet - the UK's research and = education network

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

Begin forwarded message:

Subject: New Version Notification for = draft-smith-abfab-usability-ui-considerations-03.txt
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">Date: 8 January 2013 = 11:50:54 GMT
To: smith@cardiff.ac.uk


A new version of I-D, = draft-smith-abfab-usability-ui-considerations-03.txt
has been = successfully submitted by Rhys Smith and posted to the
IETF = repository.

Filename: = draft-smith-abfab-usability-ui-considerations
Revision: = 03
Title: = = Application Bridging for Federated Access Beyond web (ABFAB) = Usability and User Interface Considerations
Creation date: = 2013-01-08
WG ID: Individual Submission
Number = of pages: 15
URL: =             http://www.ietf.org/internet-drafts/draft-smith-ab= fab-usability-ui-considerations-03.txt
Status: =          http://datatracker.ietf.org/doc/draft-smith-abfab-usability-u= i-considerations
Htmlized: =        http://tools.ietf.org/html/draft-smith-abfab-usability-ui-consi= derations-03
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-abfab-us= ability-ui-considerations-03

Abstract:
  The = use of ABFAB-based technologies requires that each user's device
=   is configured with the user's identities that they wish to = use in
  ABFAB transactions.  This will require = something on that device,
  either built into the = operating system or a standalone utility, that
  will = manage the user's identities and identity to service mappings.
=   Anyone designing that "something" will face the same set = of
  challenges.  This document aims to document = these challenges with the
  aim of producing well-thought = out UIs with some degree of
=   consistency.




The IETF = Secretariat


= --Apple-Mail=_890C0FC2-D86C-4C5B-B101-AED930322BD1-- From hartmans@painless-security.com Fri Jan 18 11:45:05 2013 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 06C8521F8799 for ; Fri, 18 Jan 2013 11:45:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW3L7mrvrOez for ; Fri, 18 Jan 2013 11:45:04 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5B47421F8759 for ; Fri, 18 Jan 2013 11:45:04 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id D340620289 for ; Fri, 18 Jan 2013 14:41:35 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5EACD43F7; Fri, 18 Jan 2013 14:45:01 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Fri, 18 Jan 2013 14:45:01 -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] Eap Applicability: Re-authentication 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, 18 Jan 2013 19:45:05 -0000 So, I was wondering what's up with the EAP applicability draft and why we've not made more progress. I'm kind of glad I didn't ask the question but instead went back to my notes, because I discovered that I dropped the ball. I already put forward some text on retransmission; Jim and Yoshi provided edits and they were happy with that. I don't think Alper was happy with the result; the chairs and editors of EAP applicability will need to resolve who is in the rough there. However, I also promised text on re-authentication. Proposed text: EAP lower layers MAY provide a mechanism for re-authentication to happen within an existing session [RFC 3748]. Diameter standardizes a mechanism fro an AAA server to request re-authentication [RFC 4005]. Re-authentication permits security associations to be updated without establishing a new session. For network access, this can be important because interrupting network access can disrupt connections and media. Some applications might not need re-authentication support. For example if sessions are relatively short-lived or if sessions can be replaced without significant disruption, re-authentication might not provide value. Protocols like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protocol (SMTP) are examples of protocols where establishing a new connection to update security associations is likely to be sufficient. Re-authentication is likely to be valuable if sessions or connections are long-lived or if there is a significant cost to disrupting them. Another factor may make re-authentication important. Some protocols only permit one side of a connection (for example the client) to establish a new connection. If another party in the protocol MAY need the security association refreshed then re-authentication can provide a mechanism to do so. Lower layers SHOULD describe whether re-authentication is provided and which parties can initiate it. From ietf@augustcellars.com Fri Jan 18 15:06:07 2013 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 4DE0F21F86AE for ; Fri, 18 Jan 2013 15:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXvRemNHX6mD for ; Fri, 18 Jan 2013 15:06:06 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06E21F86A2 for ; Fri, 18 Jan 2013 15:06:06 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id DD8A838F1B; Fri, 18 Jan 2013 15:06:05 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Fri, 18 Jan 2013 15:05:42 -0800 Message-ID: <025501cdf5d0$58766810$09633830$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIQJjjvOvgydf4rir7qOHhdZc/27JfLT33Q Content-Language: en-us Subject: Re: [abfab] Eap Applicability: Re-authentication 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, 18 Jan 2013 23:06:07 -0000 Sam, Here are some initial inline comments Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Friday, January 18, 2013 11:45 AM > To: abfab@ietf.org > Subject: [abfab] Eap Applicability: Re-authentication > > > > So, I was wondering what's up with the EAP applicability draft and why we've > not made more progress. I'm kind of glad I didn't ask the question but > instead went back to my notes, because I discovered that I dropped the ball. > I already put forward some text on retransmission; Jim and Yoshi provided > edits and they were happy with that. > I don't think Alper was happy with the result; the chairs and editors of EAP > applicability will need to resolve who is in the rough there. > > However, I also promised text on re-authentication. > > Proposed text: > > EAP lower layers MAY provide a mechanism for re-authentication to happen > within an existing session [RFC 3748]. Diameter standardizes a mechanism fro [JLS] I have problems with talking about the re-authentication happening within an existing session. EAP does not have sessions so you don't re-authenticate inside of an EAP session. You need to clarify what session you are talking about. You should also potentially talk about what a session means, are we talking about cryptographic sessions, application sessions, infrastructure session? s/fro/for/ > an AAA server to request re-authentication [RFC 4005]. Re-authentication > permits security associations to be updated without establishing a new > session. For network access, this can be important because interrupting > network access can disrupt connections and media. > > Some applications might not need re-authentication support. For example if > sessions are relatively short-lived or if sessions can be replaced without > significant disruption, re-authentication might not provide value. Protocols > like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protocol > (SMTP) are examples of protocols where establishing a new connection to s/establishing/re-establishing/ > update security associations is likely to be sufficient. > > Re-authentication is likely to be valuable if sessions or connections are long- > lived or if there is a significant cost to disrupting them. > > Another factor may make re-authentication important. Some protocols only > permit one side of a connection (for example the client) to establish a new s/one side of a connection/one party in the protocol/ > connection. If another party in the protocol MAY need the security [JLS] Suggest killing the MAY. There is not real protocol requirement on this statement - it could never be testable. s/ in the protocol MAY need the/in the protocol needs the/ > association refreshed then re-authentication can provide a mechanism to do > so. > > Lower layers SHOULD describe whether re-authentication is provided and > which parties can initiate it. The EAP applicability statement document should make some type of definition for what a lower layer is. Copying the definition from section 2.2 in 3748 is fine with me. [JLS] The lower lay needs to 1) identify which party(s) can initiate the re-authentication and 2) how to send an appropriate protocol message to that party(s) to request that it initiate re-authentication. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From yoshihiro.ohba@toshiba.co.jp Sun Jan 20 16:53:39 2013 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 2465721F842B for ; Sun, 20 Jan 2013 16:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+P4LP+6xLfK for ; Sun, 20 Jan 2013 16:53:38 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8E321F8427 for ; Sun, 20 Jan 2013 16:53:34 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r0L0rXwd001338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Jan 2013 09:53:33 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r0L0rXgI026745 for ; Mon, 21 Jan 2013 09:53:33 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 330 for ; Mon, 21 Jan 2013 09:53:33 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r0L0rWg8026731 for ; Mon, 21 Jan 2013 09:53:32 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r0L0rWiD029080 for abfab@ietf.org; Mon, 21 Jan 2013 09:53:32 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA29079; Mon, 21 Jan 2013 09:53:32 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r0L0rV5g012573 for ; Mon, 21 Jan 2013 09:53:32 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id r0L0rVPm027807; Mon, 21 Jan 2013 09:53:31 +0900 (JST) Received: from [133.196.20.72] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MGY00JVYAH74850@mail.po.toshiba.co.jp> for abfab@ietf.org; Mon, 21 Jan 2013 09:53:31 +0900 (JST) Date: Mon, 21 Jan 2013 09:53:31 +0900 From: Yoshihiro Ohba In-reply-to: To: abfab@ietf.org Message-id: <50FC918B.3030905@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [abfab] Eap Applicability: Re-authentication 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, 21 Jan 2013 00:53:39 -0000 Sam, I suggested to replace "application" with "lower-layer" in your text and Jim was against my suggestion. To continue the discussion, I asked a question whether GSS EAP token carries a sequence number but it was not answered yet. My point is that GSS-EAP solely cannot be considered as an EAP lower layer unless GSS-EAP itself provides in-order delivery of EAP message. For the same reason, IEEE 802.1X can be considered as an EAP lower-layer only if 802.1X frame is carried over Ethernet or alike media that provides in-order delivery of EAP message. Yoshihiro Ohba (2013/01/19 4:45), Sam Hartman wrote: > > So, I was wondering what's up with the EAP applicability draft and why > we've not made more progress. I'm kind of glad I didn't ask the question > but instead went back to my notes, because I discovered that I dropped > the ball. > I already put forward some text on retransmission; Jim and Yoshi > provided edits and they were happy with that. > I don't think Alper was happy with the result; the chairs and editors of > EAP applicability will need to resolve who is in the rough there. > > However, I also promised text on re-authentication. > > Proposed text: > > EAP lower layers MAY provide a mechanism for re-authentication to happen > within an existing session [RFC 3748]. Diameter standardizes a mechanism > fro an AAA server to request re-authentication [RFC > 4005]. Re-authentication permits security associations to be updated > without establishing a new session. For network access, this can be > important because interrupting network access can disrupt connections > and media. > > Some applications might not need re-authentication support. For example > if sessions are relatively short-lived or if sessions can be replaced > without significant disruption, re-authentication might not provide > value. Protocols like HypertextTransport Protocol (HTTP) and Simple > Mail Transport Protocol (SMTP) are examples of protocols where > establishing a new connection to update security associations is likely > to be sufficient. > > Re-authentication is likely to be valuable if sessions or connections > are long-lived or if there is a significant cost to disrupting them. > > Another factor may make re-authentication important. Some protocols only > permit one side of a connection (for example the client) to establish a > new connection. If another party in the protocol MAY need the security > association refreshed then re-authentication can provide a mechanism to > do so. > > Lower layers SHOULD describe whether re-authentication is provided and > which parties can initiate it. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From ietf@augustcellars.com Mon Jan 21 12:09:22 2013 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 635D121F8583 for ; Mon, 21 Jan 2013 12:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUYpDfLOb1DW for ; Mon, 21 Jan 2013 12:09:21 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7E47621F84DA for ; Mon, 21 Jan 2013 12:09:21 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 592AC38F07; Mon, 21 Jan 2013 12:09:20 -0800 (PST) From: "Jim Schaad" To: "'Yoshihiro Ohba'" , References: <50FC918B.3030905@toshiba.co.jp> In-Reply-To: <50FC918B.3030905@toshiba.co.jp> Date: Mon, 21 Jan 2013 12:08:57 -0800 Message-ID: <032701cdf813$26416760$72c43620$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIQJjjvOvgydf4rir7qOHhdZc/27AF6dCHYl8QD5JA= Content-Language: en-us Subject: Re: [abfab] Eap Applicability: Re-authentication 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, 21 Jan 2013 20:09:22 -0000 I don't think we have suggested that GSS-EAP is the "lower -layer", nor is it the "application". GSS-EAP states that the "application" is responsible for doing in order delivery for during the initialization. Let us consider the case of SSH using GSS-EAP for authentication. One could run SSH over UDP, TCP, DTLS/UDP, TLS/TCP. In these cases SSH, the "application", would need to have code to deal with in order delivery with UDP, however TCP, DTLS/UDP and TLS/TCP themselves all satisfy the in order requirements. Many of the things that we are talking about however are based on SSH, how does it deal with re-authentication being one of those things. One does not expect TCP to know anything about the process of asking for and dealing with re-authentication, but SSH is the proper layer to talk about this. In this working group we are focused on applications not lower-layers. We need to tell applications what they need to do (one of which is to figure out how to get in order delivery somehow) and not confuse the issue between what is an application as oppose to making them think about lower-layers instead (which are maybe different). Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Yoshihiro Ohba > Sent: Sunday, January 20, 2013 4:54 PM > To: abfab@ietf.org > Subject: Re: [abfab] Eap Applicability: Re-authentication > > Sam, > > I suggested to replace "application" with "lower-layer" in your text and Jim > was against my suggestion. To continue the discussion, I asked a question > whether GSS EAP token carries a sequence number but it was not > answered yet. My point is that GSS-EAP solely cannot be considered as > an EAP lower layer unless GSS-EAP itself provides in-order delivery of EAP > message. For the same reason, IEEE 802.1X can be considered as an EAP > lower-layer only if 802.1X frame is carried over Ethernet or alike media that > provides in-order delivery of EAP message. > > Yoshihiro Ohba > > > (2013/01/19 4:45), Sam Hartman wrote: > > > > So, I was wondering what's up with the EAP applicability draft and why > > we've not made more progress. I'm kind of glad I didn't ask the > > question but instead went back to my notes, because I discovered that > > I dropped the ball. > > I already put forward some text on retransmission; Jim and Yoshi > > provided edits and they were happy with that. > > I don't think Alper was happy with the result; the chairs and editors > > of EAP applicability will need to resolve who is in the rough there. > > > > However, I also promised text on re-authentication. > > > > Proposed text: > > > > EAP lower layers MAY provide a mechanism for re-authentication to > > happen within an existing session [RFC 3748]. Diameter standardizes a > > mechanism fro an AAA server to request re-authentication [RFC 4005]. > > Re-authentication permits security associations to be updated without > > establishing a new session. For network access, this can be important > > because interrupting network access can disrupt connections and media. > > > > Some applications might not need re-authentication support. For > > example if sessions are relatively short-lived or if sessions can be > > replaced without significant disruption, re-authentication might not > > provide value. Protocols like HypertextTransport Protocol (HTTP) and > > Simple Mail Transport Protocol (SMTP) are examples of protocols where > > establishing a new connection to update security associations is > > likely to be sufficient. > > > > Re-authentication is likely to be valuable if sessions or connections > > are long-lived or if there is a significant cost to disrupting them. > > > > Another factor may make re-authentication important. Some protocols > > only permit one side of a connection (for example the client) to > > establish a new connection. If another party in the protocol MAY need > > the security association refreshed then re-authentication can provide > > a mechanism to do so. > > > > Lower layers SHOULD describe whether re-authentication is provided and > > which parties can initiate it. > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab > > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From yoshihiro.ohba@toshiba.co.jp Mon Jan 21 16:20:00 2013 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 EBB0721F8460 for ; Mon, 21 Jan 2013 16:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4NNNMDGrOSz for ; Mon, 21 Jan 2013 16:20:00 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0556521F845E for ; Mon, 21 Jan 2013 16:19:59 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r0M0JsB7020840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2013 09:19:55 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r0M0JsBV023394; Tue, 22 Jan 2013 09:19:54 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 710; Tue, 22 Jan 2013 09:19:54 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r0M0JsKD023391; Tue, 22 Jan 2013 09:19:54 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r0M0JsGM011433; Tue, 22 Jan 2013 09:19:54 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA11431; Tue, 22 Jan 2013 09:19:54 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r0M0Js7H028795; Tue, 22 Jan 2013 09:19:54 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id r0M0Jrnh019019; Tue, 22 Jan 2013 09:19:53 +0900 (JST) Received: from [133.196.20.72] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MH0002AW3L5AQ90@mail.po.toshiba.co.jp>; Tue, 22 Jan 2013 09:19:53 +0900 (JST) Date: Tue, 22 Jan 2013 09:19:54 +0900 From: Yoshihiro Ohba In-reply-to: <032701cdf813$26416760$72c43620$@augustcellars.com> To: Jim Schaad Message-id: <50FDDB2A.3050606@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50FC918B.3030905@toshiba.co.jp> <032701cdf813$26416760$72c43620$@augustcellars.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Eap Applicability: Re-authentication 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: Tue, 22 Jan 2013 00:20:01 -0000 Just to clarify that my comment was about "Retransmission Text for EAP applicability" that is discussed in another thread. Please see my comment below. (2013/01/22 5:08), Jim Schaad wrote: > I don't think we have suggested that GSS-EAP is the "lower -layer", nor is > it the "application". GSS-EAP states that the "application" is > responsible for doing in order delivery for during the initialization. This simply means that application is part of EAP lower-layer, as oppose to your previous statement you made in Nov 19, 2012: "However this does not change my opinion that application protocol that is using GSS-API is not part of the EAP lower-level." We need to first mention in EAP applicability is that a GSS-EAP application is part of EAP lower-layer and needs to follow the EAP lower-layer requirements. Then, we can further have detailed text on retransmission and message discarding behavior as suggested by Sam, but I still suggest replacing "application" with "lower-layer" in there, because technically there is nothing specific to applications. Regards, Yoshihiro Ohba > Let us consider the case of SSH using GSS-EAP for authentication. One could > run SSH over UDP, TCP, DTLS/UDP, TLS/TCP. In these cases SSH, the > "application", would need to have code to deal with in order delivery with > UDP, however TCP, DTLS/UDP and TLS/TCP themselves all satisfy the in order > requirements. > > Many of the things that we are talking about however are based on SSH, how > does it deal with re-authentication being one of those things. One does not > expect TCP to know anything about the process of asking for and dealing with > re-authentication, but SSH is the proper layer to talk about this. > > In this working group we are focused on applications not lower-layers. We > need to tell applications what they need to do (one of which is to figure > out how to get in order delivery somehow) and not confuse the issue between > what is an application as oppose to making them think about lower-layers > instead (which are maybe different). > > Jim > > >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf >> Of Yoshihiro Ohba >> Sent: Sunday, January 20, 2013 4:54 PM >> To: abfab@ietf.org >> Subject: Re: [abfab] Eap Applicability: Re-authentication >> >> Sam, >> >> I suggested to replace "application" with "lower-layer" in your text and > Jim >> was against my suggestion. To continue the discussion, I asked a question >> whether GSS EAP token carries a sequence number but it was not >> answered yet. My point is that GSS-EAP solely cannot be considered as >> an EAP lower layer unless GSS-EAP itself provides in-order delivery of EAP >> message. For the same reason, IEEE 802.1X can be considered as an EAP >> lower-layer only if 802.1X frame is carried over Ethernet or alike media > that >> provides in-order delivery of EAP message. >> >> Yoshihiro Ohba >> >> >> (2013/01/19 4:45), Sam Hartman wrote: >>> So, I was wondering what's up with the EAP applicability draft and why >>> we've not made more progress. I'm kind of glad I didn't ask the >>> question but instead went back to my notes, because I discovered that >>> I dropped the ball. >>> I already put forward some text on retransmission; Jim and Yoshi >>> provided edits and they were happy with that. >>> I don't think Alper was happy with the result; the chairs and editors >>> of EAP applicability will need to resolve who is in the rough there. >>> >>> However, I also promised text on re-authentication. >>> >>> Proposed text: >>> >>> EAP lower layers MAY provide a mechanism for re-authentication to >>> happen within an existing session [RFC 3748]. Diameter standardizes a >>> mechanism fro an AAA server to request re-authentication [RFC 4005]. >>> Re-authentication permits security associations to be updated without >>> establishing a new session. For network access, this can be important >>> because interrupting network access can disrupt connections and media. >>> >>> Some applications might not need re-authentication support. For >>> example if sessions are relatively short-lived or if sessions can be >>> replaced without significant disruption, re-authentication might not >>> provide value. Protocols like HypertextTransport Protocol (HTTP) and >>> Simple Mail Transport Protocol (SMTP) are examples of protocols where >>> establishing a new connection to update security associations is >>> likely to be sufficient. >>> >>> Re-authentication is likely to be valuable if sessions or connections >>> are long-lived or if there is a significant cost to disrupting them. >>> >>> Another factor may make re-authentication important. Some protocols >>> only permit one side of a connection (for example the client) to >>> establish a new connection. If another party in the protocol MAY need >>> the security association refreshed then re-authentication can provide >>> a mechanism to do so. >>> >>> Lower layers SHOULD describe whether re-authentication is provided and >>> which parties can initiate it. >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >>> >> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > From ietf@augustcellars.com Mon Jan 21 16:47:01 2013 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 4F68021F8750 for ; Mon, 21 Jan 2013 16:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVPSG2hdXgpZ for ; Mon, 21 Jan 2013 16:47:00 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 71C4B21F874F for ; Mon, 21 Jan 2013 16:47:00 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id BF55838EF3; Mon, 21 Jan 2013 16:46:59 -0800 (PST) From: "Jim Schaad" To: "'Yoshihiro Ohba'" References: <50FC918B.3030905@toshiba.co.jp> <032701cdf813$26416760$72c43620$@augustcellars.com> <50FDDB2A.3050606@toshiba.co.jp> In-Reply-To: <50FDDB2A.3050606@toshiba.co.jp> Date: Mon, 21 Jan 2013 16:46:36 -0800 Message-ID: <033201cdf839$eff9eb10$cfedc130$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIQJjjvOvgydf4rir7qOHhdZc/27AF6dCHYAdIDkqQBqxhiJJeoasfw Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Eap Applicability: Re-authentication 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: Tue, 22 Jan 2013 00:47:01 -0000 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp] > Sent: Monday, January 21, 2013 4:20 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Eap Applicability: Re-authentication > > Just to clarify that my comment was about "Retransmission Text for EAP > applicability" that is discussed in another thread. > > Please see my comment below. > > (2013/01/22 5:08), Jim Schaad wrote: > > I don't think we have suggested that GSS-EAP is the "lower -layer", nor is > > it the "application". GSS-EAP states that the "application" is > > responsible for doing in order delivery for during the initialization. > > This simply means that application is part of EAP lower-layer, as oppose to > your previous statement you made in Nov 19, 2012: "However this does not > change my opinion that application protocol that is using GSS-API is not part > of the EAP lower-level." No - I think the EAP lower-level is part of the application. Jim > > We need to first mention in EAP applicability is that a GSS-EAP application is > part of EAP lower-layer and needs to follow the EAP lower-layer > requirements. > > Then, we can further have detailed text on retransmission and message > discarding behavior as suggested by Sam, but I still suggest replacing > "application" with "lower-layer" in there, because technically there is nothing > specific to applications. > > Regards, > Yoshihiro Ohba > > > Let us consider the case of SSH using GSS-EAP for authentication. One > > could run SSH over UDP, TCP, DTLS/UDP, TLS/TCP. In these cases SSH, > > the "application", would need to have code to deal with in order > > delivery with UDP, however TCP, DTLS/UDP and TLS/TCP themselves all > > satisfy the in order requirements. > > > > Many of the things that we are talking about however are based on SSH, > > how does it deal with re-authentication being one of those things. > > One does not expect TCP to know anything about the process of asking > > for and dealing with re-authentication, but SSH is the proper layer to talk > about this. > > > > In this working group we are focused on applications not lower-layers. > > We need to tell applications what they need to do (one of which is to > > figure out how to get in order delivery somehow) and not confuse the > > issue between what is an application as oppose to making them think > > about lower-layers instead (which are maybe different). > > > > Jim > > > > > >> -----Original Message----- > >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On > >> Behalf Of Yoshihiro Ohba > >> Sent: Sunday, January 20, 2013 4:54 PM > >> To: abfab@ietf.org > >> Subject: Re: [abfab] Eap Applicability: Re-authentication > >> > >> Sam, > >> > >> I suggested to replace "application" with "lower-layer" in your text > >> and > > Jim > >> was against my suggestion. To continue the discussion, I asked a > >> question whether GSS EAP token carries a sequence number but it was > not > >> answered yet. My point is that GSS-EAP solely cannot be considered as > >> an EAP lower layer unless GSS-EAP itself provides in-order delivery > >> of EAP message. For the same reason, IEEE 802.1X can be considered > >> as an EAP lower-layer only if 802.1X frame is carried over Ethernet > >> or alike media > > that > >> provides in-order delivery of EAP message. > >> > >> Yoshihiro Ohba > >> > >> > >> (2013/01/19 4:45), Sam Hartman wrote: > >>> So, I was wondering what's up with the EAP applicability draft and > >>> why we've not made more progress. I'm kind of glad I didn't ask the > >>> question but instead went back to my notes, because I discovered > >>> that I dropped the ball. > >>> I already put forward some text on retransmission; Jim and Yoshi > >>> provided edits and they were happy with that. > >>> I don't think Alper was happy with the result; the chairs and > >>> editors of EAP applicability will need to resolve who is in the rough there. > >>> > >>> However, I also promised text on re-authentication. > >>> > >>> Proposed text: > >>> > >>> EAP lower layers MAY provide a mechanism for re-authentication to > >>> happen within an existing session [RFC 3748]. Diameter standardizes > >>> a mechanism fro an AAA server to request re-authentication [RFC 4005]. > >>> Re-authentication permits security associations to be updated > >>> without establishing a new session. For network access, this can be > >>> important because interrupting network access can disrupt connections > and media. > >>> > >>> Some applications might not need re-authentication support. For > >>> example if sessions are relatively short-lived or if sessions can be > >>> replaced without significant disruption, re-authentication might not > >>> provide value. Protocols like HypertextTransport Protocol (HTTP) and > >>> Simple Mail Transport Protocol (SMTP) are examples of protocols > >>> where establishing a new connection to update security associations > >>> is likely to be sufficient. > >>> > >>> Re-authentication is likely to be valuable if sessions or > >>> connections are long-lived or if there is a significant cost to disrupting > them. > >>> > >>> Another factor may make re-authentication important. Some protocols > >>> only permit one side of a connection (for example the client) to > >>> establish a new connection. If another party in the protocol MAY > >>> need the security association refreshed then re-authentication can > >>> provide a mechanism to do so. > >>> > >>> Lower layers SHOULD describe whether re-authentication is provided > >>> and which parties can initiate it. > >>> _______________________________________________ > >>> abfab mailing list > >>> abfab@ietf.org > >>> https://www.ietf.org/mailman/listinfo/abfab > >>> > >> > >> _______________________________________________ > >> abfab mailing list > >> abfab@ietf.org > >> https://www.ietf.org/mailman/listinfo/abfab > > From yoshihiro.ohba@toshiba.co.jp Mon Jan 21 16:51:20 2013 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 EA3C221F881C for ; Mon, 21 Jan 2013 16:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jevdt0iNcVeg for ; Mon, 21 Jan 2013 16:51:20 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id CD98F21F8818 for ; Mon, 21 Jan 2013 16:51:19 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r0M0pI72005608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Jan 2013 09:51:18 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r0M0pISn026138 for ; Tue, 22 Jan 2013 09:51:18 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 1002 for ; Tue, 22 Jan 2013 09:51:18 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r0M0pIFE026129 for ; Tue, 22 Jan 2013 09:51:18 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r0M0pIEu012132 for abfab@ietf.org; Tue, 22 Jan 2013 09:51:18 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA12127; Tue, 22 Jan 2013 09:51:18 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r0M0pHeV015635 for ; Tue, 22 Jan 2013 09:51:17 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id r0M0pHDQ004093; Tue, 22 Jan 2013 09:51:17 +0900 (JST) Received: from [133.196.20.72] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MH0002BO51GATC0@mail.po.toshiba.co.jp> for abfab@ietf.org; Tue, 22 Jan 2013 09:51:17 +0900 (JST) Date: Tue, 22 Jan 2013 09:51:17 +0900 From: Yoshihiro Ohba In-reply-to: To: abfab@ietf.org Message-id: <50FDE285.2010300@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [abfab] Eap Applicability: Re-authentication 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: Tue, 22 Jan 2013 00:51:21 -0000 I have a few comments on re-authentication text. Please see below. (2013/01/19 4:45), Sam Hartman wrote: > > Proposed text: > > EAP lower layers MAY provide a mechanism for re-authentication to happen > within an existing session [RFC 3748]. Diameter standardizes a mechanism > fro an AAA server to request re-authentication [RFC > 4005]. Re-authentication permits security associations to be updated > without establishing a new session. For network access, this can be > important because interrupting network access can disrupt connections > and media. > > Some applications might not need re-authentication support. For example I suggest: s/Some applications/Some EAP lower layers/. > if sessions are relatively short-lived or if sessions can be replaced > without significant disruption, re-authentication might not provide > value. Protocols like HypertextTransport Protocol (HTTP) and Simple > Mail Transport Protocol (SMTP) are examples of protocols where > establishing a new connection to update security associations is likely > to be sufficient. Does HTTP support GSS-API? If not, I suggest to remove HTTP from the text as we are discussing EAP re-authentication. We should also add text to mention that SMTP with GSS-EAP is considered as EAP lower-layer. Yoshihiro Ohba > > Re-authentication is likely to be valuable if sessions or connections > are long-lived or if there is a significant cost to disrupting them. > > Another factor may make re-authentication important. Some protocols only > permit one side of a connection (for example the client) to establish a > new connection. If another party in the protocol MAY need the security > association refreshed then re-authentication can provide a mechanism to > do so. > > Lower layers SHOULD describe whether re-authentication is provided and > which parties can initiate it. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From yoshihiro.ohba@toshiba.co.jp Mon Jan 21 17:01:10 2013 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 8FEF921F8750 for ; Mon, 21 Jan 2013 17:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.939 X-Spam-Level: X-Spam-Status: No, score=-3.939 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs2FfEazVyW4 for ; Mon, 21 Jan 2013 17:01:09 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 928D011E8097 for ; Mon, 21 Jan 2013 17:01:09 -0800 (PST) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r0M10cOM010017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2013 10:00:39 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r0M10cxM013972; Tue, 22 Jan 2013 10:00:38 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 987; Tue, 22 Jan 2013 10:00:38 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r0M10ct3013966; Tue, 22 Jan 2013 10:00:38 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r0M10ctp021767; Tue, 22 Jan 2013 10:00:38 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id LAA21764; Tue, 22 Jan 2013 10:00:38 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r0M10cDJ020577; Tue, 22 Jan 2013 10:00:38 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id r0M10ckO017368; Tue, 22 Jan 2013 10:00:38 +0900 (JST) Received: from [133.196.20.72] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MH0002HT5H1ATC0@mail.po.toshiba.co.jp>; Tue, 22 Jan 2013 10:00:37 +0900 (JST) Date: Tue, 22 Jan 2013 10:00:38 +0900 From: Yoshihiro Ohba In-reply-to: <033201cdf839$eff9eb10$cfedc130$@augustcellars.com> To: Jim Schaad Message-id: <50FDE4B6.1070703@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50FC918B.3030905@toshiba.co.jp> <032701cdf813$26416760$72c43620$@augustcellars.com> <50FDDB2A.3050606@toshiba.co.jp> <033201cdf839$eff9eb10$cfedc130$@augustcellars.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Eap Applicability: Re-authentication 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: Tue, 22 Jan 2013 01:01:10 -0000 (2013/01/22 9:46), Jim Schaad wrote: > No - I think the EAP lower-level is part of the application. I don't think it's an accurate description. In the case where an appplication relies on reliable transport (e.g. TCP) for in-order message delivery, the EAP lower-layer spans both the application and the reliable transport. Yoshihiro Ohba > Jim > >> We need to first mention in EAP applicability is that a GSS-EAP > application is >> part of EAP lower-layer and needs to follow the EAP lower-layer >> requirements. >> >> Then, we can further have detailed text on retransmission and message >> discarding behavior as suggested by Sam, but I still suggest replacing >> "application" with "lower-layer" in there, because technically there is > nothing >> specific to applications. >> >> Regards, >> Yoshihiro Ohba >> >>> Let us consider the case of SSH using GSS-EAP for authentication. One >>> could run SSH over UDP, TCP, DTLS/UDP, TLS/TCP. In these cases SSH, >>> the "application", would need to have code to deal with in order >>> delivery with UDP, however TCP, DTLS/UDP and TLS/TCP themselves all >>> satisfy the in order requirements. >>> >>> Many of the things that we are talking about however are based on SSH, >>> how does it deal with re-authentication being one of those things. >>> One does not expect TCP to know anything about the process of asking >>> for and dealing with re-authentication, but SSH is the proper layer to > talk >> about this. >>> In this working group we are focused on applications not lower-layers. >>> We need to tell applications what they need to do (one of which is to >>> figure out how to get in order delivery somehow) and not confuse the >>> issue between what is an application as oppose to making them think >>> about lower-layers instead (which are maybe different). >>> >>> Jim >>> >>> >>>> -----Original Message----- >>>> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On >>>> Behalf Of Yoshihiro Ohba >>>> Sent: Sunday, January 20, 2013 4:54 PM >>>> To: abfab@ietf.org >>>> Subject: Re: [abfab] Eap Applicability: Re-authentication >>>> >>>> Sam, >>>> >>>> I suggested to replace "application" with "lower-layer" in your text >>>> and >>> Jim >>>> was against my suggestion. To continue the discussion, I asked a >>>> question whether GSS EAP token carries a sequence number but it was >> not >>>> answered yet. My point is that GSS-EAP solely cannot be considered as >>>> an EAP lower layer unless GSS-EAP itself provides in-order delivery >>>> of EAP message. For the same reason, IEEE 802.1X can be considered >>>> as an EAP lower-layer only if 802.1X frame is carried over Ethernet >>>> or alike media >>> that >>>> provides in-order delivery of EAP message. >>>> >>>> Yoshihiro Ohba >>>> >>>> >>>> (2013/01/19 4:45), Sam Hartman wrote: >>>>> So, I was wondering what's up with the EAP applicability draft and >>>>> why we've not made more progress. I'm kind of glad I didn't ask the >>>>> question but instead went back to my notes, because I discovered >>>>> that I dropped the ball. >>>>> I already put forward some text on retransmission; Jim and Yoshi >>>>> provided edits and they were happy with that. >>>>> I don't think Alper was happy with the result; the chairs and >>>>> editors of EAP applicability will need to resolve who is in the rough > there. >>>>> However, I also promised text on re-authentication. >>>>> >>>>> Proposed text: >>>>> >>>>> EAP lower layers MAY provide a mechanism for re-authentication to >>>>> happen within an existing session [RFC 3748]. Diameter standardizes >>>>> a mechanism fro an AAA server to request re-authentication [RFC 4005]. >>>>> Re-authentication permits security associations to be updated >>>>> without establishing a new session. For network access, this can be >>>>> important because interrupting network access can disrupt connections >> and media. >>>>> Some applications might not need re-authentication support. For >>>>> example if sessions are relatively short-lived or if sessions can be >>>>> replaced without significant disruption, re-authentication might not >>>>> provide value. Protocols like HypertextTransport Protocol (HTTP) and >>>>> Simple Mail Transport Protocol (SMTP) are examples of protocols >>>>> where establishing a new connection to update security associations >>>>> is likely to be sufficient. >>>>> >>>>> Re-authentication is likely to be valuable if sessions or >>>>> connections are long-lived or if there is a significant cost to > disrupting >> them. >>>>> Another factor may make re-authentication important. Some protocols >>>>> only permit one side of a connection (for example the client) to >>>>> establish a new connection. If another party in the protocol MAY >>>>> need the security association refreshed then re-authentication can >>>>> provide a mechanism to do so. >>>>> >>>>> Lower layers SHOULD describe whether re-authentication is provided >>>>> and which parties can initiate it. >>>>> _______________________________________________ >>>>> abfab mailing list >>>>> abfab@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/abfab >>>>> >>>> _______________________________________________ >>>> abfab mailing list >>>> abfab@ietf.org >>>> https://www.ietf.org/mailman/listinfo/abfab > > From alex@um.es Thu Jan 24 01:53:05 2013 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 5C8AA21F847B; Thu, 24 Jan 2013 01:53:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sfc2RJwjZSVp; Thu, 24 Jan 2013 01:53:04 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6D521F8476; Thu, 24 Jan 2013 01:53:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 0A326536FD; Thu, 24 Jan 2013 10:53:03 +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 0PrYkMoGtvtm; Thu, 24 Jan 2013 10:53:02 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 2D56C536FB; Thu, 24 Jan 2013 10:53:01 +0100 (CET) Message-ID: <5101047D.20103@um.es> Date: Thu, 24 Jan 2013 10:53:01 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: "radext@ietf.org" References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> In-Reply-To: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000103030703090803090109" Cc: "abfab@ietf.org" Subject: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 24 Jan 2013 09:53:05 -0000 This is a multi-part message in MIME format. --------------000103030703090803090109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, we have uploaded a new version of our RADIUS fragmentation draft. This version introduces some relevant changes: * Improved description of fragmentation of Access-Accept packets. * Use of Additional-Authorization service type instead of Authorize-Only * Improved description of CHUNK size calculation. * New section describing how to deal with Proxy-State attributes, including the mechanism used by the RADIUS client to discover the amount of space required for them along the path (also includes the description of a new RADIUS Attribute for that purpose). * Improved description of the management of State attributes. * New section about the interaction with RADIUS-EAP. * New section describing in detail how to rebuild a received fragmented packet. Regards, Alejandro -------- Mensaje original -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-04.txt Fecha: Thu, 24 Jan 2013 01:49:03 -0800 De: internet-drafts@ietf.org Para: alex@um.es CC: aland@networkradius.com, gabilm@um.es, diego@tid.es, pereniguez@um.es, rafa@um.es A new version of I-D, draft-perez-radext-radius-fragmentation-04.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 04 Title: Support of fragmentation of RADIUS packets Creation date: 2013-01-24 WG ID: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-04.txt Status: http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation Htmlized: http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-04 Abstract: This document describes a mechanism providing fragmentation support of RADIUS packets that exceed the 4 KB limit. The IETF Secretariat --------------000103030703090803090109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

we have uploaded a new version of our RADIUS fragmentation draft. This version introduces some relevant changes:
  • Improved description of fragmentation of Access-Accept packets.
  • Use of Additional-Authorization service type instead of Authorize-Only
  • Improved description of CHUNK size calculation.
  • New section describing how to deal with Proxy-State attributes, including the mechanism used by the RADIUS client to discover the amount of space required for them along the path (also includes the description of a new RADIUS Attribute for that purpose).
  • Improved description of the management of State attributes.
  • New section about the interaction with RADIUS-EAP.
  • New section describing in detail how to rebuild a received fragmented packet.
Regards,
Alejandro


-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-04.txt
Fecha: Thu, 24 Jan 2013 01:49:03 -0800
De: internet-drafts@ietf.org
Para: alex@um.es
CC: aland@networkradius.com, gabilm@um.es, diego@tid.es, pereniguez@um.es, rafa@um.es 


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

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 04
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-01-24
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-04.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-04

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4 KB limit.

                                                                                  


The IETF Secretariat


--------------000103030703090803090109-- From hartmans@painless-security.com Thu Jan 24 07:40:30 2013 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 1DA2321F87A3; Thu, 24 Jan 2013 07:40:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsE-coaB8nI3; Thu, 24 Jan 2013 07:40:29 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51B21F873D; Thu, 24 Jan 2013 07:40:29 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id D1AA92026F; Thu, 24 Jan 2013 10:36:47 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2B30B43FD; Thu, 24 Jan 2013 10:40:27 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> Date: Thu, 24 Jan 2013 10:40:27 -0500 In-Reply-To: <5101047D.20103@um.es> (Alejandro Perez Mendez's message of "Thu, 24 Jan 2013 10:53:01 +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: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 24 Jan 2013 15:40:30 -0000 This sounds great. What's the state within radext? I know it's now chartered; how can we help get this adopted? From aland@deployingradius.com Thu Jan 24 07:51:40 2013 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 6966321F88EE; Thu, 24 Jan 2013 07:51:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXhala9WstEY; Thu, 24 Jan 2013 07:51:36 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3989C21F8868; Thu, 24 Jan 2013 07:51:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id B3C402241106; Thu, 24 Jan 2013 16:50:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9gsYu7VFzJD; Thu, 24 Jan 2013 16:50:48 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 6DB752241069; Thu, 24 Jan 2013 16:50:48 +0100 (CET) Message-ID: <51015859.4010008@deployingradius.com> Date: Thu, 24 Jan 2013 10:50:49 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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-04.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, 24 Jan 2013 15:51:40 -0000 Sam Hartman wrote: > This sounds great. > What's the state within radext? > I know it's now chartered; how can we help get this adopted? Pipe up in radext. It's on the RADEXT charter now. So we'll need reviewers, and a call for WG adoption. Alan DeKok. From diego@tid.es Thu Jan 24 15:37:34 2013 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 B92EA11E8099; Thu, 24 Jan 2013 15:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.338 X-Spam-Level: X-Spam-Status: No, score=-4.338 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_XBL=3.033] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS5rVkSFi7U3; Thu, 24 Jan 2013 15:37:34 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id C4AB321F8BD0; Thu, 24 Jan 2013 15:37:27 -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 <0MH5009KTLLW2C@tid.hi.inet>; Fri, 25 Jan 2013 00:37:25 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 90.16.02896.4B5C1015; Fri, 25 Jan 2013 00:37:25 +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 <0MH5009MQLMC2C@tid.hi.inet>; Fri, 25 Jan 2013 00:37:24 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0328.009; Fri, 25 Jan 2013 00:37:24 +0100 Date: Thu, 24 Jan 2013 23:37:24 +0000 From: "Diego R. Lopez" In-reply-to: <51015859.4010008@deployingradius.com> X-Originating-IP: [10.95.64.115] To: Alan DeKok Message-id: Content-id: <95B96DAD44F38D4D8F8C3A4D1E302CBC@hi.inet> 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: [abfab] [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-04.txt Thread-index: AQHN+krqQs18zK84tUOgrlXG2ixR0ZhZEiuA X-AuditID: 0a5f4e69-b7f636d000000b50-d6-5101c5b4f346 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsXCFe9nqLv1KGOgwfFbLBYfr79htGh5NZPN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZc3cbFtzirTg+7SxbA+Ma3i5GDg4JAROJVVOzuxg5 gUwxiQv31rN1MXJxCAlsY5T4u/8WE4TzlFGif8IpFghnJqPEg62rGUFaWARUJT49mscGYrMB 2Y+af7OD2MICBRKHF3eygticAsYSW9ddY4JYoSDx59xjFhBbREBLYsH6RWA2s0CVRO+5E2D1 vALeEs9WvmGEiJtJnJg+nx0iLijxY/I9FpCrmQXUJaZMyYUoEZdobr0JNUZRYtqiBrBWRqBv vp9awwSxqlDi5q1mdgjbSGJF42c2iHMEJJbsOc8MYYtKvHz8D+wEIYG5jBIt51kmMErMQnLF LCRXzEK4YhaSK2YhuWIBI+sqRrHipKLM9IyS3MTMnHQDI72MTL3MvNSSTYyQ2Mvcwbh8p8oh RgEORiUe3oo7/wOEWBPLiitzDzFKcjApifJu28cYKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE 1yUCKMebklhZlVqUD5OS4eBQkuBdegQoJViUmp5akZaZA0wwMGkmDk6Qdh6QdpAa3uKCxNzi zHSI/ClGSSlx3u0gCQGQREZpHlzvK0ZxoCOFebtBsjzAVAjX9QpoIBPQwP2zgM7nLS5JREhJ NTCG19rPVxRc+yNlj234DRvDm5Y/JNSqsgXcs4JqvIzittzIr2rRuLlv272KdnF3rwJxSZXf Od9vdepXx5xK27/KU3rl/90BAjknOLXU/351+ZVTxtzY4KxjsOlUONMc++UB9c4On3M3f4jN 2pIwZerrnzbromcxS1pv+xB3o35VxqJuzfjoxUosxRmJhlrMRcWJANp8GB9CAwAA References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <51015859.4010008@deployingradius.com> Cc: "abfab@ietf.org" , "radext@ietf.org" Subject: Re: [abfab] [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 24 Jan 2013 23:37:34 -0000 DQpPbiAyNCBKYW4gMjAxMywgYXQgMTY6NTAgLCBBbGFuIERlS29rIHdyb3RlOg0KDQo+IFNhbSBI YXJ0bWFuIHdyb3RlOg0KPj4gVGhpcyBzb3VuZHMgZ3JlYXQuDQo+PiBXaGF0J3MgdGhlIHN0YXRl IHdpdGhpbiByYWRleHQ/DQo+PiBJIGtub3cgaXQncyBub3cgY2hhcnRlcmVkOyBob3cgY2FuIHdl IGhlbHAgZ2V0IHRoaXMgYWRvcHRlZD8NCj4NCj4gIFBpcGUgdXAgaW4gcmFkZXh0LiAgSXQncyBv biB0aGUgUkFERVhUIGNoYXJ0ZXIgbm93LiAgU28gd2UnbGwgbmVlZA0KPiByZXZpZXdlcnMsIGFu ZCBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uLg0KPg0KQXQgdGhlIGxhc3QgUkFERVhUIG1lZXRpbmcg dGhlIGNhbGwgZm9yIHJldmlld2VycyB3YXMgbWFkZSwgdHdvIHJldmlld2Vycw0KaWRlbnRpZmll ZCAoQWxleCBoYXMgY29udGFjdGVkIHRoZW0gb25jZSB0aGUgbGF0ZXN0IHZlcnNpb24gd2FzIGF2 YWlsYWJsZSkNCnNvIFdHIGFkb3B0aW9uIHNob3VsZCBiZSBjbG9zZS4NCg0KQlRXLCB0aGUgaW1w bGVtZW50YXRpb24gb2YgYSBQb0MgaXMgZmluaXNoZWQgYW5kIHdlIGFyZSBkaXNjdXNzaW5nIGhv dw0KdG8gbWFrZSBhIGRlbW8gb2YgaXQgYW55dGltZSBzb29uIChzb3JyeSBmb3IgdGhlIHNwb2ls ZXIsIHlvdSBVTVUgZ3V5cykNCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFy ZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJ K0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRp ZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZh bWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGlj YSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5s YWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNp dmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9u IHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VT L1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From rafa@um.es Tue Jan 29 08:05:31 2013 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 77A7C21F8936; Tue, 29 Jan 2013 08:05:31 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgyf9M0PPq9m; Tue, 29 Jan 2013 08:05:30 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id DD2DA21F890F; Tue, 29 Jan 2013 08:05:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 697CE53657; Tue, 29 Jan 2013 17:05:21 +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 hgXQB-2okM9u; Tue, 29 Jan 2013 17:05:21 +0100 (CET) Received: from inf-205-80.inf.um.es (inf-205-80.inf.um.es [155.54.205.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id 8C144536D6; Tue, 29 Jan 2013 17:05:19 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Rafa Marin Lopez In-Reply-To: <5101047D.20103@um.es> Date: Tue, 29 Jan 2013 17:05:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> To: radext@ietf.org, abfab@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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: Tue, 29 Jan 2013 16:05:31 -0000 Dear all, we have received additional comments from Yoshihiro Ohba (many thanks) = that we share with you.=20 Please, see some comments inline. "Here is my review of draft-perez-radext-radius-fragmentation-04. Section 1: "Each RADIUS packet can transport several RADIUS attributes, to convey the necessary information to the other peer, up to a maximum size of 4 KB of total data (including RADIUS packet headers)." [YO] I suggest to replace "4 KB" with "4096 bytes" throughout the document since "KB" can mean 4000 bytes in some cases. [Rafa] OK. "A reference-based mechanism is also proposed in [RFC6158], where attributes can be obtained through an out-of-band protocol." [YO} Meaning of this sentence is unclear. Does this mean RADIUS attributes are obtained through some other protocol instead of RADIUS? Or does this mean the actual format of the Value field of a RADIUS Attribute is defined in other protocol specification? In the latter case, it should be also mentioned that RADIUS-EAP is categorized as the mechanism defined in RFC 6158. [Rafa] It is referring the value of the attributes can be obtained by = other protocol instead of RADIUS. This is coming from a previous comment = related with SAML transport. Instead of transporting the real SAML = messages an URL is set as attribute value. We can try to clarify a = little bit more. "However, there are no proposals to deal with fragmentation at a packet level, when the total size exceeds the 4 KB limit imposed by the RADIUS specification." [YO] Meaning of "at a packet level" is unclear. Suggested change: "However, there are no proposals to fragement a large-sized RADIUS packet into multiple small-sized RADIUS packets, where the length of the original (unfragmented) RADIUS packet exceeds the 4096-octet limit imposed by the RADIUS specification." [Rafa] This sounds good. Section 2: [YO] I am not sure if "T" flag is needed. In other words, it should be possible to change [I-D.ietf-radext-radius-extensions] to simply allow a fragment with the M-flag cleared not to be included in a non-last chunk. [Rafa]=20 Yes, that may be possible. It is worth noting that we wanted to keep = unmodified any existing I-D by the time being. Moreover, = [I-D.ietf-radext-radius-extensions] has not considered that = fragmentation at packet level may occur for obvious reasons. Moreover, = that I-D is in a mature state now. In any case, we may ask authors of [I-D.ietf-radext-radius-extensions]. Section 3.3: [YO] Access-Accept fragmentation scheme looks odd compared to Access-Request and Access-Challenge fragmentation schemes. There are several questions related to this: (1) Why multiple chunks of Access-Accept cannot be sent without having an Access-Challange to be sent in between? (2) Why an Access-Accept cannot contain a More-Data-Pending attribute instead of using a new service type value? (3) How can a large attributue that is allowed to appear in an Access-Accept but not allowed to appear in Access-Challenge be = fragmented? [Rafa] 1) We wanted to be symmetric in the design, where = Access-Request/Access-Challenge exchange is used somehow for = fragmentation support. In any case, we have also considered the usage of = Access-Accept with Service-Type[AddAuth] so until all the attributes in = the whole RADIUS Access-Accept are finally sent the exchange will be = Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one = is simply Access-Request/Access-Accept. This mode of operation would = solve your question 3). 2) I think that may be also possible. In any case, I think Alan or Alex = can elaborate a little bit a more about the usage of = Service-Type[AddAuth]. 3) Precisely, trying to answer this question we just came up with the = solution in 1). What do you think? =20 Section 8: [YO] Security Considerations section is too short. Security mechansims that are needed for secure operation of the proposed fragmentation mechanism needs to be described in this section. [Rafa] Yes this section will be improved. Jim also raised comments about = it. Section 9: [YO] I don't think the following statement is true: "This document has no actions for IANA." because Section 6 defines new attributes. [Rafa] Correct. This needs to be fixed. Best Regards, Yoshihiro Ohba " Best regards. ------------------------------------------------------- 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 ------------------------------------------------------- From alex@um.es Wed Jan 30 00:45:34 2013 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 2665A21F8849 for ; Wed, 30 Jan 2013 00:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AcpOaCZqzmi for ; Wed, 30 Jan 2013 00:45:33 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 89E9D21F8654 for ; Wed, 30 Jan 2013 00:45:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 9781F536B9 for ; Wed, 30 Jan 2013 09:45:31 +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 LJy2sd+OccN8 for ; Wed, 30 Jan 2013 09:45:31 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id F315F536AF for ; Wed, 30 Jan 2013 09:45:30 +0100 (CET) Message-ID: <5108DDAA.9030708@um.es> Date: Wed, 30 Jan 2013 09:45:30 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: <20130124094903.28508.37132.idtracker@ietfa.amsl.com> <5101047D.20103@um.es> <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> In-Reply-To: <8708770F-0508-49A7-BDB7-63D3D4F8956A@um.es> Content-Type: multipart/alternative; boundary="------------090409010301090200040308" Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.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, 30 Jan 2013 08:45:34 -0000 This is a multi-part message in MIME format. --------------090409010301090200040308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Yoshi, Rafa, see some comments inline: > Dear all, > > we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. > > Please, see some comments inline. > > "Here is my review of draft-perez-radext-radius-fragmentation-04. > > Section 1: > > "Each RADIUS packet can transport several RADIUS attributes, to convey > the necessary information to the other peer, up to a maximum size of 4 > KB of total data (including RADIUS packet headers)." > > [YO] I suggest to replace "4 KB" with "4096 bytes" throughout the > document since "KB" can mean 4000 bytes in some cases. > > [Rafa] OK. > > > "A reference-based mechanism is also proposed in [RFC6158], where > attributes can be obtained through an out-of-band protocol." > > [YO} Meaning of this sentence is unclear. Does this mean RADIUS > attributes are obtained through some other protocol instead of RADIUS? > Or does this mean the actual format of the Value field of a RADIUS > Attribute is defined in other protocol specification? In the latter > case, it should be also mentioned that RADIUS-EAP is categorized as the > mechanism defined in RFC 6158. > > [Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more. > > "However, there are no proposals to deal with fragmentation at a packet > level, when the total size exceeds the 4 KB limit imposed by the RADIUS > specification." > > [YO] Meaning of "at a packet level" is unclear. Suggested change: > "However, there are no proposals to fragement a large-sized RADIUS > packet into multiple small-sized RADIUS packets, where the length of the > original (unfragmented) RADIUS packet exceeds the 4096-octet limit > imposed by the RADIUS specification." > > [Rafa] This sounds good. > > > Section 2: > > [YO] I am not sure if "T" flag is needed. In other words, it should be > possible to change [I-D.ietf-radext-radius-extensions] to simply allow a > fragment with the M-flag cleared not to be included in a non-last chunk. > > [Rafa] > > Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now. > > In any case, we may ask authors of [I-D.ietf-radext-radius-extensions]. > > Section 3.3: > > [YO] Access-Accept fragmentation scheme looks odd compared to > Access-Request and Access-Challenge fragmentation schemes. There are > several questions related to this: (1) Why multiple chunks of > Access-Accept cannot be sent without having an Access-Challange to be > sent in between? (2) Why an Access-Accept cannot contain a > More-Data-Pending attribute instead of using a new service type value? > (3) How can a large attributue that is allowed to appear in an > Access-Accept but not allowed to appear in Access-Challenge be fragmented? > > [Rafa] > > 1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3). > > 2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth]. > > 3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think? This alternative sounds good to me. However, I think there may be still some advantages of using Service-Type instead of (or in addition to) More-Data-Pending for Access-Accept packets. If the NAS/RP does not know anything about fragmentation (i.e. does not support this draft), it may take the first Access-Accept chunk, ignore the More-Data-Pending attribute (it is unknown for it), and process it as a complete packet. As no additional round-trip is mandatory after an Access-Accept packet, it may be problematic as it is possible that part of the obligations from the AS to the NAS (e.g. FW policies) are not enforced. However, RFC 2865 says that (in relation to Access-Accept packets): A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead Therefore, if the NAS does not understand Service-Type=AdditionalAuthorization, the Access-Accept packet will be interpreted as an Access-Reject one, which seems to be the most reasonable approach. This sort of problems seem to not be critical with Access-Challenge packets, as the NAS is expected to generate a new Access-Request packet afterwards, and the AS can detect whether fragmentation was supported. Regards, Alejandro > Section 8: > > [YO] Security Considerations section is too short. Security mechansims > that are needed for secure operation of the proposed fragmentation > mechanism needs to be described in this section. > > [Rafa] Yes this section will be improved. Jim also raised comments about it. > > Section 9: > > [YO] I don't think the following statement is true: "This document has > no actions for IANA." because Section 6 defines new attributes. > > [Rafa] Correct. This needs to be fixed. > > Best Regards, > Yoshihiro Ohba > " > > Best regards. > > ------------------------------------------------------- > 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 > ------------------------------------------------------- > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------090409010301090200040308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello Yoshi, Rafa,

see some comments inline:


Dear all,

we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. 

Please, see some comments inline.

"Here is my review of draft-perez-radext-radius-fragmentation-04.

Section 1:

"Each RADIUS packet can transport several RADIUS attributes, to convey
the necessary information to the other peer, up to a maximum size of 4
KB of total data (including RADIUS packet headers)."

[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
document since "KB" can mean 4000 bytes in some cases.

[Rafa] OK.


"A reference-based mechanism is also proposed in [RFC6158], where
attributes can be obtained through an out-of-band protocol."

[YO} Meaning of this sentence is unclear. Does this mean RADIUS
attributes are obtained through some other protocol instead of RADIUS?
Or does this mean the actual format of the Value field of a RADIUS
Attribute is defined in other protocol specification? In the latter
case, it should be also mentioned that RADIUS-EAP is categorized as the
mechanism defined in RFC 6158.

[Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.

"However, there are no proposals to deal with fragmentation at a packet
level, when the total size exceeds the 4 KB limit imposed by the RADIUS
specification."

[YO] Meaning of "at a packet level" is unclear. Suggested change:
"However, there are no proposals to fragement a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of the
original (unfragmented) RADIUS packet exceeds the 4096-octet limit
imposed by the RADIUS specification."

[Rafa] This sounds good.


Section 2:

[YO] I am not sure if "T" flag is needed. In other words, it should be
possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
fragment with the M-flag cleared not to be included in a non-last chunk.

[Rafa] 

Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.

In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].

Section 3.3:

[YO] Access-Accept fragmentation scheme looks odd compared to
Access-Request and Access-Challenge fragmentation schemes. There are
several questions related to this: (1) Why multiple chunks of
Access-Accept cannot be sent without having an Access-Challange to be
sent in between? (2) Why an Access-Accept cannot contain a
More-Data-Pending attribute instead of using a new service type value?
(3) How can a large attributue that is allowed to appear in an
Access-Accept but not allowed to appear in Access-Challenge be fragmented?

[Rafa]

1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).

2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].

3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think?

This alternative sounds good to me. However, I think there may be still some advantages of using Service-Type instead of (or in addition to) More-Data-Pending for Access-Accept packets.

If the NAS/RP does not know anything about fragmentation (i.e. does not support this draft), it may take the first Access-Accept chunk, ignore the More-Data-Pending attribute (it is unknown for it), and process it as a complete packet. As no additional round-trip is mandatory after an Access-Accept packet, it may be problematic as it is possible that part of the obligations from the AS to the NAS (e.g. FW policies) are not enforced.

However, RFC 2865 says that (in relation to Access-Accept packets):
A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead

Therefore, if the NAS does not understand Service-Type=AdditionalAuthorization, the Access-Accept packet will be interpreted as an Access-Reject one, which seems to be the most reasonable approach.

This sort of problems seem to not be critical with Access-Challenge packets, as the NAS is expected to generate a new Access-Request packet afterwards, and the AS can detect whether fragmentation was supported.

Regards,
Alejandro

Section 8:

[YO] Security Considerations section is too short. Security mechansims
that are needed for secure operation of the proposed fragmentation
mechanism needs to be described in this section.

[Rafa] Yes this section will be improved. Jim also raised comments about it.

Section 9:

[YO] I don't think the following statement is true: "This document has
no actions for IANA." because Section 6 defines new attributes.

[Rafa] Correct. This needs to be fixed.

Best Regards,
Yoshihiro Ohba
"

Best regards.

-------------------------------------------------------
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
-------------------------------------------------------




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

--------------090409010301090200040308--