From owner-radiusext@ops.ietf.org Fri Feb 1 21:54:21 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878D13A698B for ; Fri, 1 Feb 2008 21:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdjwfzsB4BMc for ; Fri, 1 Feb 2008 21:54:20 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D62783A686F for ; Fri, 1 Feb 2008 21:54:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLBEH-000KjN-Cx for radiusext-data@psg.com; Sat, 02 Feb 2008 05:47:53 +0000 Received: from [203.155.33.38] (helo=mail1.ksc.th.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JLBEE-000Kj6-O2 for radiusext@ops.ietf.org; Sat, 02 Feb 2008 05:47:52 +0000 Received: from gzornt61 ([203.209.69.218]) by mail1.ksc.th.com (8.12.1/8.12.1) with ESMTP id m125lNVr012721; Sat, 2 Feb 2008 12:47:40 +0700 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'radext mailing list'" References: <47A18C37.6040209@nitros9.org> Subject: RE: Question about RFC 2865 Date: Sat, 2 Feb 2008 12:47:18 +0700 Message-ID: <000001c8655f$1dd2c570$5601f00a@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Achj56XHPe3Ys+vzTMmwalvaeMVP6QBXvYMw In-Reply-To: <47A18C37.6040209@nitros9.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk Alan DeKok <> scribbled on Thursday, January 31, 2008 3:52 PM: > Section 5 (Attributes), page 25 says: > > ... > Value > > The Value field is zero or more octets and contains information > specific to the Attribute. > ... > > However, the following text defining type-specific formats does not > define any circumstance under which a Value field of zero octets is > permissible. Instead, the "string" and "text" types say: > > ...length zero (0) MUST NOT be sent; > omit the entire attribute instead. > > > This appears to be an inconsistency in the document. Is it a > problem? Probably. File an Errata w/the RFC Editor, I think. > > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 4 12:42:50 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E283A6CA9 for ; Mon, 4 Feb 2008 12:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9aU4NFfCuH0 for ; Mon, 4 Feb 2008 12:42:48 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DB8603A6D68 for ; Mon, 4 Feb 2008 12:42:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM7zh-000H1c-JY for radiusext-data@psg.com; Mon, 04 Feb 2008 20:32:45 +0000 Received: from [65.55.175.220] (helo=blu139-omc3-s20.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JM7ze-000H1F-TI for radiusext@ops.ietf.org; Mon, 04 Feb 2008 20:32:44 +0000 Received: from BLU137-W3 ([65.55.162.187]) by blu139-omc3-s20.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Feb 2008 12:32:42 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_5468d955-92b5-40fb-8c7b-61ce6849ad02_" X-Originating-IP: [131.107.0.71] From: Bernard Aboba To: Subject: FW: Pending Errata for RADEXT documents Date: Mon, 4 Feb 2008 12:32:42 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2008 20:32:42.0361 (UTC) FILETIME=[1782E690:01C8676D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_5468d955-92b5-40fb-8c7b-61ce6849ad02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI...> Date: Mon, 4 Feb 2008 11:40:25 +0100> From: dromasca@avaya.com> To:= radext-chairs@tools.ietf.org> CC: rbonica@juniper.net> Subject: Pending Er= rata for RADEXT documents> > RADEXT chairs,> > We are in the process of hel= ping the RFC Editor clean up the backlog of> unverified errata. There are a= number of such errata related to> documents issued by the RADEXT Working G= roup, which can be found at> http://www.rfc-editor.org/errata_list.php. > >= Specifically: > > | RFC4282 | 753 | 2006-08-14 | Frank Ellermann | radext = |> Technical | > | RFC4282 | 757 | 2005-12-13 | Peter Koch | radext |> Tech= nical | > | RFC4282 | 816 | 2005-12-18 | Alfred Hoenes | radext |> Technica= l | > | RFC4590 | 47 | 2006-09-21 | Alexander Schrab | radext |> Editorial = | > | RFC4668 | 29 | 2006-11-06 | Alfred Hoenes | radext |> Technical | > |= RFC4668 | 867 | 2006-11-06 | Alfred Hoenes | radext |> Editorial | > | RFC= 4668 | 884 | 2006-11-06 | Alfred Hoenes | radext |> Editorial | > | RFC4669= | 876 | 2006-11-06 | Alfred Hoenes | radext |> Editorial | > | RFC4670 | 2= 7 | 2006-11-06 | Alfred Hoenes | radext |> Technical | > | RFC4670 | 877 | = 2006-11-06 | Alfred Hoenes | radext |> Editorial | > | RFC4671 | 879 | 2006= -11-06 | Alfred Hoenes | radext |> Editorial | > | RFC4671 | 881 | 2006-11-= 06 | Alfred Hoenes | radext |> Editorial | > | RFC4671 | 882 | 2006-11-06 |= Alfred Hoenes | radext |> Editorial | > | RFC4673 | 891 | 2006-11-06 | Alf= red Hoenes | radext |> Editorial | > | RFC4675 | 24 | 2006-09-19 | Nikolai = Malykh | radext |> Editorial | > > Can you please have a look at these and = let us know what would be the> best process of verifying the accuracy of th= ese and approving what makes> sense. I would eliminate from start minor edi= torial issues that clearly> do not impact interoperability of the clarity o= f the secifications. > > Thanks and Regards,> > Dan> = --_5468d955-92b5-40fb-8c7b-61ce6849ad02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI...

> Date: Mon, 4 Feb 2008 11:40:25 +0100
> From: droma= sca@avaya.com
> To: radext-chairs@tools.ietf.org
> CC: rbonica@= juniper.net
> Subject: Pending Errata for RADEXT documents
> > RADEXT chairs,
>
> We are in the process of helping the= RFC Editor clean up the backlog of
> unverified errata. There are a = number of such errata related to
> documents issued by the RADEXT Wor= king Group, which can be found at
> http://www.rfc-editor.org/errata_= list.php.
>
> Specifically:
>
> | RFC4282 | 753= | 2006-08-14 | Frank Ellermann | radext |
> Technical |
> | R= FC4282 | 757 | 2005-12-13 | Peter Koch | radext |
> Technical |
&= gt; | RFC4282 | 816 | 2005-12-18 | Alfred Hoenes | radext |
> Technic= al |
> | RFC4590 | 47 | 2006-09-21 | Alexander Schrab | radext |
= > Editorial |
> | RFC4668 | 29 | 2006-11-06 | Alfred Hoenes | rad= ext |
> Technical |
> | RFC4668 | 867 | 2006-11-06 | Alfred Ho= enes | radext |
> Editorial |
> | RFC4668 | 884 | 2006-11-06 |= Alfred Hoenes | radext |
> Editorial |
> | RFC4669 | 876 | 20= 06-11-06 | Alfred Hoenes | radext |
> Editorial |
> | RFC4670 = | 27 | 2006-11-06 | Alfred Hoenes | radext |
> Technical |
> |= RFC4670 | 877 | 2006-11-06 | Alfred Hoenes | radext |
> Editorial | =
> | RFC4671 | 879 | 2006-11-06 | Alfred Hoenes | radext |
> Ed= itorial |
> | RFC4671 | 881 | 2006-11-06 | Alfred Hoenes | radext |<= BR>> Editorial |
> | RFC4671 | 882 | 2006-11-06 | Alfred Hoenes |= radext |
> Editorial |
> | RFC4673 | 891 | 2006-11-06 | Alfre= d Hoenes | radext |
> Editorial |
> | RFC4675 | 24 | 2006-09-1= 9 | Nikolai Malykh | radext |
> Editorial |
>
> Can you= please have a look at these and let us know what would be the
> best= process of verifying the accuracy of these and approving what makes
>= ; sense. I would eliminate from start minor editorial issues that clearly> do not impact interoperability of the clarity of the secifications. =
>
> Thanks and Regards,
>
> Dan
>
= --_5468d955-92b5-40fb-8c7b-61ce6849ad02_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 00:43:08 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1732228C12F for ; Fri, 8 Feb 2008 00:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMFV8Ovkss3j for ; Fri, 8 Feb 2008 00:43:07 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 16A8128C16D for ; Fri, 8 Feb 2008 00:43:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNOgE-0001Bn-Cg for radiusext-data@psg.com; Fri, 08 Feb 2008 08:33:54 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNOgB-0001BL-JJ for radiusext@ops.ietf.org; Fri, 08 Feb 2008 08:33:53 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id B149C76F4A for ; Fri, 8 Feb 2008 09:33:49 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id A3BB576F47 for ; Fri, 8 Feb 2008 09:33:49 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org Subject: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 09:33:45 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart3306979.0A814c2o6r Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, there is a new version of the RadSec draft available under http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt It contains the changes which were announced in IETF70 in Vancouver. The two main points are: =2D mention TLS with shared secrets as a possible means of establishing the= TLS=20 tunnel (though no implementations currently offer that option) =2D The CA selection during the TLS handshake. This was presented in the=20 Vancouver meeting, but the problem has two sides: server-to-client signalli= ng=20 of acceptable CAs can be signalled with TLS 1.1, as presented in the=20 Vancouver meeting. The other way round, client-to-server signalling, is not= =20 possible with TLS 1.1. There is ongoing work in the tls working group thoug= h,=20 http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-01.txt , whi= ch=20 will allow a Trusted CA indication later. A note that this signalling is th= e=20 suggested behaviour as soon as that draft is ratified is added in the curre= nt=20 radsec draft. Greetings, Stefan Winter =2D-=20 Stefan WINTER RESTENA Foundation - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education = Nationale et de=20 la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0=C2=A0+352= 424409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax:= =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart3306979.0A814c2o6r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHrBPt+jm90f8eFWYRAj6bAJ4hO7erD7hgFSQijMZWmeVlEDvD4wCeLKJz MvZyHyQYw5PReD+tUM8/7wQ= =XN1G -----END PGP SIGNATURE----- --nextPart3306979.0A814c2o6r-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 01:47:53 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792D028C0EB for ; Fri, 8 Feb 2008 01:47:53 -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 core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0gDEwgnQMdg for ; Fri, 8 Feb 2008 01:47:52 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6A57F28C12E for ; Fri, 8 Feb 2008 01:47:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNPfU-0009xN-Ff for radiusext-data@psg.com; Fri, 08 Feb 2008 09:37:12 +0000 Received: from [76.96.62.32] (helo=QMTA03.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNPfR-0009wh-75 for radiusext@ops.ietf.org; Fri, 08 Feb 2008 09:37:10 +0000 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA03.westchester.pa.mail.comcast.net with comcast id mxYQ1Y0010mv7h05300X00; Fri, 08 Feb 2008 09:36:56 +0000 Received: from gzornt61 ([124.120.226.91]) by OMTA11.westchester.pa.mail.comcast.net with comcast id mxck1Y0081ywtWc3X00000; Fri, 08 Feb 2008 09:37:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=TuEEcIFd5YL6z6dLqLAA:9 a=wQdheGBN1PYZrmHWMmwA:7 a=9IHV8avbFvip_CvZxmRx2y4y2AUA:4 a=pt045V2O6wwA:10 From: "Glen Zorn" To: "'Stefan Winter'" Cc: References: <200802080933.49040.stefan.winter@restena.lu> Subject: RE: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 16:36:41 +0700 Message-ID: <006801c86a36$28c05250$5be2787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <200802080933.49040.stefan.winter@restena.lu> Thread-index: AchqLeSE4G/aHf1ITWCA4y7YGjddJQACAxrg Sender: owner-radiusext@ops.ietf.org Precedence: bulk Are you planning to request a BOF slot in Philadephia? If not, I would strongly encourage you to do so. Stefan Winter <> scribbled on Friday, February 08, 2008 3:34 PM: > Hello, > > there is a new version of the RadSec draft available under > > http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt > > It contains the changes which were announced in IETF70 in Vancouver. > > The two main points are: > > - mention TLS with shared secrets as a possible means of establishing > the TLS tunnel (though no implementations currently offer that > option) > - The CA selection during the TLS handshake. This was presented in > the Vancouver meeting, but the problem has two sides: > server-to-client signalling of acceptable CAs can be signalled with > TLS 1.1, as presented in the Vancouver meeting. The other way round, > client-to-server signalling, is not possible with TLS 1.1. There is > ongoing work in the tls working group though, > http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-01.txt > , which will allow a Trusted CA indication later. A note that this > signalling is the suggested behaviour as soon as that draft is > ratified is added in the current radsec draft. > > Greetings, > > Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 02:04:15 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F18728C1E5 for ; Fri, 8 Feb 2008 02:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzrPRUxuCCGE for ; Fri, 8 Feb 2008 02:04:14 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 81E4B28C1EC for ; Fri, 8 Feb 2008 02:04:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNPyI-000CXy-Tx for radiusext-data@psg.com; Fri, 08 Feb 2008 09:56:38 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNPyB-000CWT-5j for radiusext@ops.ietf.org; Fri, 08 Feb 2008 09:56:33 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 59A2576F4A; Fri, 8 Feb 2008 10:56:30 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 4912E76F47; Fri, 8 Feb 2008 10:56:30 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 10:56:25 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org References: <200802080933.49040.stefan.winter@restena.lu> <006801c86a36$28c05250$5be2787c@arubanetworks.com> In-Reply-To: <006801c86a36$28c05250$5be2787c@arubanetworks.com> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart6844755.QOo7syA114 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Are you planning to request a BOF slot in Philadephia? If not, I would > strongly encourage you to do so. It was considered, and I held a conf call with several ADs about it. The to= pic=20 would not be RadSec only, but also several other things about the use of=20 EAP/EAPoL in large federated roaming environments. Unfortunately, it is quite late to still do a well-prepared BOF for IETF71,= =20 and so it was suggested that I hold a "bar BoF", which I will do. As a matt= er=20 of fact, I'll be at the meeting the entire week, so there's plenty of time= =20 for discussion at any time. I'm also about to write a draft for one of the EAP issues, about the proble= m=20 that it is sub-optimal to find out how much EAP payload exactly to put into= a=20 RADIUS packet so that it doesn't fragment on the way but still fills the=20 available space. Currently, this is determined by guessing and=20 better-safe-than-sorry underestimations on the server side, and not at all= =20 done on the supplicant side. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart6844755.QOo7syA114 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHrCdN+jm90f8eFWYRAuKxAJ9GBwT8MvGfaTnYZO8NrrODRs0HNgCdFbFF UTVhEGOzE5oauH129NM0g8E= =7rpf -----END PGP SIGNATURE----- --nextPart6844755.QOo7syA114-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 02:12:15 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83E628C1B9 for ; Fri, 8 Feb 2008 02:12:15 -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 core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETRfVi5cBBrH for ; Fri, 8 Feb 2008 02:12:15 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 2C3DE28C16E for ; Fri, 8 Feb 2008 02:12:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQ6V-000Dk5-Rl for radiusext-data@psg.com; Fri, 08 Feb 2008 10:05:07 +0000 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQ6T-000DjV-BQ for radiusext@ops.ietf.org; Fri, 08 Feb 2008 10:05:06 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 142F7A704E; Fri, 8 Feb 2008 02:04:56 -0800 (PST) Message-ID: <47AC28B1.3030205@nitros9.org> Date: Fri, 08 Feb 2008 11:02:25 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Winter CC: Glen Zorn , radiusext@ops.ietf.org Subject: Re: draft-winter-radsec-01 published References: <200802080933.49040.stefan.winter@restena.lu> <006801c86a36$28c05250$5be2787c@arubanetworks.com> <200802081056.29687.stefan.winter@restena.lu> In-Reply-To: <200802081056.29687.stefan.winter@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter wrote: > I'm also about to write a draft for one of the EAP issues, about the problem > that it is sub-optimal to find out how much EAP payload exactly to put into a > RADIUS packet so that it doesn't fragment on the way but still fills the > available space. Currently, this is determined by guessing ? RFC 3579, Section 2.4 says that the NAS should Framed-MTU. All servers I know of use this to determine EAP payload. If the Framed-MTU isn't sent, then a "safe" assumption of normal Ethernet is used. i.e. eap_payload = Framed-MTU - eapol_header This calculation is extended to the contents of EAP types, by accounting for known, and fixed, EAP-type headers. > and > better-safe-than-sorry underestimations on the server side, and not at all > done on the supplicant side. ? If the supplicant doesn't know what the local L2 MTU is, it's completely broken. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 02:19:58 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863D628C1E9 for ; Fri, 8 Feb 2008 02:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2FShUGm9c+u for ; Fri, 8 Feb 2008 02:19:57 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7E86128C1BD for ; Fri, 8 Feb 2008 02:19:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQG9-000F46-GM for radiusext-data@psg.com; Fri, 08 Feb 2008 10:15:05 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQG6-000F3I-4M for radiusext@ops.ietf.org; Fri, 08 Feb 2008 10:15:04 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 3985D76F4A; Fri, 8 Feb 2008 11:15:01 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 25E2076F47; Fri, 8 Feb 2008 11:15:01 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: Alan DeKok Subject: Re: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 11:14:57 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <200802080933.49040.stefan.winter@restena.lu> <200802081056.29687.stefan.winter@restena.lu> <47AC28B1.3030205@nitros9.org> In-Reply-To: <47AC28B1.3030205@nitros9.org> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart2848574.OIrO05vLX7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > If the supplicant doesn't know what the local L2 MTU is, it's > completely broken. The issue is more about the supplicant knowing its MTU, sending the maximum= =20 payload possible (typically, in EAP-TLS where the supplicant has a lot to=20 say), the authenticator encapsulating that in a RADIUS packet, which grows= =20 larger than the MTU on its own uplink, leading to fragmentation of the UDP= =20 packet. That is not in principle a problem, but practical experience has=20 shown that too many firewalls drop the fragments and auth doesn't work. It would be desirable to be able to tell the supplicant that it should send= =20 *less* than its own MTU to prevent that from happening. On the server side, EAP fragment size is statically configured, and is ofte= n a=20 lot less than what supplicant could handle (1024 is a common default). Thus= ,=20 sending less payload than would be possible means that a server has to spli= t=20 the EAP conversation in more RADIUS packets than need be, meaning more=20 round-trips and longer time-to-auth.=20 greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart2848574.OIrO05vLX7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHrCuk+jm90f8eFWYRAsaGAKCFl3H7MUKkSLqQbvtgYbjWcjnrUACeNNh/ JVHHZ8/EPaCC1fM3PIiZO9w= =cvTG -----END PGP SIGNATURE----- --nextPart2848574.OIrO05vLX7-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 02:34:02 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A547B28C1E7 for ; Fri, 8 Feb 2008 02:34:02 -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 core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glFcweKJvegs for ; Fri, 8 Feb 2008 02:34:01 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C227628C0F8 for ; Fri, 8 Feb 2008 02:34:01 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQQW-000GIq-EG for radiusext-data@psg.com; Fri, 08 Feb 2008 10:25:48 +0000 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQQT-000GIO-FT for radiusext@ops.ietf.org; Fri, 08 Feb 2008 10:25:47 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id EE8E2A704E; Fri, 8 Feb 2008 02:25:35 -0800 (PST) Message-ID: <47AC2D89.1060604@deployingradius.com> Date: Fri, 08 Feb 2008 11:23:05 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Winter CC: Alan DeKok , radiusext@ops.ietf.org Subject: Re: draft-winter-radsec-01 published References: <200802080933.49040.stefan.winter@restena.lu> <200802081056.29687.stefan.winter@restena.lu> <47AC28B1.3030205@nitros9.org> <200802081115.00527.stefan.winter@restena.lu> In-Reply-To: <200802081115.00527.stefan.winter@restena.lu> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter wrote: > The issue is more about the supplicant knowing its MTU, sending the maximum > payload possible (typically, in EAP-TLS where the supplicant has a lot to > say), the authenticator encapsulating that in a RADIUS packet, which grows > larger than the MTU on its own uplink, leading to fragmentation of the UDP > packet. Ah. That's a completely separate problem. > That is not in principle a problem, but practical experience has > shown that too many firewalls drop the fragments and auth doesn't work. Broken firewalls are bad. Putting a firewall between a NAS and a RADIUS server is generally not a good idea. Sending RADIUS over the wider Internet isn't a good idea, unless encapsulation is used (IPSec, etc.), which solves the UDP fragmentation problem. > It would be desirable to be able to tell the supplicant that it should send > *less* than its own MTU to prevent that from happening. This is a path MTU discovery problem. It's hard. i.e. impossible, in the general case. > On the server side, EAP fragment size is statically configured, and is often a > lot less than what supplicant could handle (1024 is a common default). Thus, > sending less payload than would be possible means that a server has to split > the EAP conversation in more RADIUS packets than need be, meaning more > round-trips and longer time-to-auth. I'm not sure what else to say other than "Yes, that's life..." I think it's a bad idea to add complexity to EAP in order to work around firewall bugs. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 02:49:13 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A9828C1E7 for ; Fri, 8 Feb 2008 02:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrwpjX5Mw7Iv for ; Fri, 8 Feb 2008 02:49:12 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A0FDF28C1C8 for ; Fri, 8 Feb 2008 02:49:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQfk-000IO5-HP for radiusext-data@psg.com; Fri, 08 Feb 2008 10:41:32 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNQfh-000ILo-UW for radiusext@ops.ietf.org; Fri, 08 Feb 2008 10:41:31 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id B58B976F4A; Fri, 8 Feb 2008 11:41:28 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id A40C776F42; Fri, 8 Feb 2008 11:41:28 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: Alan DeKok Subject: Re: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 11:41:28 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org References: <200802080933.49040.stefan.winter@restena.lu> <200802081115.00527.stefan.winter@restena.lu> <47AC2D89.1060604@deployingradius.com> In-Reply-To: <47AC2D89.1060604@deployingradius.com> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart2407923.BYBiNbY0Af Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > > On the server side, EAP fragment size is statically configured, and is > > often a lot less than what supplicant could handle (1024 is a common > > default). Thus, sending less payload than would be possible means that a > > server has to split the EAP conversation in more RADIUS packets than ne= ed > > be, meaning more round-trips and longer time-to-auth. > > I'm not sure what else to say other than "Yes, that's life..." The idea would be to make life better, if that's at all possible. Long=20 authentication time is bad. Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart2407923.BYBiNbY0Af Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHrDHY+jm90f8eFWYRApQCAJsEfg6uOe9rlDqO4ilL0HVIoExAAACfYtSE X5o3jCIqmDX/t8yblPwKgoU= =vj72 -----END PGP SIGNATURE----- --nextPart2407923.BYBiNbY0Af-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 06:28:27 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8759928C2DE for ; Fri, 8 Feb 2008 06:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.717 X-Spam-Level: X-Spam-Status: No, score=-3.717 tagged_above=-999 required=5 tests=[AWL=1.882, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFE8nP-sD4pP for ; Fri, 8 Feb 2008 06:28:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 97E0E28C2D9 for ; Fri, 8 Feb 2008 06:28:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNU19-000KRo-97 for radiusext-data@psg.com; Fri, 08 Feb 2008 14:15:51 +0000 Received: from [65.55.175.192] (helo=blu139-omc2-s22.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNU12-000KRC-T2 for radiusext@ops.ietf.org; Fri, 08 Feb 2008 14:15:49 +0000 Received: from BLU137-W18 ([65.55.162.184]) by blu139-omc2-s22.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Feb 2008 06:15:44 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_4297b688-cf14-44be-9ee3-38f1a9d3f748_" X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Alan DeKok , Stefan Winter CC: Alan DeKok , Subject: RE: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 06:15:44 -0800 Importance: Normal In-Reply-To: <47AC2D89.1060604@deployingradius.com> References: <200802080933.49040.stefan.winter@restena.lu> <200802081056.29687.stefan.winter@restena.lu> <47AC28B1.3030205@nitros9.org> <200802081115.00527.stefan.winter@restena.lu> <47AC2D89.1060604@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2008 14:15:44.0359 (UTC) FILETIME=[17C8AF70:01C86A5D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_4297b688-cf14-44be-9ee3-38f1a9d3f748_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To be clear, this fragmentation issue is a problem for RADIUS, but not RADS= EC, correct?=20 I'd assume that TCP MSS negotiation combined with Packetization Layer Path = MTU discovery should make fragmentation of TCP segments relatively unlikely.=20 BTW, how does IPsec solve the fragmentation problem for RADIUS? Couldn't i= t make it worse?=20 > Date: Fri, 8 Feb 2008 11:23:05 +0100 > From: aland@deployingradius.com > To: stefan.winter@restena.lu > CC: aland@nitros9.org; radiusext@ops.ietf.org > Subject: Re: draft-winter-radsec-01 published >=20 > Stefan Winter wrote: > > The issue is more about the supplicant knowing its MTU, sending the max= imum=20 > > payload possible (typically, in EAP-TLS where the supplicant has a lot = to=20 > > say), the authenticator encapsulating that in a RADIUS packet, which gr= ows=20 > > larger than the MTU on its own uplink, leading to fragmentation of the = UDP=20 > > packet. >=20 > Ah. That's a completely separate problem. >=20 > > That is not in principle a problem, but practical experience has=20 > > shown that too many firewalls drop the fragments and auth doesn't work. >=20 > Broken firewalls are bad. Putting a firewall between a NAS and a > RADIUS server is generally not a good idea. Sending RADIUS over the > wider Internet isn't a good idea, unless encapsulation is used (IPSec, > etc.), which solves the UDP fragmentation problem. >=20 > > It would be desirable to be able to tell the supplicant that it should = send=20 > > *less* than its own MTU to prevent that from happening. >=20 > This is a path MTU discovery problem. It's hard. i.e. impossible, in > the general case. >=20 > > On the server side, EAP fragment size is statically configured, and is = often a=20 > > lot less than what supplicant could handle (1024 is a common default). = Thus,=20 > > sending less payload than would be possible means that a server has to = split=20 > > the EAP conversation in more RADIUS packets than need be, meaning more= =20 > > round-trips and longer time-to-auth.=20 >=20 > I'm not sure what else to say other than "Yes, that's life..." >=20 > I think it's a bad idea to add complexity to EAP in order to work > around firewall bugs. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --_4297b688-cf14-44be-9ee3-38f1a9d3f748_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To be clear, this= fragmentation issue is a problem for RADIUS, but not RADSEC, correct?
= I'd assume that TCP MSS negotiation combined with Packetization Layer Path = MTU discovery
should make fragmentation of TCP segments relatively unlik= ely.

BTW, how does IPsec solve the fragmentation problem for RADIUS= ?  Couldn't it make it worse?

> Date: Fri, 8 Feb 200= 8 11:23:05 +0100
> From: aland@deployingradius.com
> To: stefan= .winter@restena.lu
> CC: aland@nitros9.org; radiusext@ops.ietf.org> Subject: Re: draft-winter-radsec-01 published
>
> Stefan= Winter wrote:
> > The issue is more about the supplicant knowing = its MTU, sending the maximum
> > payload possible (typically, in = EAP-TLS where the supplicant has a lot to
> > say), the authentic= ator encapsulating that in a RADIUS packet, which grows
> > large= r than the MTU on its own uplink, leading to fragmentation of the UDP
&= gt; > packet.
>
> Ah. That's a completely separate probl= em.
>
> > That is not in principle a problem, but practical= experience has
> > shown that too many firewalls drop the fragme= nts and auth doesn't work.
>
> Broken firewalls are bad. Pu= tting a firewall between a NAS and a
> RADIUS server is generally not= a good idea. Sending RADIUS over the
> wider Internet isn't a good = idea, unless encapsulation is used (IPSec,
> etc.), which solves the = UDP fragmentation problem.
>
> > It would be desirable to b= e able to tell the supplicant that it should send
> > *less* than= its own MTU to prevent that from happening.
>
> This is a p= ath MTU discovery problem. It's hard. i.e. impossible, in
> the gen= eral case.
>
> > On the server side, EAP fragment size is s= tatically configured, and is often a
> > lot less than what suppl= icant could handle (1024 is a common default). Thus,
> > sending = less payload than would be possible means that a server has to split
&g= t; > the EAP conversation in more RADIUS packets than need be, meaning m= ore
> > round-trips and longer time-to-auth.
>
> = I'm not sure what else to say other than "Yes, that's life..."
>
= > I think it's a bad idea to add complexity to EAP in order to work> around firewall bugs.
>
> Alan DeKok.
>
>= --
> to unsubscribe send a message to radiusext-request@ops.ietf.org= with
> the word 'unsubscribe' in a single line as the message text b= ody.
> archive: <http://psg.com/lists/radiusext/>
= --_4297b688-cf14-44be-9ee3-38f1a9d3f748_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 06:37:32 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D403D3A6FB5 for ; Fri, 8 Feb 2008 06:37:32 -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 core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCOPSSTqwnBs for ; Fri, 8 Feb 2008 06:37:31 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8F4AE28C2EA for ; Fri, 8 Feb 2008 06:36:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNUFU-000NHI-S8 for radiusext-data@psg.com; Fri, 08 Feb 2008 14:30:40 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNUFO-000NGP-C3 for radiusext@ops.ietf.org; Fri, 08 Feb 2008 14:30:35 +0000 Received: (qmail 9216 invoked from network); 8 Feb 2008 09:30:33 -0500 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.1) by gumby.elbrysnetworks.com with SMTP; 8 Feb 2008 09:30:33 -0500 Message-ID: <47AC6789.4050002@elbrysnetworks.com> Date: Fri, 08 Feb 2008 09:30:33 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba CC: Alan DeKok , Stefan Winter , Alan DeKok , radiusext@ops.ietf.org Subject: Re: draft-winter-radsec-01 published References: <200802080933.49040.stefan.winter@restena.lu> <200802081056.29687.stefan.winter@restena.lu> <47AC28B1.3030205@nitros9.org> <200802081115.00527.stefan.winter@restena.lu> <47AC2D89.1060604@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba wrote: > BTW, how does IPsec solve the fragmentation problem for RADIUS? Maybe it prevents the "broken" firewalls from peeking into the packets, seeing UDP fragments, and dropping them. They skate by via means of an IPsec pass through feature. Just a guess. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 8 08:17:54 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E77228C379 for ; Fri, 8 Feb 2008 08:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.821 X-Spam-Level: X-Spam-Status: No, score=-3.821 tagged_above=-999 required=5 tests=[AWL=1.778, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGyVOMV9afUe for ; Fri, 8 Feb 2008 08:17:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E1AF328C387 for ; Fri, 8 Feb 2008 08:17:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNVmo-000E37-Cq for radiusext-data@psg.com; Fri, 08 Feb 2008 16:09:10 +0000 Received: from [65.55.175.195] (helo=blu139-omc2-s25.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNVml-000E2k-Sz for radiusext@ops.ietf.org; Fri, 08 Feb 2008 16:09:09 +0000 Received: from BLU137-W42 ([65.55.162.184]) by blu139-omc2-s25.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Feb 2008 08:09:07 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_817f26f1-f645-4f53-a413-c327529cae9d_" X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: "David B. Nelson" CC: Alan DeKok , Stefan Winter , Alan DeKok , Subject: RE: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 08:09:07 -0800 Importance: Normal In-Reply-To: <47AC6789.4050002@elbrysnetworks.com> References: <200802080933.49040.stefan.winter@restena.lu> <200802081056.29687.stefan.winter@restena.lu> <47AC28B1.3030205@nitros9.org> <200802081115.00527.stefan.winter@restena.lu> <47AC2D89.1060604@deployingradius.com> <47AC6789.4050002@elbrysnetworks.com> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2008 16:09:07.0354 (UTC) FILETIME=[EEAF57A0:01C86A6C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_817f26f1-f645-4f53-a413-c327529cae9d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To even know whether the packets are IPsec/IKE, it would be necessary to re= assemble them. So I don't see how they could be treated differently.=20 > Date: Fri, 8 Feb 2008 09:30:33 -0500 > From: dnelson@elbrysnetworks.com > To: bernard_aboba@hotmail.com > CC: aland@deployingradius.com; stefan.winter@restena.lu; aland@nitros9.or= g; radiusext@ops.ietf.org > Subject: Re: draft-winter-radsec-01 published >=20 > Bernard Aboba wrote: >=20 > > BTW, how does IPsec solve the fragmentation problem for RADIUS? >=20 > Maybe it prevents the "broken" firewalls from peeking into the packets,=20 > seeing UDP fragments, and dropping them. They skate by via means of an=20 > IPsec pass through feature. Just a guess. >=20 --_817f26f1-f645-4f53-a413-c327529cae9d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To even know whet= her the packets are IPsec/IKE, it would be necessary to reassemble them.&nb= sp; So
I don't see how they could be treated differently.
> Date: Fri, 8 Feb 2008 09:30:33 -0500
> From: dnelson@elbrysnetw= orks.com
> To: bernard_aboba@hotmail.com
> CC: aland@deployingr= adius.com; stefan.winter@restena.lu; aland@nitros9.org; radiusext@ops.ietf.= org
> Subject: Re: draft-winter-radsec-01 published
>
> = Bernard Aboba wrote:
>
> > BTW, how does IPsec solve the fr= agmentation problem for RADIUS?
>
> Maybe it prevents the "bro= ken" firewalls from peeking into the packets,
> seeing UDP fragments= , and dropping them. They skate by via means of an
> IPsec pass thr= ough feature. Just a guess.
>
= --_817f26f1-f645-4f53-a413-c327529cae9d_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Feb 9 00:08:39 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA8E3A764A for ; Sat, 9 Feb 2008 00:08:39 -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 core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB5AedF7GGBU for ; Sat, 9 Feb 2008 00:08:39 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0566B3A6FFA for ; Sat, 9 Feb 2008 00:08:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNkeU-000OnB-Ql for radiusext-data@psg.com; Sat, 09 Feb 2008 08:01:34 +0000 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JNkeS-000Omy-E9 for radiusext@ops.ietf.org; Sat, 09 Feb 2008 08:01:33 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id A91DCA704E; Sat, 9 Feb 2008 00:01:23 -0800 (PST) Message-ID: <47AD5D3A.8040806@nitros9.org> Date: Sat, 09 Feb 2008 08:58:50 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: "David B. Nelson" , Stefan Winter , radiusext@ops.ietf.org Subject: Re: draft-winter-radsec-01 published References: <200802080933.49040.stefan.winter@restena.lu> <200802081056.29687.stefan.winter@restena.lu> <47AC28B1.3030205@nitros9.org> <200802081115.00527.stefan.winter@restena.lu> <47AC2D89.1060604@deployingradius.com> <47AC6789.4050002@elbrysnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba wrote: > To even know whether the packets are IPsec/IKE, it would be necessary to > reassemble them. So > I don't see how they could be treated differently. They won't. But administrators can lower the MTU for IPSec connections until it "just works". At that point, protocols transported inside of IPSec are fine. This can't be done on the supplicant, because it only sees it's local MTU. There is no feedback mechanism to lower this MTU to account for later RADIUS encapsulation. The IPSec solution is less about automated path MTU discovery than administrator trial and error until "it seems to work". Adding a feedback mechanism to EAP for MTU could be useful. The only reasonable place to put this information is in the first packet sent by the EAP server. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Feb 10 12:54:17 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEC03A68B6 for ; Sun, 10 Feb 2008 12:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3ixgMQpkWoA for ; Sun, 10 Feb 2008 12:54:16 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 952B23A67B3 for ; Sun, 10 Feb 2008 12:54:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOJ3d-0002Jw-Ok for radiusext-data@psg.com; Sun, 10 Feb 2008 20:45:49 +0000 Received: from [65.55.175.184] (helo=blu139-omc2-s14.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOJ3a-0002JN-NO for radiusext@ops.ietf.org; Sun, 10 Feb 2008 20:45:48 +0000 Received: from BLU137-W10 ([65.55.162.184]) by blu139-omc2-s14.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Feb 2008 12:45:45 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d08605a4-ce3b-4a52-bd70-e9d3530fdd11_" X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Alan DeKok , 'radext mailing list' Subject: RE: Review of RADIUS Design Guidelines document Date: Sun, 10 Feb 2008 12:45:46 -0800 Importance: Normal In-Reply-To: <479E07B1.9040806@deployingradius.com> References: <479E07B1.9040806@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2008 20:45:45.0922 (UTC) FILETIME=[E9075220:01C86C25] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_d08605a4-ce3b-4a52-bd70-e9d3530fdd11_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Hmm... I'm trying to come up with something that the WG could agree > with, but which isn't banal to the point of being meaningless. >=20 > The comments about the State attribute are a good start. =20 [BA] Yes, because they relate to fundamental assumptions of the protocol de= sign.=20 > Other points are: >=20 > - RADIUS is a transport protocol for authentication credentials, > authorization information, and accounting data for user sessions [BA] Is this implying a requirement for a user session to be in progress at a NAS that originates a request? Or is it a statement relating to=20 the kinds of purposes for which attributes can be used?=20 > - authorization is possible only after a session has been successfully > authenticated [BA] Is this a statement about what messages authorizations can be included within (e.g. Access-Reject or Access-Challenge messages)? > - the protocol is "hop by hop", and not "end to end" [BA] There are protocol elements (e.g. NAS-Identifier, NAS-IP-Address, NAS-IPv6-Address) that refer to the original NAS. However, other fields (Message-Authenticator, Proxy-State, Authenticator field) are recalculated = by=20 intermediate nodes. How should specifications think about these distinctions? =20 > - all data transported by RADIUS is visible to all intermediate nodes [BA] Is this a design principle, or just a statement of how things currentl= y work?=20 > - authentication servers do not have to be co-located with accounting > servers > - no action may be taken on Access-Reject other than disconnecting the > user session that was attempting authentication > - no information may be sent in an Accounting-Response > - Any PDU may not reach it's intended destination. Implementations > should be robust in the event of lost, missing, or incomplete information [BA] These seem reasonable.=20 >=20 > Suggestions for more? [BA] It might be worth saying that RADIUS attribute specifications do not d= efine services, they describe how services that have already been defined should be provisioned.=20 >=20 > > Given the concern about SHA-1 collisions, is it worth recommending > > against use of this algorithm in new attributes? >=20 > Yes. >=20 > > I also something might be worth saying about the use of RADIUS without > > user authentication. >=20 > This can be mentioned as part of the set of assumptions. >=20 > > Section 1 > >=20 > > Suggest changing: ... To: ... >=20 > Looks good to me. >=20 >=20 > > Section 5 > >=20 > > Suggest changing ... To: ... >=20 > Looks good to me. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --_d08605a4-ce3b-4a52-bd70-e9d3530fdd11_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  > Hmm... I'm trying to come up with something that the WG could = agree
> with, but which isn't banal to the point of being meaningless= .
>
> The comments about the State attribute are a good star= t.

[BA] Yes, because they relate to fundamental assumptions of the= protocol design.

> Other points are:
>
> - RADIUS= is a transport protocol for authentication credentials,
> authorizat= ion information, and accounting data for user sessions

[BA]  Is= this implying a requirement for a user session to be in progress
at a N= AS that originates a request?  Or is it a statement relating to
th= e kinds of purposes for which attributes can be used?

> - autho= rization is possible only after a session has been successfully
> aut= henticated

[BA] Is this a statement about what messages authorizatio= ns can be
included within (e.g. Access-Reject or Access-Challenge messag= es)?

> - the protocol is "hop by hop", and not "end to end"
<= br>[BA]  There are protocol elements (e.g. NAS-Identifier, NAS-IP-Addr= ess,
NAS-IPv6-Address) that refer to the original NAS.  However, ot= her fields
(Message-Authenticator, Proxy-State, Authenticator field) are= recalculated by
intermediate nodes.  How should specifications th= ink about these
distinctions? 

> - all data transported= by RADIUS is visible to all intermediate nodes

[BA] Is this a desig= n principle, or just a statement of how things currently
work?

&= gt; - authentication servers do not have to be co-located with accounting<= br>> servers
> - no action may be taken on Access-Reject other th= an disconnecting the
> user session that was attempting authenticatio= n
> - no information may be sent in an Accounting-Response
> = - Any PDU may not reach it's intended destination. Implementations
>= should be robust in the event of lost, missing, or incomplete information<= br>
[BA] These seem reasonable.

>
> Suggestions for = more?

[BA] It might be worth saying that RADIUS attribute specificat= ions do not define
services, they describe how services that have alread= y been defined should
be provisioned.

>
> > Given t= he concern about SHA-1 collisions, is it worth recommending
> > ag= ainst use of this algorithm in new attributes?
>
> Yes.
&= gt;
> > I also something might be worth saying about the use of R= ADIUS without
> > user authentication.
>
> This can= be mentioned as part of the set of assumptions.
>
> > Sect= ion 1
> >
> > Suggest changing: ... To: ...
>
= > Looks good to me.
>
>
> > Section 5
> &= gt;
> > Suggest changing ... To: ...
>
> Looks goo= d to me.
>
> Alan DeKok.
>
> --
> to unsu= bscribe send a message to radiusext-request@ops.ietf.org with
> the w= ord 'unsubscribe' in a single line as the message text body.
> archiv= e: <http://psg.com/lists/radiusext/>
= --_d08605a4-ce3b-4a52-bd70-e9d3530fdd11_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Feb 10 12:55:45 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81AE43A6854 for ; Sun, 10 Feb 2008 12:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.857 X-Spam-Level: X-Spam-Status: No, score=-3.857 tagged_above=-999 required=5 tests=[AWL=1.742, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Thwf9CwyzeAe for ; Sun, 10 Feb 2008 12:55:44 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A10A53A6807 for ; Sun, 10 Feb 2008 12:55:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOJ8K-0003KQ-6i for radiusext-data@psg.com; Sun, 10 Feb 2008 20:50:40 +0000 Received: from [65.55.175.211] (helo=blu139-omc3-s11.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOJ8H-0003Jq-K3 for radiusext@ops.ietf.org; Sun, 10 Feb 2008 20:50:38 +0000 Received: from BLU137-W28 ([65.55.162.188]) by blu139-omc3-s11.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Feb 2008 12:50:36 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_9e27425a-f09b-415e-8201-cabdf6471a42_" X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Subject: REMINDER: Ongoing RADEXT WG last call on the Extended RADIUS Attributes document Date: Sun, 10 Feb 2008 12:50:36 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2008 20:50:36.0873 (UTC) FILETIME=[9672EB90:01C86C26] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_9e27425a-f09b-415e-8201-cabdf6471a42_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a reminder of the ongoing RADEXT WG last call on the Extended RADIU= S Attributes document, prior to sending it to the IESG for consideration as a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-0= 0.txt RADEXT WG last call will last until February 14, 2008. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/= --_9e27425a-f09b-415e-8201-cabdf6471a42_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a reminder of the ongoing RADEXT WG last call on the Extended RADIU= S Attributes document, prior to sending it to the IESG for consideration as a Proposed Standard.   The document is available for inspectio= n here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-a= ttributes-00.txt

RADEXT WG last call will last until February 14, 2008.  Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RA= DEXT/ = --_9e27425a-f09b-415e-8201-cabdf6471a42_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 11 02:28:15 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1AA3A6AEA for ; Mon, 11 Feb 2008 02:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk9U1ZQVaf7W for ; Mon, 11 Feb 2008 02:28:11 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0F4693A6AFF for ; Mon, 11 Feb 2008 02:28:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOVpe-000EmD-PG for radiusext-data@psg.com; Mon, 11 Feb 2008 10:24:14 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOVpb-000Eln-N9 for radiusext@ops.ietf.org; Mon, 11 Feb 2008 10:24:13 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7E25676F44; Mon, 11 Feb 2008 11:24:10 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 6E1A276F43; Mon, 11 Feb 2008 11:24:10 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: Bernard Aboba Subject: Re: draft-winter-radsec-01 published Date: Mon, 11 Feb 2008 11:24:09 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Alan DeKok , radiusext@ops.ietf.org References: <200802080933.49040.stefan.winter@restena.lu> <47AC2D89.1060604@deployingradius.com> In-Reply-To: X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart10647522.34XRZU3o58 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > To be clear, this fragmentation issue is a problem for RADIUS, but not > RADSEC, correct? I'd assume that TCP MSS negotiation combined with > Packetization Layer Path MTU discovery should make fragmentation of TCP > segments relatively unlikely. That is correct, a reliable transport makes this problem go away, or at lea= st=20 makes life a lot easier in that respect. Still, even though I'm quite=20 enthusiastic about RadSec, I can still imagine people using just plain RADI= US=20 who suffer from that problem. > BTW, how does IPsec solve the fragmentation problem for RADIUS? Couldn't > it make it worse? As I don't use RADIUS-over-IPSec myself, I asked one of our national eduroa= m=20 operators for his practical experiences in that respect. I'll keep you=20 posted. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart10647522.34XRZU3o58 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHsCJJ+jm90f8eFWYRArQBAJ9piHxogql8ZyjPxzQ9bILKn7//OwCeOLS7 VERHiTRVj7YK9a0oevAr0bk= =Tyfc -----END PGP SIGNATURE----- --nextPart10647522.34XRZU3o58-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 11 02:28:32 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340F03A6B01 for ; Mon, 11 Feb 2008 02:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.69 X-Spam-Level: X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6m6fOlT4pX0 for ; Mon, 11 Feb 2008 02:28:23 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8DD543A6895 for ; Mon, 11 Feb 2008 02:28:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOVrs-000F0e-IW for radiusext-data@psg.com; Mon, 11 Feb 2008 10:26:32 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOVrm-000F06-Go for radiusext@ops.ietf.org; Mon, 11 Feb 2008 10:26:31 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C813376F44 for ; Mon, 11 Feb 2008 11:26:25 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id BBE4E76F43 for ; Mon, 11 Feb 2008 11:26:25 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org Subject: request to recharter Date: Mon, 11 Feb 2008 11:26:25 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart2525371.U1nnMiPe13 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, the topic of re-chartering radiusext to accomodate the RadSec work has been= a=20 continuous topic in the last two meetings, the mailing list and in several= =20 offline discussions. The last meeting in Vancouver suggested to move the three most promising=20 crypto-agility suggestions (keywrap, dtls, radsec) to EXP status within=20 radext. RadSec is being implemented in various independent codebases and is in=20 production use today. The points above make me think that it is about time to seriously consider= =20 that the radext charter is modified to include RadSec into the working grou= p=20 scope. The DTLS draft led to consensus that TLS-style payload encryption is not=20 considered being a new security mechanism for protecting RADIUS (which woul= d=20 be excluded by the charter as-is). Then, the same holds true for the TLS pa= rt=20 of the radsec draft, which in turn means this part of the charter does not= =20 need changing. The only part in the charter that would need to be changed is, obviously, t= he=20 line "- No new RADIUS transports (e.g. TCP, SCTP) will be defined." which I request to purge from the charter. After being included in the radext WG scope, the radsec draft would certain= ly=20 be rewritten for more normative wording. Because up to now, it was meant as= =20 an FYI description of existing implementations, not in any way a standard.= =20 When EXP is a target, language should change accordingly. I volunteer to do= =20 this to the best of my knowledge - it is my first I-D at all. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart2525371.U1nnMiPe13 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHsCLR+jm90f8eFWYRAlIYAJ0cwdUYqMqNM2Mnt821y/veSM9SewCfdjnh vmxO0DOuKD0gmbJFBnrwKXU= =R8zv -----END PGP SIGNATURE----- --nextPart2525371.U1nnMiPe13-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 11 02:39:48 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495B33A6AF0 for ; Mon, 11 Feb 2008 02:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVFBOlmIfgA2 for ; Mon, 11 Feb 2008 02:39:47 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 997AC3A6B00 for ; Mon, 11 Feb 2008 02:39:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOW29-000GAE-BM for radiusext-data@psg.com; Mon, 11 Feb 2008 10:37:09 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOW26-000G9t-Gp for radiusext@ops.ietf.org; Mon, 11 Feb 2008 10:37:08 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id B876776F44; Mon, 11 Feb 2008 11:37:05 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id AD0AB76F42; Mon, 11 Feb 2008 11:37:05 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: Bernard Aboba Subject: Re: draft-winter-radsec-01 published Date: Mon, 11 Feb 2008 11:37:04 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Alan DeKok , radiusext@ops.ietf.org References: <200802080933.49040.stefan.winter@restena.lu> <200802111124.09919.stefan.winter@restena.lu> In-Reply-To: <200802111124.09919.stefan.winter@restena.lu> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart1509223.T8BsIcjxoV Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > As I don't use RADIUS-over-IPSec myself, I asked one of our national > eduroam operators for his practical experiences in that respect. I'll keep > you posted. I got: "I've seen fragmentation problems on IPsec only once, and that quite long ago so I can't recall more info than it was related to CISCO PIX FW in situation when we were using both AH and ESP headers. After droping AH it started working reliably. That time I realized that AH headers are not necessary and now we are using only ESP. [...] I'm doing from time to time test with big EAP requests to be sure that our Czech eduroam is running on correctly setup network. When I discover problem I ask admins to fix that. So far I never had to disconnect anyone for this incompatibility." Which looks like forcing admins to tweak stuff until it works. Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart1509223.T8BsIcjxoV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHsCVR+jm90f8eFWYRAptbAJ48ldtV4EjKyllBu2KNtG8phyEC/QCeIBiM s6KctBCciclNz7bwIFcJUro= =9urz -----END PGP SIGNATURE----- --nextPart1509223.T8BsIcjxoV-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 11 17:12:32 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438383A68C2 for ; Mon, 11 Feb 2008 17:12:32 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ+Wcmq6zfjR for ; Mon, 11 Feb 2008 17:12:31 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4B7593A682E for ; Mon, 11 Feb 2008 17:12:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOjZK-000Kk3-Ar for radiusext-data@psg.com; Tue, 12 Feb 2008 01:04:18 +0000 Received: from [76.96.30.17] (helo=QMTA10.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOjZH-000Kji-Tl for radiusext@ops.ietf.org; Tue, 12 Feb 2008 01:04:17 +0000 Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id oQw71Y0020EPchoAA01s00; Tue, 12 Feb 2008 01:03:39 +0000 Received: from gzornt61 ([124.120.221.174]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id oR3t1Y00M3mNAXQ8M00000; Tue, 12 Feb 2008 01:04:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=EzrpwxPfZxGxtMX5siIA:9 a=yeZjmhicef1VKm6iTkgA:7 a=zFdoyY0iU1bGQ-cYEjA5OudzwI8A:4 a=ufO146cb3fEA:10 From: "Glen Zorn" To: "'Stefan Winter'" , References: <200802111126.25340.stefan.winter@restena.lu> Subject: RE: request to recharter Date: Tue, 12 Feb 2008 08:03:49 +0700 Message-ID: <008b01c86d13$290663f0$aedd787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200802111126.25340.stefan.winter@restena.lu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchsmO0sxJh8DZt2QmSwaf2B7i/MqgAeHcSA Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter <> scribbled on Monday, February 11, 2008 5:26 PM: > Hello, > > the topic of re-chartering radiusext to accomodate the RadSec work > has been a continuous topic in the last two meetings, the mailing > list and in several offline discussions. Yes, there has been a popular upswell of support for abandoning our work in favor of yours -- oh, wait, that would be you alone... > The last meeting in Vancouver suggested to move the three most > promising crypto-agility suggestions (keywrap, dtls, radsec) to EXP > status within radext. > RadSec is being implemented in various independent codebases and is > in production use today. > > The points above make me think that it is about time to seriously > consider that the radext charter is modified to include RadSec into > the working group scope. Yes, there has been a popular upswell of support for abandoning our work in favor of yours -- oh, wait, that would be you again... > > The DTLS draft led to consensus that TLS-style payload encryption is > not considered being a new security mechanism for protecting RADIUS > (which would be excluded by the charter as-is). Then, the same holds > true for the TLS part of the radsec draft, which in turn means this > part of the charter does not need changing. > > The only part in the charter that would need to be changed is, > obviously, the line > > "- No new RADIUS transports (e.g. TCP, SCTP) will be defined." > > which I request to purge from the charter. No, no, NO! "radsec" is not RADIUS, period. Not an extension, not even a perversion, not RADIUS. I would support a radsec BOF & WG, but I will not support this. > > After being included in the radext WG scope, the radsec draft would > certainly be rewritten for more normative wording. Because up to now, > it was meant as an FYI description of existing implementations, not > in any way a standard. > When EXP is a target, language should change accordingly. I volunteer > to do this to the best of my knowledge - it is my first I-D at all. > > Greetings, > > Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 11 18:19:56 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86C73A68C2 for ; Mon, 11 Feb 2008 18:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.921, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mfGtNIbb4G8 for ; Mon, 11 Feb 2008 18:19:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EF16E3A687E for ; Mon, 11 Feb 2008 18:19:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOkdY-0000Um-R8 for radiusext-data@psg.com; Tue, 12 Feb 2008 02:12:44 +0000 Received: from [65.55.175.157] (helo=blu139-omc1-s17.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOkdW-0000UG-6t for radiusext@ops.ietf.org; Tue, 12 Feb 2008 02:12:43 +0000 Received: from BLU127-DS3 ([65.55.162.183]) by blu139-omc1-s17.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Feb 2008 18:12:41 -0800 X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" In-Reply-To: <200802111126.25340.stefan.winter@restena.lu> <008b01c86d13$290663f0$aedd787c@arubanetworks.com> To: "'Stefan Winter'" , References: <200802111126.25340.stefan.winter@restena.lu> <008b01c86d13$290663f0$aedd787c@arubanetworks.com> Subject: Re: request to recharter Date: Mon, 11 Feb 2008 18:12:41 -0800 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 12 Feb 2008 02:12:41.0403 (UTC) FILETIME=[BF2DF0B0:01C86D1C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk > Yes, there has been a popular upswell of support for abandoning our work > in favor of yours -- oh, wait, that would be you again... [BA] Completion of the existing RADEXT WG work items has always been a precondition for re-chartering. There has never been a discussion of "abandoning" existing work items. Once the Design Guidelines, Management Attributes and Extended Attributes documents complete WG last call and are forwarded to the IESG, the remaining work items left will be the IEEE 802 attributes document, and the Crypto-agility draft. At that point a discussion of Re-Chartering would be appropriate. > No, no, NO! "radsec" is not RADIUS, period. Not an extension, not even > a perversion, not RADIUS. I would support a radsec BOF & WG, but I will > not support this. [BA] The IETF process involves "rough consensus and running code". During the RADEXT WG re-charter discussion, the opinion of all WG participants will be taken into account. With respect to RADSEC, the minutes of IETF 69 show that as part of the crypto-agility portion of the meeting, there was a consensus call on potential solutions, and that RADSEC got considerable support. We did not follow up with a consensus call on the list since RADSEC was outside the RADEXT WG charter. However, during a re-charter discussion, this and other potential WG work items will be open to discussion. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 11 18:29:48 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBBF03A69BF for ; Mon, 11 Feb 2008 18:29:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+R1PdyEUZFx for ; Mon, 11 Feb 2008 18:29:47 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id AA51D3A68C2 for ; Mon, 11 Feb 2008 18:28:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOkpo-0001az-Dp for radiusext-data@psg.com; Tue, 12 Feb 2008 02:25:24 +0000 Received: from [76.96.30.56] (helo=QMTA06.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOkpm-0001aj-3F for radiusext@ops.ietf.org; Tue, 12 Feb 2008 02:25:23 +0000 Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id oLuc1Y00A0lTkoCA60LZ00; Tue, 12 Feb 2008 02:25:09 +0000 Received: from gzornt61 ([124.120.221.174]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id oSR31Y00P3mNAXQ8Q00000; Tue, 12 Feb 2008 02:25:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=5ug3leTaZO15GJfnEZ0A:9 a=Coed-Q8GIVqaR0Z63I4A:7 a=IiJCNgloRMIS-t5IviACQNUvDVcA:4 a=c5zHXd76wwQA:10 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Stefan Winter'" , References: <200802111126.25340.stefan.winter@restena.lu> <008b01c86d13$290663f0$aedd787c@arubanetworks.com> Subject: RE: request to recharter Date: Mon, 11 Feb 2008 18:24:59 -0800 Message-ID: <00a601c86d1e$807a8a20$aedd787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchtHUWlUay6LIOYRjOpYYiiBPXpigAAKw/Q Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba <> scribbled on Monday, February 11, 2008 6:13 PM: >> Yes, there has been a popular upswell of support for abandoning our >> work in favor of yours -- oh, wait, that would be you again... > > [BA] Completion of the existing RADEXT WG work items has always been a > precondition for re-chartering. There has never been a discussion of > "abandoning" existing work items. I didn't say "work items", I said "work", meaning RADIUS. This is a new & different protocol, more akin to Diameter than RADIUS & does not belong in this WG. > Once the Design Guidelines, > Management Attributes and Extended Attributes documents complete WG > last call and are forwarded to the IESG, the remaining work items > left will be the IEEE 802 attributes document, and the Crypto-agility > draft. > > At that point a discussion of Re-Chartering would be appropriate. > >> No, no, NO! "radsec" is not RADIUS, period. Not an extension, not >> even a perversion, not RADIUS. I would support a radsec BOF & WG, >> but I will not support this. > > [BA] The IETF process involves "rough consensus and running code". > During the RADEXT WG re-charter discussion, the opinion of all WG > participants will be taken into account. > > With respect to RADSEC, the minutes of IETF 69 show that as part of > the crypto-agility portion of the meeting, there was a consensus call > on > potential solutions, and that RADSEC got considerable support. > We did not follow up with a consensus call on the list since > RADSEC was outside the RADEXT WG charter. However, > during a re-charter discussion, this and other potential WG work > items will be open to discussion. Fine, just change the WG name "radsec" as well. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 11 20:36:07 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47DB3A6802 for ; Mon, 11 Feb 2008 20:36:07 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzPjXuxjH4y4 for ; Mon, 11 Feb 2008 20:36:06 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 950203A6B5F for ; Mon, 11 Feb 2008 20:36:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOmnF-000BsK-DP for radiusext-data@psg.com; Tue, 12 Feb 2008 04:30:53 +0000 Received: from [209.85.198.187] (helo=rv-out-0910.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOmnC-000Bs0-Ow for radiusext@ops.ietf.org; Tue, 12 Feb 2008 04:30:52 +0000 Received: by rv-out-0910.google.com with SMTP id b22so4335803rvf.41 for ; Mon, 11 Feb 2008 20:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=OZ6BYPysRViGx9smcGB1bwcYKfEIDOZo7qY7GXEn3E4=; b=nwgSZgi/LAaxXvtbSmOJ3Uv7KpSV/4jmUBuGjRXXYwwty4UvTKCn2VCwUbGNiu4vOg1P+YpeidEndx1gOXt3pSvkUWQYEKIBEvbn8vGVqGg6aGKjentdMvWVZOxQeZpb1ic8glb5ESItATUGcP+LDfSWZFgzyz6Aetn/AfOil/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=K6tAd4u+6XAafcryGFKj2qMj6jj3YxGAa0uy/MyTlCRuv5inmDc5ylyE9NM28MG38rj/bnbkpf2Vm8YnumjD461sVLpupYIED7rk3asNwFu3elrgPvr715kouCUlElW1GAirZ8H4s7/1gwDAvvfIY11LmZVRUzqDkm6D0+fh/Lg= Received: by 10.140.180.13 with SMTP id c13mr591659rvf.188.1202790650627; Mon, 11 Feb 2008 20:30:50 -0800 (PST) Received: by 10.141.34.1 with HTTP; Mon, 11 Feb 2008 20:30:50 -0800 (PST) Message-ID: Date: Mon, 11 Feb 2008 23:30:50 -0500 From: "Greg Weber" To: radiusext@ops.ietf.org Subject: LC cmts: Extended Attrs MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-radiusext@ops.ietf.org Precedence: bulk I have some comments on: draft-ietf-radext-extended-attributes-00.txt * In section 5, the Ext-Length field is defined as the length of the Extended Attribute. I think you mean it's the length of the TLV (multiple TLVs can be in the Extended Attribute). I think that would make the value ">=3", not ">=4". * It's probably worth calling out any artifacts of overloading attribute 26 which wouldn't apply to standard attributes in the original number space (or apply to overloading a new attribute instead of 26). For example, attribute 26 is already specifically excluded from some RADIUS message types, e.g. CoA-NAK, so new Extended Attributes couldn't be included in those messages, but new standard attribute could be. Also, are malformed VSAs always treated just like malformed non-VSAs? * I think it would be useful to explicitly mention if recursive grouping is allowed and that Extended Attributes cannot be grouped with non-Extended Attributes. * It's probably useful to mention what happens when an Extended Attribute's tag is non-zero and it contains multiple TLVs (this does not seem to be excluded -as multiple TLVs are when the M-bit is on). * RFC2865 specifically calls out the proxies can't reorder attributes of the same type; does this doc need to create the same restriction for Ext-Type? * I actually didn't have a lot of editorial comments :-) Possibly the M-bit could be renamed to avoid potential confusion with Diameter. Greg On Feb 10, 2008 3:50 PM, Bernard Aboba wrote: > > This is a reminder of the ongoing RADEXT WG last call on the Extended > RADIUS Attributes document, prior to sending it to the IESG for > consideration as a Proposed Standard. The document is available for > inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00.txt > > RADEXT WG last call will last until February 14, 2008. Please send comments > to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format > described on the RADEXT WG Issues page: > http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 11 22:27:52 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295FF3A6BBA for ; Mon, 11 Feb 2008 22:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=1.975, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeUXw5CjKxOX for ; Mon, 11 Feb 2008 22:27:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D2AFA3A6AE5 for ; Mon, 11 Feb 2008 22:27:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOoTY-000J7P-Q1 for radiusext-data@psg.com; Tue, 12 Feb 2008 06:18:40 +0000 Received: from [65.55.175.147] (helo=blu139-omc1-s7.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOoTV-000J73-TD for radiusext@ops.ietf.org; Tue, 12 Feb 2008 06:18:39 +0000 Received: from BLU137-W26 ([65.55.162.183]) by blu139-omc1-s7.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 11 Feb 2008 22:18:37 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_a47af0b9-587b-413c-8d6b-95d15e55a8d5_" X-Originating-IP: [131.107.0.71] From: Bernard Aboba To: Greg Weber , Subject: RE: LC cmts: Extended Attrs Date: Mon, 11 Feb 2008 22:18:37 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2008 06:18:37.0136 (UTC) FILETIME=[1A481D00:01C86D3F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_a47af0b9-587b-413c-8d6b-95d15e55a8d5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have some additional comments on the document: =20 1. Diameter Considerations. There currently is no Diameter Considerations = section.=20 One issue that arises is how to map the Extended Attribute space into the D= iameter attribute space. Since Diameter AVP numbers have been assigned with codes = >255, the mapping requires an offset to be added to RADIUS Extended Attribute cod= es. Off the top of my head, I am clear what this offset should be.=20 =20 Also, I think there is the issue of how the extended grouped attributes are= mapped into grouped Diameter AVPs. =20 =20 2. IANA considerations. The text in the current document is minimal, and = I think there is room for considerably more discussion there. Given the potential differences in treatment of attributes within the VSA space and standard RADIUS attributes, I think that the IANA = considerations should indicate that Extended Attributes should initially be allocated only= on request.=20 However, as the standard RADIUS attribute space is exhausted, there will ev= entually be no choice but to allocate out of the extended space. The question is ho= w attributes should be allocated. > Date: Mon, 11 Feb 2008 23:30:50 -0500> From: gdwebe= r@gmail.com> To: radiusext@ops.ietf.org> Subject: LC cmts: Extended Attrs> = > I have some comments on: draft-ietf-radext-extended-attributes-00.txt> > = * In section 5, the Ext-Length field is defined as the length of the Extend= ed> Attribute. I think you mean it's the length of the TLV (multiple TLVs c= an be> in the Extended Attribute). I think that would make the value ">=3D3= ", not ">=3D4".> > * It's probably worth calling out any artifacts of overl= oading attribute 26> which wouldn't apply to standard attributes in the ori= ginal number space> (or apply to overloading a new attribute instead of 26)= . For example,> attribute 26 is already specifically excluded from some RAD= IUS message> types, e.g. CoA-NAK, so new Extended Attributes couldn't be in= cluded in> those messages, but new standard attribute could be. Also, are m= alformed> VSAs always treated just like malformed non-VSAs?> > * I think it= would be useful to explicitly mention if recursive grouping is> allowed an= d that Extended Attributes cannot be grouped with non-Extended> Attributes.= > > * It's probably useful to mention what happens when an Extended Attribu= te's> tag is non-zero and it contains multiple TLVs (this does not seem to = be> excluded -as multiple TLVs are when the M-bit is on).> > * RFC2865 spec= ifically calls out the proxies can't reorder attributes> of the same> type;= does this doc need to create the same restriction for Ext-Type?> > * I act= ually didn't have a lot of editorial comments :-) Possibly the M-bit> could= be renamed to avoid potential confusion with Diameter.> > Greg> > > On Feb= 10, 2008 3:50 PM, Bernard Aboba wrote:> >> > T= his is a reminder of the ongoing RADEXT WG last call on the Extended> > RAD= IUS Attributes document, prior to sending it to the IESG for> > considerati= on as a Proposed Standard. The document is available for> > inspection here= :> > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribu= tes-00.txt> >> > RADEXT WG last call will last until February 14, 2008. Ple= ase send comments> > to the RADEXT WG mailing list (radiusext@ops.ietf.org)= in the format> > described on the RADEXT WG Issues page:> > http://www.dri= zzle.com/~aboba/RADEXT/> > --> to unsubscribe send a message to radiusext-r= equest@ops.ietf.org with> the word 'unsubscribe' in a single line as the me= ssage text body.> archive: = --_a47af0b9-587b-413c-8d6b-95d15e55a8d5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have some additional comments on the document:
 
1. Diameter Considerations.  There currently is no Diameter Considerat= ions section.
One issue that arises is how to map the Extended Attribute space into the D= iameter
attribute space.  Since Diameter AVP numbers have been assigned with c= odes >255,
the mapping requires an offset to be added to RADIUS Extended Attribute cod= es.
Off the top of my head, I am clear what this offset should be.
 
Also, I think there is the issue of how the extended grouped attributes are= mapped
into grouped Diameter AVPs. 
 
2. IANA considerations.   The text in the current document is min= imal, and I think
there is room for considerably more discussion there.
Given the potential differences in treatment of attributes
within the VSA space and standard RADIUS attributes, I think that the IANA = considerations
should indicate that Extended Attributes should initially be allocated only= on request.
However, as the standard RADIUS attribute space is exhausted, there will ev= entually
be no choice but to allocate out of the extended space.  The question = is how attributes
should be allocated. 

> Date: Mon, 11 Feb 2008 23:30:50 -05= 00
> From: gdweber@gmail.com
> To: radiusext@ops.ietf.org
&g= t; Subject: LC cmts: Extended Attrs
>
> I have some comments o= n: draft-ietf-radext-extended-attributes-00.txt
>
> * In secti= on 5, the Ext-Length field is defined as the length of the Extended
>= Attribute. I think you mean it's the length of the TLV (multiple TLVs can = be
> in the Extended Attribute). I think that would make the value "&= gt;=3D3", not ">=3D4".
>
> * It's probably worth calling ou= t any artifacts of overloading attribute 26
> which wouldn't apply to= standard attributes in the original number space
> (or apply to over= loading a new attribute instead of 26). For example,
> attribute 26 i= s already specifically excluded from some RADIUS message
> types, e.g= . CoA-NAK, so new Extended Attributes couldn't be included in
> those= messages, but new standard attribute could be. Also, are malformed
>= VSAs always treated just like malformed non-VSAs?
>
> * I thi= nk it would be useful to explicitly mention if recursive grouping is
>= ; allowed and that Extended Attributes cannot be grouped with non-Extended<= BR>> Attributes.
>
> * It's probably useful to mention what= happens when an Extended Attribute's
> tag is non-zero and it contai= ns multiple TLVs (this does not seem to be
> excluded -as multiple TL= Vs are when the M-bit is on).
>
> * RFC2865 specifically calls= out the proxies can't reorder attributes
> of the same
> type;= does this doc need to create the same restriction for Ext-Type?
> > * I actually didn't have a lot of editorial comments :-) Possibly th= e M-bit
> could be renamed to avoid potential confusion with Diameter= .
>
> Greg
>
>
> On Feb 10, 2008 3:50 PM, = Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> >
>= > This is a reminder of the ongoing RADEXT WG last call on the Extended=
> > RADIUS Attributes document, prior to sending it to the IESG f= or
> > consideration as a Proposed Standard. The document is avail= able for
> > inspection here:
> > http://www.ietf.org/int= ernet-drafts/draft-ietf-radext-extended-attributes-00.txt
> >
&= gt; > RADEXT WG last call will last until February 14, 2008. Please send= comments
> > to the RADEXT WG mailing list (radiusext@ops.ietf.or= g) in the format
> > described on the RADEXT WG Issues page:
&g= t; > http://www.drizzle.com/~aboba/RADEXT/
>
> --
> t= o unsubscribe send a message to radiusext-request@ops.ietf.org with
>= the word 'unsubscribe' in a single line as the message text body.
> = archive: <http://psg.com/lists/radiusext/>

= --_a47af0b9-587b-413c-8d6b-95d15e55a8d5_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 12 05:25:02 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA18E28C21D for ; Tue, 12 Feb 2008 05:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh8kTQJAFJPY for ; Tue, 12 Feb 2008 05:25:01 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4C57828C1FD for ; Tue, 12 Feb 2008 05:25:01 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOv21-0003iE-Jz for radiusext-data@psg.com; Tue, 12 Feb 2008 13:18:41 +0000 Received: from [76.96.62.56] (helo=QMTA06.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOv1x-0003hL-CD for radiusext@ops.ietf.org; Tue, 12 Feb 2008 13:18:39 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA06.westchester.pa.mail.comcast.net with comcast id obvG1Y00216LCl05605G00; Tue, 12 Feb 2008 13:18:22 +0000 Received: from gzornt61 ([124.120.230.227]) by OMTA06.westchester.pa.mail.comcast.net with comcast id odJG1Y00B4v1YFw3S00000; Tue, 12 Feb 2008 13:18:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=Cv6e0pkHAAAA:8 a=No5EcEP4AAAA:8 a=GlhhHl8CrVWxkqo7YFUA:9 a=P8ttVjzdRwFzP7Z-qsMA:7 a=AzMFAGkU1sz61GIkUObPrNvP5vMA:4 a=MSl-tDqOz04A:10 a=EfJqPEOeqlMA:10 a=gi0PWCVxevcA:10 a=waUKbcnP6kOjtJonaEUA:9 a=79Ug1xdWh4i4xJr_HvAA:7 a=AKoJm_GX4JNO04dleTsmcdvaVbcA:4 a=AfD3MYMu9mQA:10 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'Greg Weber'" , References: Subject: RE: LC cmts: Extended Attrs Date: Tue, 12 Feb 2008 20:18:10 +0700 Message-ID: <000e01c86d79$c0da46e0$e3e6787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C86DB4.6D391EE0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchtP58ea4I8p1DuRqyPdH6mcWB+UQAOSZ2Q In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C86DB4.6D391EE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have some additional comments on the document: 1. Diameter Considerations. There currently is no Diameter Considerations section. One issue that arises is how to map the Extended Attribute space into the Diameter attribute space. Since Diameter AVP numbers have been assigned with codes >255, the mapping requires an offset to be added to RADIUS Extended Attribute codes. Off the top of my head, I am clear what this offset should be. Also, I think there is the issue of how the extended grouped attributes are mapped into grouped Diameter AVPs. Why don't you think that section 9.6.2 of RFC 4005 applies here (w/the possible exception of setting the Mandatory bit)?. 2. IANA considerations. The text in the current document is minimal, and I think there is room for considerably more discussion there. Given the potential differences in treatment of attributes within the VSA space and standard RADIUS attributes, I think that the IANA considerations should indicate that Extended Attributes should initially be allocated only on request. I disagree. It seems to me that the new, empty space should be used first whenever possible; it is conceivable that some application might absolutely require a legacy standard attribute when they're all gone. In addition, I think that phasing in extended attributes slowly might lessen the chance that implementors will ignore them until the last minute. OTOH, I'm not religious about it. However, as the standard RADIUS attribute space is exhausted, there will eventually be no choice but to allocate out of the extended space. The question is how attributes should be allocated. > Date: Mon, 11 Feb 2008 23:30:50 -0500 > From: gdweber@gmail.com > To: radiusext@ops.ietf.org > Subject: LC cmts: Extended Attrs > > I have some comments on: draft-ietf-radext-extended-attributes-00.txt > > * In section 5, the Ext-Length field is defined as the length of the Extended > Attribute. I think you mean it's the length of the TLV (multiple TLVs can be > in the Extended Attribute). I think that would make the value ">=3", not ">=4". > > * It's probably worth calling out any artifacts of overloading attribute 26 > which wouldn't apply to standard attributes in the original number space > (or apply to overloading a new attribute instead of 26). For example, > attribute 26 is already specifically excluded from some RADIUS message > types, e.g. CoA-NAK, so new Extended Attributes couldn't be included in > those messages, but new standard attribute could be. Also, are malformed > VSAs always treated just like malformed non-VSAs? > > * I think it would be useful to explicitly mention if recursive grouping is > allowed and that Extended Attributes cannot be grouped with non-Extended > Attributes. > > * It's probably useful to mention what happens when an Extended Attribute's > tag is non-zero and it contains multiple TLVs (this does not seem to be > excluded -as multiple TLVs are when the M-bit is on). > > * RFC2865 specifically calls out the proxies can't reorder attributes > of the same > type; does this doc need to create the same restriction for Ext-Type? > > * I actually didn't have a lot of editorial comments :-) Possibly the M-bit > could be renamed to avoid potential confusion with Diameter. > > Greg > > > On Feb 10, 2008 3:50 PM, Bernard Aboba wrote: > > > > This is a reminder of the ongoing RADEXT WG last call on the Extended > > RADIUS Attributes document, prior to sending it to the IESG for > > consideration as a Proposed Standard. The document is available for > > inspection here: > > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute s-00.txt > > > > RADEXT WG last call will last until February 14, 2008. Please send comments > > to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format > > described on the RADEXT WG Issues page: > > http://www.drizzle.com/~aboba/RADEXT/ > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: ------=_NextPart_000_000F_01C86DB4.6D391EE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have some additional comments on the=20 document:
 
1. Diameter Considerations.  There currently = is no=20 Diameter Considerations section.
One issue that arises is how to map = the=20 Extended Attribute space into the Diameter
attribute space.  = Since=20 Diameter AVP numbers have been assigned with codes >255,
the = mapping=20 requires an offset to be added to RADIUS Extended Attribute = codes.
Off the=20 top of my head, I am clear what this offset should be. =
 
Also, I=20 think there is the issue of how the extended grouped attributes are=20 mapped
into grouped Diameter AVPs.   
Why don't you think that section 9.6.2 of RFC 4005 = applies here=20 (w/the possible exception of setting the Mandatory=20 bit)?.  
 
2. IANA = considerations.=20   The text in the current document is minimal, and I think
there = is room=20 for considerably more discussion there.
Given the potential = differences in=20 treatment of attributes
within the VSA space and standard RADIUS = attributes,=20 I think that the IANA considerations
should indicate that Extended = Attributes=20 should initially be allocated only on request.  
I disagree.  It seems to me that the new, empty = space should=20 be used first whenever possible; it is conceivable that some application = might=20 absolutely require a legacy standard attribute when they're all = gone.  In=20 addition, I think that phasing in extended attributes slowly might = lessen the=20 chance that implementors will ignore them until the last minute.  = OTOH, I'm=20 not religious about it.
However, as the standard RADIUS = attribute space is exhausted, there will eventually
be no choice but = to=20 allocate out of the extended space.  The question is how=20 attributes
should be allocated. 

> Date: Mon, 11 Feb = 2008=20 23:30:50 -0500
> From: gdweber@gmail.com
> To:=20 radiusext@ops.ietf.org
> Subject: LC cmts: Extended Attrs
> =
>=20 I have some comments on: = draft-ietf-radext-extended-attributes-00.txt
>=20
> * In section 5, the Ext-Length field is defined as the length = of the=20 Extended
> Attribute. I think you mean it's the length of the TLV=20 (multiple TLVs can be
> in the Extended Attribute). I think that = would=20 make the value ">=3D3", not ">=3D4".
>
> * It's = probably worth=20 calling out any artifacts of overloading attribute 26
> which = wouldn't=20 apply to standard attributes in the original number space
> (or = apply to=20 overloading a new attribute instead of 26). For example,
> = attribute 26 is=20 already specifically excluded from some RADIUS message
> types, = e.g.=20 CoA-NAK, so new Extended Attributes couldn't be included in
> = those=20 messages, but new standard attribute could be. Also, are = malformed
> VSAs=20 always treated just like malformed non-VSAs?
>
> * I think = it would=20 be useful to explicitly mention if recursive grouping is
> allowed = and=20 that Extended Attributes cannot be grouped with non-Extended
>=20 Attributes.
>
> * It's probably useful to mention what = happens when=20 an Extended Attribute's
> tag is non-zero and it contains multiple = TLVs=20 (this does not seem to be
> excluded -as multiple TLVs are when = the M-bit=20 is on).
>
> * RFC2865 specifically calls out the proxies = can't=20 reorder attributes
> of the same
> type; does this doc need = to=20 create the same restriction for Ext-Type?
>
> * I actually = didn't=20 have a lot of editorial comments :-) Possibly the M-bit
> could be = renamed=20 to avoid potential confusion with Diameter.
>
> = Greg
>=20
>
> On Feb 10, 2008 3:50 PM, Bernard Aboba=20 <bernard_aboba@hotmail.com> wrote:
> >
> > This = is a=20 reminder of the ongoing RADEXT WG last call on the Extended
> > = RADIUS=20 Attributes document, prior to sending it to the IESG for
> >=20 consideration as a Proposed Standard. The document is available = for
> >=20 inspection here:
> >=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes= -00.txt
>=20 >
> > RADEXT WG last call will last until February 14, 2008. = Please=20 send comments
> > to the RADEXT WG mailing list=20 (radiusext@ops.ietf.org) in the format
> > described on the = RADEXT WG=20 Issues page:
> > http://www.drizzle.com/~aboba/RADEXT/
> =
>=20 --
> to unsubscribe send a message to = radiusext-request@ops.ietf.org=20 with
> the word 'unsubscribe' in a single line as the message text = body.
> archive:=20 <http://psg.com/lists/radiusext/>

------=_NextPart_000_000F_01C86DB4.6D391EE0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 12 08:19:09 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC62F28C366 for ; Tue, 12 Feb 2008 08:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvaBjCK3SXbE for ; Tue, 12 Feb 2008 08:19:08 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8023628C2F6 for ; Tue, 12 Feb 2008 08:18:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOxgG-000NQa-UD for radiusext-data@psg.com; Tue, 12 Feb 2008 16:08:24 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JOxgE-000NQH-7d for radiusext@ops.ietf.org; Tue, 12 Feb 2008 16:08:23 +0000 Received: (qmail 10377 invoked from network); 12 Feb 2008 11:08:21 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 12 Feb 2008 11:08:21 -0500 From: "David B. Nelson" To: References: <200802111126.25340.stefan.winter@restena.lu> <008b01c86d13$290663f0$aedd787c@arubanetworks.com> Subject: RE: request to recharter Date: Tue, 12 Feb 2008 11:04:03 -0500 Organization: Elbrys Networks, Inc. Message-ID: <010e01c86d90$e3756920$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <008b01c86d13$290663f0$aedd787c@arubanetworks.com> Thread-Index: AchsmO0sxJh8DZt2QmSwaf2B7i/MqgAeHcSAAB+sv7A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > No, no, NO! "radsec" is not RADIUS, period. Not an extension, > not even a perversion, not RADIUS. Without offering any opinion as to whether RADEXT should seek to amend its charter to include RADSEC, let me ask why RADIUS over TLS/TCP is conceptually so different from RADIUS over IPSec? Seems to me that both are RADIUS encapsulated in protected transport. We are also considering RADIUS over DTLS/UDP, and you don't seem to be quire so concerned about that proposal. Is it the use of TCP that bothers you so much? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 06:50:26 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352F33A6A24 for ; Wed, 13 Feb 2008 06:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.83 X-Spam-Level: X-Spam-Status: No, score=-5.83 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txAXtcI61w0l for ; Wed, 13 Feb 2008 06:50:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 339943A6888 for ; Wed, 13 Feb 2008 06:50:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPIro-0008U3-BQ for radiusext-data@psg.com; Wed, 13 Feb 2008 14:45:44 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPIrf-0008TQ-69 for radiusext@ops.ietf.org; Wed, 13 Feb 2008 14:45:39 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id E21B376F44; Wed, 13 Feb 2008 15:45:33 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id D59C876F42; Wed, 13 Feb 2008 15:45:33 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: request to recharter Date: Wed, 13 Feb 2008 15:45:29 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org References: <200802111126.25340.stefan.winter@restena.lu> <008b01c86d13$290663f0$aedd787c@arubanetworks.com> In-Reply-To: <008b01c86d13$290663f0$aedd787c@arubanetworks.com> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart1746412.3UTehyOUJ2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Yes, there has been a popular upswell of support for abandoning our work > in favor of yours -- oh, wait, that would be you alone... well, first: it's not abandoning abandoning RADIUS work. In fact, the RADIU= S=20 payload is left completely untouched. Second: it wasn't me alone. I was the one who showed up at IETF, that's rig= ht.=20 But as you very well know, there was an implementation out there for years= =20 which had customers, and RadSec has proved useful to a worldwide-operating= =20 roaming consortium, and has been implemented by other parties meanwhile. If= I=20 had gotten an outright reject from the radext group as whole I wouldn't hav= e=20 taken the step to ask for rechartering. But if you recall IETF69+70, there= =20 *was* support for the work. Yes, there has also been an outcry to ignore=20 RadSec completely -- oh, wait, that was you alone... > No, no, NO! "radsec" is not RADIUS, period. Not an extension, not even > a perversion, not RADIUS.=20 We've had a discussion on that topic before on this list. That time, at the= =20 end you resorted to a strange analogy of ducks and snakes IIRC, not providi= ng=20 a reasonable argumentation. > I would support a radsec BOF & WG, but I will not support this. *Thank you*! It is very nice to read that you would support a WG for that=20 work, which appears to imply that you see the concept as worthy for=20 exploration and eventual standardisation. Actually, I had been thinking abo= ut=20 this way forward as well. The outcome was that creating a whole new working= =20 group for this one thing probably isn't justified. After all, it is not=20 likely to create follow-up work, it's pretty much a standalone thing to add= =20 to RADIUS. So, if a working group isn't justified due to lack of amount of work, but t= he=20 work is still somewhat important, where would the place to go be? My=20 conclusion was that radext is the place to go. And I still think that=20 reasoning is justified, Bernard's reply in the thread looks like it is at=20 least deemed worth a consideration. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart1746412.3UTehyOUJ2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHswKN+jm90f8eFWYRArOVAJ42rr5nS5gLX36f8ITCJnmJj1MRQwCbBuzh AG0QdoKJ4OQ6KhoWg5xuYCw= =k9/G -----END PGP SIGNATURE----- --nextPart1746412.3UTehyOUJ2-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 09:09:42 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062A228C8B3 for ; Wed, 13 Feb 2008 09:09:42 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebCypZGNJQzs for ; Wed, 13 Feb 2008 09:09:39 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D3BBF28C898 for ; Wed, 13 Feb 2008 09:09:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPKxV-0005xt-1O for radiusext-data@psg.com; Wed, 13 Feb 2008 16:59:45 +0000 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPKxJ-0005wK-9j for radiusext@ops.ietf.org; Wed, 13 Feb 2008 16:59:38 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 65CDCA704E; Wed, 13 Feb 2008 08:59:28 -0800 (PST) Message-ID: <47B3214B.4050407@nitros9.org> Date: Wed, 13 Feb 2008 17:56:43 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Winter CC: radiusext@ops.ietf.org Subject: Re: request to recharter References: <200802111126.25340.stefan.winter@restena.lu> In-Reply-To: <200802111126.25340.stefan.winter@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter wrote: > The points above make me think that it is about time to seriously consider > that the radext charter is modified to include RadSec into the working group > scope. I have no objections, presuming that TCP is also accepted as a transport protocol. > The only part in the charter that would need to be changed is, obviously, the > line > > "- No new RADIUS transports (e.g. TCP, SCTP) will be defined." > > which I request to purge from the charter. I'm not sure I understand all of Glen's concerns, but TCP as a transport protocol is a fairly large change to RADIUS. The basic send/receive concepts don't change. The packet formats don't change, but there are issues relating to TCP && AAA stability, as discussed in RFC 3539. I have no major objections to this. If TCP is accepted, I would suggest a draft focussed on issues relating to TCP as a transport protocol. The RadSec document can then reference this draft. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 09:46:39 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9771228C914 for ; Wed, 13 Feb 2008 09:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.339 X-Spam-Level: X-Spam-Status: No, score=-4.339 tagged_above=-999 required=5 tests=[AWL=2.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg+poUNe-vE4 for ; Wed, 13 Feb 2008 09:46:35 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 77ABC28C83D for ; Wed, 13 Feb 2008 09:46:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPLZx-000AYk-BV for radiusext-data@psg.com; Wed, 13 Feb 2008 17:39:29 +0000 Received: from [76.96.62.96] (helo=QMTA09.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPLZu-000AYG-U2 for radiusext@ops.ietf.org; Wed, 13 Feb 2008 17:39:28 +0000 Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA09.westchester.pa.mail.comcast.net with comcast id p5XV1Y00L0xGWP85901w00; Wed, 13 Feb 2008 17:38:47 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA12.westchester.pa.mail.comcast.net with comcast id p5fP1Y00224Kx1C3Y00000; Wed, 13 Feb 2008 17:39:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=faAz9kwQZ2d5UOnyVXAA:9 a=68EGe2Om-__2EsfGVTM-DMjLwc8A:4 a=v47ZLdibA2YA:10 From: "David B. Nelson" To: References: <200802111126.25340.stefan.winter@restena.lu> <47B3214B.4050407@nitros9.org> Subject: RE: request to recharter Date: Wed, 13 Feb 2008 12:39:23 -0500 Message-ID: <078001c86e67$5fec7d00$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchuYqCUQ3pEYVGESwSMVkPhtIQfIQABEzAw In-reply-to: <47B3214B.4050407@nitros9.org> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Alan DeKok writes... > If TCP is accepted, I would suggest a draft focussed on issues > relating to TCP as a transport protocol. I think that would be warranted, whether in a separate document or integrated. Someone sent me an off-list reply, expressing concern about changes to the RADIUS paradigm for timeouts and retransmissions, when using TCP. Those issues would certainly need to be addressed. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 10:11:01 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149E03A6D20 for ; Wed, 13 Feb 2008 10:11:01 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtnOKqOTjHrk for ; Wed, 13 Feb 2008 10:11:00 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 3043C3A6A9A for ; Wed, 13 Feb 2008 10:11:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPLxP-000DLJ-Un for radiusext-data@psg.com; Wed, 13 Feb 2008 18:03:43 +0000 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPLxN-000DKt-Ox for radiusext@ops.ietf.org; Wed, 13 Feb 2008 18:03:42 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 5B015A704E for ; Wed, 13 Feb 2008 10:03:36 -0800 (PST) Message-ID: <47B3304F.9030005@nitros9.org> Date: Wed, 13 Feb 2008 19:00:47 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: request to recharter References: <200802111126.25340.stefan.winter@restena.lu> <47B3214B.4050407@nitros9.org> <078001c86e67$5fec7d00$011716ac@NEWTON603> In-Reply-To: <078001c86e67$5fec7d00$011716ac@NEWTON603> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk David B. Nelson wrote: > I think that would be warranted, whether in a separate document or > integrated. Someone sent me an off-list reply, expressing concern about > changes to the RADIUS paradigm for timeouts and retransmissions, when using > TCP. Those issues would certainly need to be addressed. RFC 3539 already has a suggested retransmission and timeout algorithm for AAA protocols over TCP. I think that could be used. Any document for RADIUS + TCP would need to concentrate on RADIUS-specific issues. e.g. UDP RADIUS practices are NOT appropriate when TCP is used as a transport protocol. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 15:09:23 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81913A6FF6 for ; Wed, 13 Feb 2008 15:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.173 X-Spam-Level: X-Spam-Status: No, score=-4.173 tagged_above=-999 required=5 tests=[AWL=2.426, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cc1-E07Uk8R for ; Wed, 13 Feb 2008 15:09:22 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1EBD63A67D5 for ; Wed, 13 Feb 2008 15:08:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQe9-000L5E-GL for radiusext-data@psg.com; Wed, 13 Feb 2008 23:04:09 +0000 Received: from [65.55.175.216] (helo=blu139-omc3-s16.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQe7-000L2J-4Y for radiusext@ops.ietf.org; Wed, 13 Feb 2008 23:04:08 +0000 Received: from BLU137-W37 ([65.55.162.187]) by blu139-omc3-s16.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Feb 2008 15:04:06 -0800 Message-ID: X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: "David B. Nelson" , Subject: RE: request to recharter Date: Wed, 13 Feb 2008 15:04:07 -0800 Importance: Normal In-Reply-To: <078001c86e67$5fec7d00$011716ac@NEWTON603> References: <200802111126.25340.stefan.winter@restena.lu> <47B3214B.4050407@nitros9.org> <078001c86e67$5fec7d00$011716ac@NEWTON603> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2008 23:04:06.0719 (UTC) FILETIME=[BBEDACF0:01C86E94] Sender: owner-radiusext@ops.ietf.org Precedence: bulk > I think that would be warranted, whether in a separate document or > integrated. Someone sent me an off-list reply, expressing concern about > changes to the RADIUS paradigm for timeouts and retransmissions, when usi= ng > TCP. Those issues would certainly need to be addressed. There is already a proposed standard for the transport of AAA protocols ove= r TCP, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC= 3539. = -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 15:14:55 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3523A6D6E for ; Wed, 13 Feb 2008 15:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.232 X-Spam-Level: X-Spam-Status: No, score=-4.232 tagged_above=-999 required=5 tests=[AWL=2.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC27Y8UIUouU for ; Wed, 13 Feb 2008 15:14:55 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0CDA63A6873 for ; Wed, 13 Feb 2008 15:14:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQj8-000M06-MU for radiusext-data@psg.com; Wed, 13 Feb 2008 23:09:18 +0000 Received: from [65.55.175.223] (helo=blu139-omc3-s23.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQj6-000Lzq-KO for radiusext@ops.ietf.org; Wed, 13 Feb 2008 23:09:17 +0000 Received: from BLU137-W28 ([65.55.162.187]) by blu139-omc3-s23.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Feb 2008 15:09:15 -0800 Message-ID: X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Alan DeKok , Stefan Winter CC: Subject: RE: request to recharter Date: Wed, 13 Feb 2008 15:09:15 -0800 Importance: Normal In-Reply-To: <47B3214B.4050407@nitros9.org> References: <200802111126.25340.stefan.winter@restena.lu> <47B3214B.4050407@nitros9.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2008 23:09:16.0037 (UTC) FILETIME=[744BDB50:01C86E95] Sender: owner-radiusext@ops.ietf.org Precedence: bulk > If TCP is accepted, I would suggest a draft focussed on issues relating t= o TCP as a transport > protocol. The RadSec document can then reference this draft. Since RFC 3539 already defines the transport profile and failover algorithm= s for AAA running over TCP/SCTP, I am not clear what remaining work is required in that area. = -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 15:26:09 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE083A6E84 for ; Wed, 13 Feb 2008 15:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.716 X-Spam-Level: X-Spam-Status: No, score=-4.716 tagged_above=-999 required=5 tests=[AWL=1.883, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhuOdZrqBvet for ; Wed, 13 Feb 2008 15:26:08 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 990AE3A68D4 for ; Wed, 13 Feb 2008 15:26:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQv4-000NLu-1Z for radiusext-data@psg.com; Wed, 13 Feb 2008 23:21:38 +0000 Received: from [76.96.62.24] (helo=QMTA02.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPQv1-000NLe-MJ for radiusext@ops.ietf.org; Wed, 13 Feb 2008 23:21:37 +0000 Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA02.westchester.pa.mail.comcast.net with comcast id p5KM1Y0080ldTLk520Dy00; Wed, 13 Feb 2008 23:21:19 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA04.westchester.pa.mail.comcast.net with comcast id pBMY1Y00724Kx1C3Q00000; Wed, 13 Feb 2008 23:21:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=-mbZP6gPpZCDtTN4cRUA:9 a=AvjDuu0ag2L2Y42YsA-ShYR_lpEA:4 a=zoKOyUDlhksA:10 From: "David B. Nelson" To: References: <200802111126.25340.stefan.winter@restena.lu> <47B3214B.4050407@nitros9.org> <078001c86e67$5fec7d00$011716ac@NEWTON603> Subject: RE: request to recharter Date: Wed, 13 Feb 2008 18:21:33 -0500 Message-ID: <00a001c86e97$2c6bf9d0$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AchulTgSa3VmN9EXTkSkpAzxnLqOQAAAa44g Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba writes... > There is already a proposed standard for the transport of AAA protocols > over TCP, "Authentication, Authorization and Accounting (AAA) Transport > Profile", RFC 3539. Yes. Alan pointed that out in a follow up message. Was that document created as part of the Diameter requirements work? Just curious. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 16:52:25 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19923A6C8F for ; Wed, 13 Feb 2008 16:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[AWL=1.810, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9P1JJXiK5bP for ; Wed, 13 Feb 2008 16:52:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 2A49A3A68DB for ; Wed, 13 Feb 2008 16:52:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPSGN-0006a7-W3 for radiusext-data@psg.com; Thu, 14 Feb 2008 00:47:43 +0000 Received: from [65.55.175.203] (helo=blu139-omc3-s3.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPSGL-0006Zc-RW for radiusext@ops.ietf.org; Thu, 14 Feb 2008 00:47:42 +0000 Received: from BLU137-W42 ([65.55.162.188]) by blu139-omc3-s3.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Feb 2008 16:47:40 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_0bac74ce-4cb2-4fa1-9e61-718c09c046b2_" X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Subject: RFC 5090 published as a Proposed Standard Date: Wed, 13 Feb 2008 16:47:41 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2008 00:47:40.0999 (UTC) FILETIME=[33ED8D70:01C86EA3] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_0bac74ce-4cb2-4fa1-9e61-718c09c046b2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 5090 (RADIUS Digest Authentication) has now been published as an RFC: http://www.ietf.org/rfc/rfc5090.txt Congratulations to the authors, as well as everyone who worked on this "min= or update" to RFC 4590 that ended up being more work than any of us expecte= d :) --_0bac74ce-4cb2-4fa1-9e61-718c09c046b2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 5090 (RADIUS Digest Authentication) has now been published as an RFC:http://www.ietf.org/rfc/rfc5090.txt

Congratulations to the authors= , as well as everyone who worked on this "minor update" to RFC 4590 that en= ded up being more work than any of us expected :)
= --_0bac74ce-4cb2-4fa1-9e61-718c09c046b2_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 18:26:26 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2A53A6FA6 for ; Wed, 13 Feb 2008 18:26:26 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtgSL9DWQ+AR for ; Wed, 13 Feb 2008 18:26:25 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BF1043A6F65 for ; Wed, 13 Feb 2008 18:26:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPTji-000Fjs-0z for radiusext-data@psg.com; Thu, 14 Feb 2008 02:22:06 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPTjf-000Fj9-Jh for radiusext@ops.ietf.org; Thu, 14 Feb 2008 02:22:04 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2008 18:22:02 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1E2M2jd029882; Wed, 13 Feb 2008 18:22:02 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1E2LYQN005690; Thu, 14 Feb 2008 02:22:02 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 18:21:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: inconsistency in RFC 5176 Date: Wed, 13 Feb 2008 18:21:48 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: inconsistency in RFC 5176 Thread-Index: AchurF1toURjm34sRTCZ45MRUMM1gAAA9zQw From: "Murtaza Chiba (mchiba)" To: , "Bernard Aboba" X-OriginalArrivalTime: 14 Feb 2008 02:21:56.0133 (UTC) FILETIME=[5EA68550:01C86EB0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2391; t=1202955722; x=1203819722; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20FW=3A=20inconsistency=20in=20RFC=205176 |Sender:=20; bh=N1A8K0X8fl0QkJCbg9YvQpLUDarjscq2U7jWeLJsQyY=; b=GjgaFhaPamiCvGcTb3HzDF2pVgXBAoTmasI2iKmTMwIfoFbO+QmWFAyXdQ XXxvlfimi0fqjuDuMpRFiTdCXf2ZkHo2P0rVyn9di+g7dbzCtL8vin72NZfo PC9f21M90C; Authentication-Results: sj-dkim-4; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-radiusext@ops.ietf.org Precedence: bulk =20 -----Original Message----- From: Alfred H=CEnes [mailto:ah@tr-sys.de]=20 Sent: Wednesday, February 13, 2008 5:51 PM To: Murtaza Chiba (mchiba); Gopal Dommety (gdommety); Mark Eklund = (meklund); david@mitton.com Cc: rfc-editor@rfc-editor.org Subject: inconsistency in RFC 5176 Hello, after studying the recently published RFC 5176 (RADIUS Dyn.Auth.) = authored by you, I stumbled over an apparent serious inconsistency in = Section 3.5 of that memo. The first clause there (on page 16) says: 3.5. Error-Cause Description It is possible that a Dynamic Authorization Server cannot honor Disconnect-Request or CoA-Request packets for some reason. The Error-Cause Attribute provides more detail on the cause of the | problem. It MAY be included within CoA-NAK and Disconnect-NAK | packets. The last sentence is consistent with the tables in Section 3.6 (pages = 20..22) that also exclude the use of the Error-Clause Attribute for the = CoA-ACK and Disconnect-ACK messages/packets. But surprisingly, the text in the "Value" clause in Section 3.5, from = the bottom of page 16 until page 18 repeatedly deals with inclusion or = non-inclusion of the Error-Clause Attribute into the CoA-ACK and = Disconnect-ACK messages/packets. Some of these sentences are only = confusing, but those that state applicability of the Error-Clause = Attribute contradict the intent ot the other parts of the memo. Please check. I suggest that this issue should be resolved by RFC Errata Notes = invalidating/removing all phrases in the "Value" clause that mention = CoA-ACK and Disconnect-ACK. Kind regards, Alfred H=CEnes. P.S.: Due to inappropriate blackholing of DNS requests, apparently caused by packet filtering based on *sorce* port somewhere in Redmont, I cannot send a copy of this message to your co-author Bernard Aboba. Please arrange to forward to him a copy of this message -- thanks in advance. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Feb 13 22:22:10 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2582728C8DA for ; Wed, 13 Feb 2008 22:22:10 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9l57IE51KzT for ; Wed, 13 Feb 2008 22:22:09 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 16F0128C848 for ; Wed, 13 Feb 2008 22:22:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPXOK-0008W5-U9 for radiusext-data@psg.com; Thu, 14 Feb 2008 06:16:16 +0000 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPXOI-0008Vh-In for radiusext@ops.ietf.org; Thu, 14 Feb 2008 06:16:15 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 30144A704E; Wed, 13 Feb 2008 22:16:03 -0800 (PST) Message-ID: <47B3DC02.7070709@nitros9.org> Date: Thu, 14 Feb 2008 07:13:22 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: Stefan Winter , radiusext@ops.ietf.org Subject: Re: request to recharter References: <200802111126.25340.stefan.winter@restena.lu> <47B3214B.4050407@nitros9.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba wrote: > Since RFC 3539 already defines the transport profile and failover algorithms > for AAA running over TCP/SCTP, I am not clear what remaining work is > required in that area. Partly psychological... people are more likely to read a "RADIUS over TCP" document than an "AAA over TCP" document. Also, standardizing TCP as a RADIUS transport would require the publication of *some* kind of document, if I understand the IETF process correctly. We couldn't just announce that it's OK... The "RADIUS over TCP" document could reference existing RADIUS practices, and explain in excruciating detail why they won't work for TCP. Also, some issues relating to RADIUS PDU's over a stream transport may be discussed. e.g. receiving half a RADIUS packet and then a FIN is *not* a problem. The MIB counters for radiusAuthServMalformedAccessRequests should NOT be incremented. e.g. receiving a PDU with malformed attributes means that the TCP connection SHOULD be closed. Many RADIUS practices related to handling error cases require a PDU to be "silently discarded". This won't work for TCP. The connection has to be closed, too. The existing RFC's have to be audited, and a new document issued which explains the correct behavior. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 14 00:03:46 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F2228C8C9 for ; Thu, 14 Feb 2008 00:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rN4HytmcM6d for ; Thu, 14 Feb 2008 00:03:45 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 07DCF28C433 for ; Thu, 14 Feb 2008 00:03:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPYzN-000KKf-Gw for radiusext-data@psg.com; Thu, 14 Feb 2008 07:58:37 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPYzJ-000KEN-PI for radiusext@ops.ietf.org; Thu, 14 Feb 2008 07:58:36 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 011D776F44; Thu, 14 Feb 2008 08:58:30 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id E508576F43; Thu, 14 Feb 2008 08:58:29 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: Alan DeKok Subject: Re: request to recharter Date: Thu, 14 Feb 2008 08:58:24 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Bernard Aboba , radiusext@ops.ietf.org References: <200802111126.25340.stefan.winter@restena.lu> <47B3DC02.7070709@nitros9.org> In-Reply-To: <47B3DC02.7070709@nitros9.org> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart3320479.kJetg781WW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Partly psychological... people are more likely to read a "RADIUS over > TCP" document than an "AAA over TCP" document. Also, standardizing TCP > as a RADIUS transport would require the publication of *some* kind of > document, if I understand the IETF process correctly. We couldn't just > announce that it's OK... The draft currently already references 3539, in section "Connection=20 Keepalive":=20 " A RadSec node which initiates a RadSec connection SHOULD send the Status-Server packets defined in [10] according to the state machine in section 3.4 of [6] since RadSec operates on a reliable transport protocol." where [6] is a reference to 3539. That text could be made more explicitly=20 though, and reference 3539 as a whole, not just the one section with the=20 state machine. > The "RADIUS over TCP" document could reference existing RADIUS > practices, and explain in excruciating detail why they won't work for TCP. > > Also, some issues relating to RADIUS PDU's over a stream transport may > be discussed. e.g. receiving half a RADIUS packet and then a FIN is > *not* a problem. The MIB counters for > radiusAuthServMalformedAccessRequests should NOT be incremented. e.g. > receiving a PDU with malformed attributes means that the TCP connection > SHOULD be closed. > > Many RADIUS practices related to handling error cases require a PDU to > be "silently discarded". This won't work for TCP. The connection has > to be closed, too. The existing RFC's have to be audited, and a new > document issued which explains the correct behavior. Sounds plausible. Greetings, Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart3320479.kJetg781WW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHs/Sk+jm90f8eFWYRAniKAKCKP8FmUakhX7UYSULgJowOCoxi8ACfQBXQ V+/xPafSKjJMGyr3M6wjPJY= =gjxt -----END PGP SIGNATURE----- --nextPart3320479.kJetg781WW-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 14 00:11:49 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD9B3A682B for ; Thu, 14 Feb 2008 00:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KezIlDuhfdeI for ; Thu, 14 Feb 2008 00:11:47 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A784B3A6F80 for ; Thu, 14 Feb 2008 00:11:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPZ8E-000MNk-Uf for radiusext-data@psg.com; Thu, 14 Feb 2008 08:07:46 +0000 Received: from [76.96.62.64] (helo=QMTA07.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPZ8B-000MNI-Cg for radiusext@ops.ietf.org; Thu, 14 Feb 2008 08:07:45 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA07.westchester.pa.mail.comcast.net with comcast id pKty1Y0051GhbT85701000; Thu, 14 Feb 2008 08:07:28 +0000 Received: from gzornt61 ([124.120.216.208]) by OMTA07.westchester.pa.mail.comcast.net with comcast id pL7N1Y0084WMWz83T00000; Thu, 14 Feb 2008 08:07:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=s1hnIps86Wqfa7_udcQA:9 a=nBgGr7l2f4VDuDU0iTwA:7 a=Hy9uususOaWHO9zb5RGPWHYPp_4A:4 a=ufO146cb3fEA:10 a=36aA09wfIYVdTMBMJboA:9 a=VcYAn4G9HKkxqU8l_IMA:7 a=P6WdGPYqbrGycz4xTK2ZSq45SV0A:4 a=AfD3MYMu9mQA:10 From: "Glen Zorn" To: "'Stefan Winter'" Cc: References: <200802111126.25340.stefan.winter@restena.lu> <008b01c86d13$290663f0$aedd787c@arubanetworks.com> <200802131545.33245.stefan.winter@restena.lu> Subject: RE: request to recharter Date: Thu, 14 Feb 2008 15:07:22 +0700 Message-ID: <000d01c86ee0$aa4753b0$d0d8787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C86F1B.56A62BB0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200802131545.33245.stefan.winter@restena.lu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchuTxjxFT0KhVCmRjC8JWczBR8ywwAiu80A Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C86F1B.56A62BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stefan Winter scribbled on Wednesday, February 13, 2008 9:45 PM: > Hi, > >> Yes, there has been a popular upswell of support for abandoning our >> work in favor of yours -- oh, wait, that would be you alone... > > well, first: it's not abandoning abandoning RADIUS work. In fact, the > RADIUS payload is left completely untouched. > > Second: it wasn't me alone. I was the one who showed up at IETF, > that's right. > But as you very well know, there was an implementation out there for > years which had customers, and RadSec has proved useful to a > worldwide-operating roaming consortium, and has been implemented by > other parties meanwhile. If I had gotten an outright reject from the > radext group as whole I wouldn't have taken the step to ask for > rechartering. But if you recall IETF69+70, there *was* support for > the work. Yes, there has also been an outcry to ignore RadSec > completely -- oh, wait, that was you alone... I'm afraid you are incorrect. From your first appearance at radext I have expressed the opinion that, while the radsec work was interesting, it is not RADIUS & therefore does not belong in the radext WG. > >> No, no, NO! "radsec" is not RADIUS, period. Not an extension, not >> even a perversion, not RADIUS. > > We've had a discussion on that topic before on this list. That time, > at the end you resorted to a strange analogy of ducks and snakes > IIRC, not providing a reasonable argumentation. I assume that you are referring to the following exchange (https://ops.ietf.org/lists/radiusext/2007/msg00603.html): > Well, except that in order to place these things in a common category it > is necessary to ignore one of the defining characteristics of RADIUS: > that it is only and intentionally defined as a connectionless protocol. >> The impact of connectionless vs. connection is not very significant when >> discussing the protocol's *security*, IMO. So I gather that as far as you're concerned a network "protocol" solely consists of the format of the innermost PDU? > might like to believe so, RadSec is _not_ RADIUS, >> Well, it's _almost_ RADIUS, especially if one takes into account the >> mechanisms in RADIUS to detect duplication, retransmission etc, which already >> contains parts of the merits of TCP. By that logic, a cobra is _almost_ a pigeon. > & therefore far out of > scope of not just the crypto-agility discussions but of this WG. > RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS & > therefore _is_ in scope. >> I have understood that DTLS is considered in scope, while RadSec is out of >> scope (Reminder: I never claimed otherwise). Just keep in mind that DTLS >> itself requires even more characteristics of TCP, so when combining the >> RADIUS mechanisms that come on top of UDP + the transport mechanisms in DTLS, >> the end result is getting very close to TCP already. So the distance between >> in-scope and out-of-scope is a very thin line. Only if snakes are almost birds... I'm sorry that you didn't understand that simile. Perhaps you also don't recall (or didn't understand) the message that elicited it (https://ops.ietf.org/lists/radiusext/2007/msg00590.html): > I agree that it is not relevant for crypto-agility discussions. As I > see it, DTLS and RadSec fall under a common category in this respect: > whole packet encryption, with encryption negotiation happening > outside of RADIUS. Well, except that in order to place these things in a common category it is necessary to ignore one of the defining characteristics of RADIUS: that it is only and intentionally defined as a connectionless protocol. This is not an accidental result of the transport choice as you seem to imply below ("{some transport}+{the equivalent of TLS for that transport}"), but a fundamental quality of RADIUS itself. Much as you might like to believe so, RadSec is _not_ RADIUS, & therefore far out of scope of not just the crypto-agility discussions but of this WG. RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS & therefore _is_ in scope. Since the "strange analogy" you deride was an attempt to explain the above statement (what part of it is "unreasonable", exactly?) I won't risk further derision by attempting to explain it again. > >> I would support a radsec BOF & WG, but I will not support this. > > *Thank you*! It is very nice to read that you would support a WG for > that work, which appears to imply that you see the concept as worthy > for exploration and eventual standardisation. See above; actually, I'm not really sure about standardization, but surely it could be documented. > Actually, I had been > thinking about this way forward as well. The outcome was that > creating a whole new working group for this one thing probably isn't > justified. After all, it is not likely to create follow-up work, it's > pretty much a standalone thing to add to RADIUS. So, if a working > group isn't justified due to lack of amount of work, but the work is > still somewhat important, where would the place to go be? My > conclusion was that radext is the place to go. As the chairs have pointed out, the WG has almost completed its work & it seems like the only thing being considered to continue radext is radsec. So if there is not enough work to justify a WG (something I doubt very much) then it doesn't seem to justify the continuation of radext, either. Just publish an Informational RFC & be done with it. BTW, what do the members of the "worldwide-operating roaming consortium" think about giving up change control to the IETF (or do they think that we will simply rubberstamp this work of sheer genius)? > And I still think that > reasoning is justified, Bernard's reply in the thread looks like it > is at least deemed worth a consideration. > > Greetings, > > Stefan Winter ------=_NextPart_000_000E_01C86F1B.56A62BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan Winter <mailto:stefan.winter@restena.lu<= /A>>=20 scribbled on Wednesday, February 13, 2008 9:45 PM:

>=20 Hi,
>
>> Yes, there has been a popular upswell of support = for=20 abandoning our
>> work in favor of yours -- oh, wait, that = would be you=20 alone...
>
> well, first: it's not abandoning abandoning = RADIUS=20 work. In fact, the
> RADIUS payload is left completely=20 untouched.
>
> Second: it wasn't me alone. I was the one who = showed=20 up at IETF,
> that's right.
> But as you very well know, = there was=20 an implementation out there for
> years which had customers, and = RadSec=20 has proved useful to a
> worldwide-operating roaming consortium, = and has=20 been implemented by
> other parties meanwhile. If I had gotten an = outright=20 reject from the
> radext group as whole I wouldn't have taken the = step to=20 ask for
> rechartering. But if you recall IETF69+70, there *was* = support=20 for
> the work. Yes, there has also been an outcry to ignore=20 RadSec
> completely -- oh, wait, that was you = alone... 

I'm afraid you are incorrect.  From your first = appearance at=20 radext I have expressed the opinion that, while the radsec work was = interesting,=20 it is not RADIUS & therefore does not belong in the radext=20 WG. 
 
>
>> No, no, NO!  = "radsec" is not=20 RADIUS, period.  Not an extension, not
>> even a = perversion, not=20 RADIUS.
>
> We've had a discussion on that topic before on = this=20 list. That time,
> at the end you resorted to a strange analogy of = ducks=20 and snakes
> IIRC, not providing a reasonable=20 argumentation. 

I assume that you are = referring=20 to the following exchange (https://= ops.ietf.org/lists/radiusext/2007/msg00603.html):

<QUOTE>
> Well, except that in order to = place these=20 things in a common category it
> is necessary to ignore one of the = defining characteristics of RADIUS:
> that it is only and = intentionally=20 defined as a connectionless protocol.

>> The impact of=20 connectionless vs. connection is not very significant when
>>=20 discussing the protocol's *security*, IMO.

So I gather that as = far as=20 you're concerned a network "protocol" solely consists of the format of = the=20 innermost PDU?

> might like to believe so, RadSec is _not_=20 RADIUS,

>> Well, it's _almost_ RADIUS, especially if one = takes into=20 account the
>> mechanisms in RADIUS to detect duplication,=20 retransmission etc, which already
>> contains parts of the = merits of=20 TCP.

By that logic, a cobra is _almost_ a pigeon.

> = &=20 therefore far out of
> scope of not just the crypto-agility = discussions=20 but of this WG.
> RADIUSoDTLS, OTOH, doesn't alter the fundamental = nature=20 of RADIUS &
> therefore _is_ in scope.

>> I have=20 understood that DTLS is considered in scope, while RadSec is out = of
>>=20 scope (Reminder: I never claimed otherwise). Just keep in mind that=20 DTLS
>> itself requires even more characteristics of TCP, so = when=20 combining the
>> RADIUS mechanisms that come on top of UDP + = the=20 transport mechanisms in DTLS,
>> the end result is getting very = close=20 to TCP already. So the distance between
>> in-scope and = out-of-scope is=20 a very thin line.

Only if snakes are almost=20 birds...
</QUOTE>

I'm sorry = that you=20 didn't understand that simile.  Perhaps you also don't recall (or = didn't=20 understand) the message that elicited it (https://= ops.ietf.org/lists/radiusext/2007/msg00590.html):
<QUOTE>
> I agree that it is not relevant = for=20 crypto-agility discussions. As I
> see it, DTLS and RadSec fall = under a=20 common category in this respect:
> whole packet encryption, with=20 encryption negotiation happening
> outside of=20 RADIUS.  

Well, except that in order to place these = things in a=20 common category it
is necessary to ignore one of the defining = characteristics=20 of RADIUS:
that it is only and intentionally defined as a = connectionless=20 protocol.
This is not an accidental result of the transport choice as = you=20 seem to
imply below ("{some transport}+{the equivalent of TLS for=20 that
transport}"), but a fundamental quality of RADIUS itself.  = Much as=20 you
might like to believe so, RadSec is _not_ RADIUS, & therefore = far out=20 of
scope of not just the crypto-agility discussions but of this=20 WG.
RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS = &
therefore _is_ in scope.
</QUOTE>

Since the "strange analogy" you deride was an attempt to = explain=20 the above statement (what part of it is "unreasonable", exactly?)  = I won't=20 risk further derision by attempting to explain it=20 again.

>
>> I would support a radsec BOF & = WG, but=20 I will not support this.
>
> *Thank you*! It is very nice to = read=20 that you would support a WG for
> that work, which appears to = imply that=20 you see the concept as worthy
> for exploration and eventual=20 standardisation.

See above; actually, I'm not really = sure about=20 standardization, but surely it could be documented. 

> Actually, I had been
> thinking about this = way=20 forward as well. The outcome was that
> creating a whole new = working group=20 for this one thing probably isn't
> justified. After all, it is = not likely=20 to create follow-up work, it's
> pretty much a standalone thing to = add to=20 RADIUS. So, if a working
> group isn't justified due to lack of = amount of=20 work, but the work is
> still somewhat important, where would the = place to=20 go be? My
> conclusion was that radext is the place to go. =

As the chairs have pointed out, the WG = has almost=20 completed its work & it seems like the only thing being considered = to=20 continue radext is radsec.  So if there is not enough work to = justify a WG=20 (something I doubt very much) then it doesn't seem to justify the = continuation=20 of radext, either.  Just publish an Informational RFC & be done = with=20 it.  BTW, what do the members of the "worldwide-operating = roaming=20 consortium" think about giving up change control to the IETF (or do they = think=20 that we will simply rubberstamp this work of sheer genius)?

> And I still think that
> reasoning is = justified,=20 Bernard's reply in the thread looks like it
> is at least deemed = worth a=20 consideration.         
&= gt;
>=20 Greetings,
>
> Stefan Winter

------=_NextPart_000_000E_01C86F1B.56A62BB0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 14 00:44:51 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21A23A7052 for ; Thu, 14 Feb 2008 00:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wga6pxtQFUlJ for ; Thu, 14 Feb 2008 00:44:50 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 482113A705B for ; Thu, 14 Feb 2008 00:44:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPZdb-000P6g-UT for radiusext-data@psg.com; Thu, 14 Feb 2008 08:40:11 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPZdF-000P37-Ub for radiusext@ops.ietf.org; Thu, 14 Feb 2008 08:39:51 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2A78076F44; Thu, 14 Feb 2008 09:39:49 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 1A13F76F42; Thu, 14 Feb 2008 09:39:49 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: request to recharter Date: Thu, 14 Feb 2008 09:39:44 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <200802111126.25340.stefan.winter@restena.lu> <200802131545.33245.stefan.winter@restena.lu> <000d01c86ee0$aa4753b0$d0d8787c@arubanetworks.com> In-Reply-To: <000d01c86ee0$aa4753b0$d0d8787c@arubanetworks.com> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart2914344.vqQyJgVDnk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > As the chairs have pointed out, the WG has almost completed its work & > it seems like the only thing being considered to continue radext is > radsec. So if there is not enough work to justify a WG (something I > doubt very much) then it doesn't seem to justify the continuation of > radext, either. Just publish an Informational RFC & be done with it. > BTW, what do the members of the "worldwide-operating roaming consortium" > think about giving up change control to the IETF (or do they think that > we will simply rubberstamp this work of sheer genius)? It is clear to everyone that change control goes to the IETF. It is not at = all=20 a problem. We are in the lucky position that we don't have any commercial=20 interest or pressure, but do this work for (excuse the pathos) "the greater= =20 good of humanity" - at least the subset of humanity we are concerned with:= =20 educational users and researchers. As such, we have no interest in=20 locked-down Intellectual Property. In fact, being a (former) GPL programmer= ,=20 I have an open source guy's typical aversion against closed, IPO'ed, NDA'ed= =20 stuff. Regarding the "genius" part: I'm aware that there are several parts in the= =20 current draft that need to be looked over carefully and modified, as the=20 discussion of the last few days has already shown. I'm happy that the=20 discussion is happening, that improvements are pointed out etc. Actually, t= he=20 discussion almost looks like WG work on it has already begun :-) Greetings, Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart2914344.vqQyJgVDnk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHs/5U+jm90f8eFWYRAjKsAJ0S40HwFWCH/dQUiuKsA0d2n5sO0ACffUc3 rmRLt03WtzcUg5mgvhS4uxg= =zcnb -----END PGP SIGNATURE----- --nextPart2914344.vqQyJgVDnk-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 14 15:12:40 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B803A67B2 for ; Thu, 14 Feb 2008 15:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=1.435, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEED75wC1U5b for ; Thu, 14 Feb 2008 15:12:39 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 60ED43A6956 for ; Thu, 14 Feb 2008 15:12:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPnAQ-000C7C-MP for radiusext-data@psg.com; Thu, 14 Feb 2008 23:06:58 +0000 Received: from [65.55.175.223] (helo=blu139-omc3-s23.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPn9z-000C53-63 for radiusext@ops.ietf.org; Thu, 14 Feb 2008 23:06:57 +0000 Received: from BLU127-DS3 ([65.55.162.187]) by blu139-omc3-s23.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Feb 2008 15:06:30 -0800 X-Originating-IP: [131.107.0.106] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" In-Reply-To: To: "Murtaza Chiba \(mchiba\)" , References: Subject: Re: inconsistency in RFC 5176 X-Unsent: 1 Date: Thu, 14 Feb 2008 15:06:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 14 Feb 2008 23:06:30.0896 (UTC) FILETIME=[3C471700:01C86F5E] Sender: owner-radiusext@ops.ietf.org Precedence: bulk There is no contradiction here. Section 3.5 says: "Values 200-299 represent successful completion, so that these values may only be sent within CoA-ACK or Disconnect-ACK packets and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet." There are only two values in the range 200-299 which are defined: 201 Residual Session Context Removed 202 Invalid EAP Packet (Ignored) Error 202 is explicitly prohibited for use by RFC 5176 implementations: "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification. Error 201 is also not currently defined for use with RFC 5176 since it refers to removal of key context, not modification or disconnection of sessions. Therefore, Section 3.5 and 3.6 are in agreement. > -----Original Message----- > From: Alfred HÎnes [mailto:ah@tr-sys.de] > Sent: Wednesday, February 13, 2008 5:51 PM > To: Murtaza Chiba (mchiba); Gopal Dommety (gdommety); Mark Eklund > (meklund); david@mitton.com > Cc: rfc-editor@rfc-editor.org > Subject: inconsistency in RFC 5176 > > Hello, > after studying the recently published RFC 5176 (RADIUS Dyn.Auth.) authored > by you, I stumbled over an apparent serious inconsistency in Section 3.5 > of that memo. > > The first clause there (on page 16) says: > > 3.5. Error-Cause > > Description > > It is possible that a Dynamic Authorization Server cannot honor > Disconnect-Request or CoA-Request packets for some reason. The > Error-Cause Attribute provides more detail on the cause of the > | problem. It MAY be included within CoA-NAK and Disconnect-NAK > | packets. > > The last sentence is consistent with the tables in Section 3.6 (pages > 20..22) that also exclude the use of the Error-Clause Attribute for the > CoA-ACK and Disconnect-ACK messages/packets. > > But surprisingly, the text in the "Value" clause in Section 3.5, from the > bottom of page 16 until page 18 repeatedly deals with inclusion or > non-inclusion of the Error-Clause Attribute into the CoA-ACK and > Disconnect-ACK messages/packets. Some of these sentences are only > confusing, but those that state applicability of the Error-Clause > Attribute contradict the intent ot the other parts of the memo. > > Please check. > > I suggest that this issue should be resolved by RFC Errata Notes > invalidating/removing all phrases in the "Value" clause that mention > CoA-ACK and Disconnect-ACK. > > > Kind regards, > Alfred HÎnes. > > P.S.: Due to inappropriate blackholing of DNS requests, apparently > caused by packet filtering based on *sorce* port somewhere > in Redmont, I cannot send a copy of this message to your > co-author Bernard Aboba. Please arrange to forward to him > a copy of this message -- thanks in advance. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 14 15:28:32 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967F93A68B5 for ; Thu, 14 Feb 2008 15:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=1.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAN8hMumZpxW for ; Thu, 14 Feb 2008 15:28:31 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D146C3A6803 for ; Thu, 14 Feb 2008 15:28:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPnRg-000DuL-Dq for radiusext-data@psg.com; Thu, 14 Feb 2008 23:24:48 +0000 Received: from [65.55.175.227] (helo=blu139-omc3-s27.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPnRd-000Dtw-S5 for radiusext@ops.ietf.org; Thu, 14 Feb 2008 23:24:47 +0000 Received: from BLU127-DS3 ([65.55.162.187]) by blu139-omc3-s27.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Feb 2008 15:24:45 -0800 X-Originating-IP: [131.107.0.106] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" In-Reply-To: <200802111126.25340.stefan.winter@restena.lu> <47B3214B.4050407@nitros9.org> <47B3DC02.7070709@nitros9.org> To: "Alan DeKok" Cc: "Stefan Winter" , References: <200802111126.25340.stefan.winter@restena.lu> <47B3214B.4050407@nitros9.org> <47B3DC02.7070709@nitros9.org> Subject: Re: request to recharter X-Unsent: 1 Date: Thu, 14 Feb 2008 15:24:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 14 Feb 2008 23:24:45.0698 (UTC) FILETIME=[C8D49E20:01C86F60] Sender: owner-radiusext@ops.ietf.org Precedence: bulk > The "RADIUS over TCP" document could reference existing RADIUS > practices, and explain in excruciating detail why they won't work for TCP. > > Also, some issues relating to RADIUS PDU's over a stream transport may > be discussed. e.g. receiving half a RADIUS packet and then a FIN is > *not* a problem. > > The MIB counters for > radiusAuthServMalformedAccessRequests should NOT be incremented. e.g. > receiving a PDU with malformed attributes means that the TCP connection > SHOULD be closed. > > Many RADIUS practices related to handling error cases require a PDU to > be "silently discarded". This won't work for TCP. The connection has > to be closed, too. > > The existing RFC's have to be audited, and a new > document issued which explains the correct behavior. This sounds like an outline of the issues that need to be handled in the RADSEC specification. Regardless of whether the RADEXT WG ends up adding the RADSEC work to the Charter, it would be useful to include this material in the document. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 14 18:21:45 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77EFC3A7102 for ; Thu, 14 Feb 2008 18:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=2.345, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BitTIwtjJJIm for ; Thu, 14 Feb 2008 18:21:44 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 4D49A3A7108 for ; Thu, 14 Feb 2008 18:19:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPq2A-0003i0-KD for radiusext-data@psg.com; Fri, 15 Feb 2008 02:10:38 +0000 Received: from [128.9.168.207] (helo=bosco.isi.edu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPq28-0003hn-8f for radiusext@ops.ietf.org; Fri, 15 Feb 2008 02:10:37 +0000 Received: by bosco.isi.edu (Postfix, from userid 70) id D17DE113E4C; Thu, 14 Feb 2008 18:10:32 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5090 on RADIUS Extension for Digest Authentication From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org Message-Id: <20080215021032.D17DE113E4C@bosco.isi.edu> Date: Thu, 14 Feb 2008 18:10:32 -0800 (PST) Sender: owner-radiusext@ops.ietf.org Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 5090 Title: RADIUS Extension for Digest Authentication Author: B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck Status: Standards Track Date: February 2008 Mailbox: baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, beckw@t-systems.com Pages: 33 Characters: 68299 Obsoletes: RFC4590 I-D Tag: draft-ietf-radext-rfc4590bis-02.txt URL: http://www.rfc-editor.org/rfc/rfc5090.txt This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 14 21:23:16 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A343A69D6 for ; Thu, 14 Feb 2008 21:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHO9274VMRyv for ; Thu, 14 Feb 2008 21:23:15 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A46273A69A6 for ; Thu, 14 Feb 2008 21:23:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPszK-000Iql-9V for radiusext-data@psg.com; Fri, 15 Feb 2008 05:19:54 +0000 Received: from [76.96.62.48] (helo=QMTA05.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPszH-000IqQ-Ph for radiusext@ops.ietf.org; Fri, 15 Feb 2008 05:19:53 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA05.westchester.pa.mail.comcast.net with comcast id pYz31Y00G0EZKEL550Z100; Fri, 15 Feb 2008 05:19:29 +0000 Received: from gzornt61 ([124.120.223.173]) by OMTA01.westchester.pa.mail.comcast.net with comcast id phKV1Y00C3l56bg3M00000; Fri, 15 Feb 2008 05:19:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=yS0Foppocm5N_DWF6pwA:9 a=Lc9RFNY41y14_X5afssA:7 a=BciZWn3T2WGlYyLGN-VvwUvUJFsA:4 a=zoKOyUDlhksA:10 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Murtaza Chiba \(mchiba\)'" , References: Subject: RE: inconsistency in RFC 5176 Date: Fri, 15 Feb 2008 12:19:27 +0700 Message-ID: <005801c86f92$61cbbe70$addf787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AchvXtAoq56LQbSASh+JB7x4lrv7HgAMSPUw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba <> scribbled on Friday, February 15, 2008 6:07 AM: > There is no contradiction here. Section 3.5 says: > > "Values 200-299 represent successful completion, so that these > values may only be sent within CoA-ACK or Disconnect-ACK packets and > MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet." > > There are only two values in the range 200-299 which are defined: > > 201 Residual Session Context Removed > 202 Invalid EAP Packet (Ignored) > > Error 202 is explicitly prohibited for use by RFC 5176 > implementations: > > "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST > NOT be sent by implementations of this specification. > > Error 201 is also not currently defined for use with RFC 5176 since > it refers to removal of key context, not modification or > disconnection of sessions. > > Therefore, Section 3.5 and 3.6 are in agreement. Thanks, Bernard, I was just about to respond in that very fashion, except that the table headed "Disconnect Messages" in section 3.6 completely disallows the use of the Error-Cause Attribute in Disconnect-ACK messages, while section 3.5 says; "Residual Session Context Removed" is sent in response to a Disconnect-Request if one or more user sessions are no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK. It seems that the table is in error to me. BTW, I can't find anything in the document that says that Error 201 is currently undefined; what am I missing? ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 15 01:27:22 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2894C3A6966 for ; Fri, 15 Feb 2008 01:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRk9cV3tcGUz for ; Fri, 15 Feb 2008 01:27:21 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 590A13A6A49 for ; Fri, 15 Feb 2008 01:27:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPwj2-000Ggh-VJ for radiusext-data@psg.com; Fri, 15 Feb 2008 09:19:20 +0000 Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JPwj0-000Gf0-93 for radiusext@ops.ietf.org; Fri, 15 Feb 2008 09:19:19 +0000 Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id plAH1Y0020bG4ec5400W00; Fri, 15 Feb 2008 09:19:01 +0000 Received: from gzornt61 ([124.120.223.173]) by OMTA03.westchester.pa.mail.comcast.net with comcast id plJo1Y0073l56bg3P00000; Fri, 15 Feb 2008 09:19:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=K3E-7NYQ7KgB6HzodQMA:9 a=Zbf9DVOUahQzSVg98mA1q0Q13F4A:4 a=vbBLm4PHyUgA:10 a=RFKBk05vbE4A:10 From: "Glen Zorn" To: "'Klaas Wierenga'" Cc: "'Stefan Winter'" , References: <200802111126.25340.stefan.winter@restena.lu> <008b01c86d13$290663f0$aedd787c@arubanetworks.com> <200802131545.33245.stefan.winter@restena.lu> <000d01c86ee0$aa4753b0$d0d8787c@arubanetworks.com> <47B3FC7D.9050005@wierenga.net> Subject: RE: request to recharter Date: Fri, 15 Feb 2008 16:18:46 +0700 Message-ID: <006801c86fb3$d488bfa0$addf787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47B3FC7D.9050005@wierenga.net> Thread-Index: Achu5AxrjeWCuOGvTSO1ht0i2Rs4agAzt+LQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk Klaas Wierenga scribbled on Thursday, February 14, 2008 3:32 PM: ... > > Nobody expects the IETF to just rubberstamp this work, on the > contrary, this is an effort to sollicit comments and make this better > than it would be if it was just thought up by a few individuals. I'm extremely pleased to hear that! For example, I'm inclined to think that TLSoSCTP might be a choice far less destructive of RADIUS semantics that TLSoTCP... > We > have built an infrastructure on what was available and ran into > operational problems with it, I believe it is perfectly legitimate > to try to address these problems. No doubt. The only question is where & how. I strongly believe that the radext WG is not the right place,\. The IETF standardization process may be the "how"; the normal way this is discovered is through the BOF process. > > Klaas Wierenga > (creator of eduroam) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 15 06:46:41 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949CA3A6A93 for ; Fri, 15 Feb 2008 06:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGBrTPqIhiX9 for ; Fri, 15 Feb 2008 06:46:40 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A2AE33A67DB for ; Fri, 15 Feb 2008 06:46:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ1l7-0006oc-Ud for radiusext-data@psg.com; Fri, 15 Feb 2008 14:41:49 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ1l4-0006o8-Kp for radiusext@ops.ietf.org; Fri, 15 Feb 2008 14:41:48 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 0346076F44; Fri, 15 Feb 2008 15:41:45 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id E793B76F42; Fri, 15 Feb 2008 15:41:44 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: request to recharter Date: Fri, 15 Feb 2008 15:41:40 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: "'Klaas Wierenga'" , radiusext@ops.ietf.org References: <200802111126.25340.stefan.winter@restena.lu> <47B3FC7D.9050005@wierenga.net> <006801c86fb3$d488bfa0$addf787c@arubanetworks.com> In-Reply-To: <006801c86fb3$d488bfa0$addf787c@arubanetworks.com> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart2274283.rqoavQJ91C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > I'm extremely pleased to hear that! For example, I'm inclined to think > that TLSoSCTP might be a choice far less destructive of RADIUS semantics > that TLSoTCP... SCTP was also considered, and in fact the Radiator implementation also offe= rs=20 SCTP as an option. The choice for TCP was a rather pragmatic one. SCTP is available on less=20 platforms and the implementations appeared to be a bit more flaky - e.g. th= e=20 SCTP implementation in Linux has had several DoS advisories, and I for one= =20 wouldn't want to rely on it yet. Regarding platforms: that LANCOM Access Point implementation wouldn't exist= if=20 SCTP would have been the transport - to my best knowledge, that feature is= =20 not even anywhere near their radar. So, the choice was to concentrate on something that works today and almost= =20 everywhere. If I take a look at how Diameter approached this: clients TCP and optional= =20 SCTP, servers both required: if we were to follow that, we'd still have to= =20 deal with all the complexities of TCP and add on top of that SCTP. And I'm= =20 not sure that trying SCTP first and falling back to TCP if that doesn't wor= k=20 really fits to the KISS mantra of the IETF. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart2274283.rqoavQJ91C Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHtaSo+jm90f8eFWYRAg8TAJ0VTSV/OM2SkjV4RlQaJE63BNTq/ACfc/Sb p4ckW4U+/pDd75hEYgcCdpc= =GfTz -----END PGP SIGNATURE----- --nextPart2274283.rqoavQJ91C-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 15 07:15:59 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2D83A67DB for ; Fri, 15 Feb 2008 07:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[AWL=1.704, BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V40wIqNtiZ4P for ; Fri, 15 Feb 2008 07:15:58 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 303F03A6ACA for ; Fri, 15 Feb 2008 07:15:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ2EM-000BQr-21 for radiusext-data@psg.com; Fri, 15 Feb 2008 15:12:02 +0000 Received: from [65.55.175.203] (helo=blu139-omc3-s3.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ2EJ-000BQT-B6 for radiusext@ops.ietf.org; Fri, 15 Feb 2008 15:12:00 +0000 Received: from BLU137-W13 ([65.55.162.187]) by blu139-omc3-s3.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Feb 2008 07:11:58 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_220d8099-f519-465d-bfe2-85ef69b920f9_" X-Originating-IP: [24.18.144.82] From: Bernard Aboba To: Glen Zorn , "'Murtaza Chiba (mchiba)'" , Subject: RE: inconsistency in RFC 5176 Date: Fri, 15 Feb 2008 07:11:58 -0800 Importance: Normal In-Reply-To: <005801c86f92$61cbbe70$addf787c@arubanetworks.com> References: <005801c86f92$61cbbe70$addf787c@arubanetworks.com> MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2008 15:11:58.0774 (UTC) FILETIME=[1BFBCD60:01C86FE5] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_220d8099-f519-465d-bfe2-85ef69b920f9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Error 201 is defined. However, RFC 5716 only defines to how modify author= izations or delete current sessions. Presumably if a session were not active, then = current implementations would return a Disconnect-NAK or CoA-NAK, rather than a Disconnect-ACK with Error-Code value 201.=20 > From: glenzorn@comcast.net > To: Bernard_Aboba@hotmail.com; mchiba@cisco.com; radiusext@ops.ietf.org > Subject: RE: inconsistency in RFC 5176 > Date: Fri, 15 Feb 2008 12:19:27 +0700 >=20 > Bernard Aboba <> scribbled on Friday, February 15, 2008 6:07 AM: >=20 > > There is no contradiction here. Section 3.5 says: > >=20 > > "Values 200-299 represent successful completion, so that these=20 > > values may only be sent within CoA-ACK or Disconnect-ACK packets and > > MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet." =20 > >=20 > > There are only two values in the range 200-299 which are defined: > >=20 > > 201 Residual Session Context Removed > > 202 Invalid EAP Packet (Ignored) > >=20 > > Error 202 is explicitly prohibited for use by RFC 5176 > > implementations:=20 > >=20 > > "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST > > NOT be sent by implementations of this specification. > >=20 > > Error 201 is also not currently defined for use with RFC 5176 since > > it refers to removal of key context, not modification or > > disconnection of sessions. =20 > >=20 > > Therefore, Section 3.5 and 3.6 are in agreement. >=20 > Thanks, Bernard, I was just about to respond in that very fashion, > except that the table headed "Disconnect Messages" in section 3.6 > completely disallows the use of the Error-Cause Attribute in > Disconnect-ACK messages, while section 3.5 says;=20 >=20 > "Residual Session Context Removed" is sent in response to a > Disconnect-Request if one or more user sessions are no longer > active, but residual session context was found and successfully > removed. This value is only sent within a Disconnect-ACK and MUST > NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK. >=20 > It seems that the table is in error to me. BTW, I can't find anything > in the document that says that Error 201 is currently undefined; what am > I missing? >=20 > ... >=20 --_220d8099-f519-465d-bfe2-85ef69b920f9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Error 201 is defined.  However, RFC 5716 only defines to  how mod= ify authorizations
or delete current sessions.  Presumably if a ses= sion were not active, then current
implementations would return a Discon= nect-NAK or CoA-NAK, rather than a
Disconnect-ACK with Error-Code value = 201.

> From: glenzorn@comcast.net
> To: Bernard_Aboba@hotm= ail.com; mchiba@cisco.com; radiusext@ops.ietf.org
> Subject: RE: inco= nsistency in RFC 5176
> Date: Fri, 15 Feb 2008 12:19:27 +0700
>=
> Bernard Aboba <> scribbled on Friday, February 15, 2008 6:0= 7 AM:
>
> > There is no contradiction here. Section 3.5 = says:
> >
> > "Values 200-299 represent successful compl= etion, so that these
> > values may only be sent within CoA-ACK o= r Disconnect-ACK packets and
> > MUST NOT be sent within a CoA-NA= K or Disconnect-NAK packet."
> >
> > There are only tw= o values in the range 200-299 which are defined:
> >
> >= 201 Residual Session Context Removed
> > 202 In= valid EAP Packet (Ignored)
> >
> > Error 202 is explicit= ly prohibited for use by RFC 5176
> > implementations:
> &g= t;
> > "Invalid EAP Packet (Ignored)" is a non-fatal error = that MUST
> > NOT be sent by implementations of this specifi= cation.
> >
> > Error 201 is also not currently defined = for use with RFC 5176 since
> > it refers to removal of key contex= t, not modification or
> > disconnection of sessions.
> &g= t;
> > Therefore, Section 3.5 and 3.6 are in agreement.
> =
> Thanks, Bernard, I was just about to respond in that very fashion,=
> except that the table headed "Disconnect Messages" in section 3.6<= br>> completely disallows the use of the Error-Cause Attribute in
>= ; Disconnect-ACK messages, while section 3.5 says;
>
> = "Residual Session Context Removed" is sent in response to a
> D= isconnect-Request if one or more user sessions are no longer
> = active, but residual session context was found and successfully
> = removed. This value is only sent within a Disconnect-ACK and MUST
&g= t; NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK.
> =
> It seems that the table is in error to me. BTW, I can't find anyt= hing
> in the document that says that Error 201 is currently undefine= d; what am
> I missing?
>
> ...
>
= --_220d8099-f519-465d-bfe2-85ef69b920f9_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 15 09:16:36 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDC33A6AE2 for ; Fri, 15 Feb 2008 09:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOLG2kno-zaQ for ; Fri, 15 Feb 2008 09:16:35 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E92B73A6AD0 for ; Fri, 15 Feb 2008 09:16:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ47Q-0002jn-VI for radiusext-data@psg.com; Fri, 15 Feb 2008 17:13:00 +0000 Received: from [76.96.30.17] (helo=QMTA10.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JQ47N-0002jK-WB for radiusext@ops.ietf.org; Fri, 15 Feb 2008 17:12:59 +0000 Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id ptAU1Y00C1HpZEsAA00M00; Fri, 15 Feb 2008 17:12:17 +0000 Received: from gzornt61 ([124.121.211.139]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id ptCM1Y008310cjg8a00000; Fri, 15 Feb 2008 17:12:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=edjKE5AfWFVbauQriqYA:9 a=xjXZTxohteqdzea3LHcA:7 a=lKTIVm5KPXmu_X19UiO8LhOOq8cA:4 a=si9q_4b84H0A:10 a=EfJqPEOeqlMA:10 a=JfD0Fch1gWkA:10 a=gJcimI5xSWUA:10 a=Ko0JbywxA1D3Ib-HTe4A:9 a=Id-a2kUplA_oyAPN_dIA:7 a=pHo-sV8yvlOduzMH5LHt8xuM848A:4 a=AfD3MYMu9mQA:10 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Murtaza Chiba \(mchiba\)'" , References: <005801c86f92$61cbbe70$addf787c@arubanetworks.com> Subject: RE: inconsistency in RFC 5176 Date: Sat, 16 Feb 2008 00:12:19 +0700 Message-ID: <003201c86ff5$ff777a70$8bd3797c@arubanetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C87030.ABD65270" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Achv5agwON227gTLTXeU72ZWj6fc/QAECBiw Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C87030.ABD65270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Error 201 is defined. However, RFC 5716 only defines to how modify authorizations or delete current sessions. Presumably if a session were not active, then current implementations would return a Disconnect-NAK or CoA-NAK, rather than a Disconnect-ACK with Error-Code value 201. OK, but shouldn't the Error-Cause attribute still be allowed in the table? > From: glenzorn@comcast.net > To: Bernard_Aboba@hotmail.com; mchiba@cisco.com; radiusext@ops.ietf.org > Subject: RE: inconsistency in RFC 5176 > Date: Fri, 15 Feb 2008 12:19:27 +0700 > > Bernard Aboba <> scribbled on Friday, February 15, 2008 6:07 AM: > > > There is no contradiction here. Section 3.5 says: > > > > "Values 200-299 represent successful completion, so that these > > values may only be sent within CoA-ACK or Disconnect-ACK packets and > > MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet." > > > > There are only two values in the range 200-299 which are defined: > > > > 201 Residual Session Context Removed > > 202 Invalid EAP Packet (Ignored) > > > > Error 202 is explicitly prohibited for use by RFC 5176 > > implementations: > > > > "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST > > NOT be sent by implementations of this specification. > > > > Error 201 is also not currently defined for use with RFC 5176 since > > it refers to removal of key context, not modification or > > disconnection of sessions. > > > > Therefore, Section 3.5 and 3.6 are in agreement. > > Thanks, Bernard, I was just about to respond in that very fashion, > except that the table headed "Disconnect Messages" in section 3.6 > completely disallows the use of the Error-Cause Attribute in > Disconnect-ACK messages, while section 3.5 says; > > "Residual Session Context Removed" is sent in response to a > Disconnect-Request if one or more user sessions are no longer > active, but residual session context was found and successfully > removed. This value is only sent within a Disconnect-ACK and MUST > NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK. > > It seems that the table is in error to me. BTW, I can't find anything > in the document that says that Error 201 is currently undefined; what am > I missing? > > ... > ------=_NextPart_000_0033_01C87030.ABD65270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Error 201 is = defined.  However,=20 RFC 5716 only defines to  how modify authorizations
or delete = current=20 sessions.  Presumably if a session were not active, then=20 current
implementations would return a Disconnect-NAK or CoA-NAK, = rather than=20 a
Disconnect-ACK with Error-Code value 201.  
 
OK, but=20 shouldn't the Error-Cause attribute still be allowed in the=20 table? 

> From: = glenzorn@comcast.net
> To:=20 Bernard_Aboba@hotmail.com; mchiba@cisco.com; = radiusext@ops.ietf.org
>=20 Subject: RE: inconsistency in RFC 5176
> Date: Fri, 15 Feb 2008 = 12:19:27=20 +0700
>
> Bernard Aboba <> scribbled on Friday, = February 15,=20 2008 6:07 AM:
>
> > There is no contradiction here. = Section 3.5=20 says:
> >
> > "Values 200-299 represent successful=20 completion, so that these
> > values may only be sent within = CoA-ACK=20 or Disconnect-ACK packets and
> > MUST NOT be sent within a = CoA-NAK or=20 Disconnect-NAK packet."
> >
> > There are only two = values in=20 the range 200-299 which are defined:
> >
> > 201 = Residual=20 Session Context Removed
> > 202 Invalid EAP Packet = (Ignored)
>=20 >
> > Error 202 is explicitly prohibited for use by RFC=20 5176
> > implementations:
> >
> > "Invalid = EAP=20 Packet (Ignored)" is a non-fatal error that MUST
> > NOT be = sent by=20 implementations of this specification.
> >
> > Error = 201 is=20 also not currently defined for use with RFC 5176 since
> > it = refers to=20 removal of key context, not modification or
> > disconnection = of=20 sessions.
> >
> > Therefore, Section 3.5 and 3.6 are = in=20 agreement.
>
> Thanks, Bernard, I was just about to respond = in that=20 very fashion,
> except that the table headed "Disconnect Messages" = in=20 section 3.6
> completely disallows the use of the Error-Cause = Attribute=20 in
> Disconnect-ACK messages, while section 3.5 says;
> =
>=20 "Residual Session Context Removed" is sent in response to a
>=20 Disconnect-Request if one or more user sessions are no longer
> = active,=20 but residual session context was found and successfully
> removed. = This=20 value is only sent within a Disconnect-ACK and MUST
> NOT be sent = within a=20 CoA-ACK, Disconnect-NAK, or CoA-NAK.
>
> It seems that the = table is=20 in error to me. BTW, I can't find anything
> in the document that = says=20 that Error 201 is currently undefined; what am
> I = missing?
>=20
> ...
>
------=_NextPart_000_0033_01C87030.ABD65270-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 19 04:50:43 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D8128C587 for ; Tue, 19 Feb 2008 04:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d68Jf32sGhSy for ; Tue, 19 Feb 2008 04:50:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EF6728C573 for ; Tue, 19 Feb 2008 04:50:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRRqC-000CUG-HT for radiusext-data@psg.com; Tue, 19 Feb 2008 12:44:56 +0000 Received: from [68.142.200.154] (helo=web30901.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRRq8-000CT3-6a for radiusext@ops.ietf.org; Tue, 19 Feb 2008 12:44:54 +0000 Received: (qmail 61001 invoked by uid 60001); 19 Feb 2008 12:44:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=5OoFWJ0vM5b2OftJuqtDc9iu7G1hAsiK2ilTUf/r6rswSgQagIgDHSx/aZtSQErTbhynCPszuJgM/7PsKe6Kn+V6lRl8TY9Le7SOairDvSMYCINtH68m33pVgW14jLo9aWNcQ75liyf5yJLbZXqO22b287t4rajFc4JLGKpwc+w=; X-YMail-OSG: TB5s1oAVM1kxcy5viv4LhEN.pv4gOr3Eb.Kf86sTtTXvzX_deoZYLTAp0UO78azjdxJq0rnxhF7.5pv2lwYILiPy4R0KEokP_EHawYk94UHsRhNSnn4- Received: from [193.54.225.198] by web30901.mail.mud.yahoo.com via HTTP; Tue, 19 Feb 2008 04:44:50 PST X-Mailer: YahooMailRC/902.30 YahooMailWebService/0.7.162 Date: Tue, 19 Feb 2008 04:44:50 -0800 (PST) From: vamsi krishna Subject: new draft proposal To: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <825804.56409.qm@web30901.mail.mud.yahoo.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Dear All, I am proposing a new draft in the radext WG on Radius Mobility Extensions. you can fnd it at this link http://tools.ietf.org/wg/radext/draft-gondi-radext-radius-mobility-00.txt The main aim of the draft is to extebd the functionalities of RADIUS server for mobility management. In this context we have proposed new modules and attributes where a Radius server can communicate with the different network entities and another radius servers for mobility context transfer. We have demobnstrated its capabilities using PMIPv4. i am keen to discuss the issues raised by the WG in the mailing list to enhance our proposed solution. thankng you, gondi. Vamsi Krishna GONDI, 16 rue Jean Pierre Laurens, Fontenay Aux Roses, 92260, France. Ph no. +33 (0)6 20 38 51 53 ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 19 04:57:41 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0413A6929 for ; Tue, 19 Feb 2008 04:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIkSFPEz36PW for ; Tue, 19 Feb 2008 04:57:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 021FB3A680B for ; Tue, 19 Feb 2008 04:57:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRRxF-000DNQ-Sc for radiusext-data@psg.com; Tue, 19 Feb 2008 12:52:13 +0000 Received: from [68.142.200.156] (helo=web30903.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRRxB-000DMy-RS for radiusext@ops.ietf.org; Tue, 19 Feb 2008 12:52:12 +0000 Received: (qmail 7238 invoked by uid 60001); 19 Feb 2008 12:52:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=anSQocG5Fq8ZeIUqs6jmTJyyfpHSyP+xjNst6FXFGHXHnHAQ+thmq9Ttb6Z6nejnXqPhuGsSR33h4aBYHo4TURmF62ZwPULm/zgn8mGBTZOyvPquOdjUY6mnf6boeVLWTy3Y7LE+QScSlVSjbI1cu6Msw985ohs35QR95HD/iNQ=; X-YMail-OSG: 7FhvrSIVM1kaSQDPeUE5EvfJVyDkHj7gCMl7gnCvL3vK.RWOplcyrkDgWY83kx1P9Lz2NdN4c_3Da9yGPVZA4Sxbq5SiRIcw6ZTPHqcBIHw0DNhKyQwXQ3PZ4M3XxQ-- Received: from [193.54.225.198] by web30903.mail.mud.yahoo.com via HTTP; Tue, 19 Feb 2008 04:52:07 PST X-Mailer: YahooMailRC/902.30 YahooMailWebService/0.7.162 Date: Tue, 19 Feb 2008 04:52:07 -0800 (PST) From: vamsi krishna Subject: new draft proposal on Radius support for roaming and handovers To: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <13150.3575.qm@web30903.mail.mud.yahoo.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Dear all, I am proposing another new draft for this WG on new extensions for radius supporting roaming and handover. you can check it at this link. Roaming Extensions for radius server http://tools.ietf.org/wg/radext/draft-gondi-radext-radius-roaming-01.txt In this draft we have proposed different extensions for extending the functionalities of radius server for not only to authenticatio, authorization and accounting but also for wireless mobiity. In this draft we have proposed 4 new mechanisms which can be extended later, on network selection, handover management, security context transfer management and mobility context management. In ths draf we have proposed new attributes to support RADIUS for extending functionalities for supporting seamless roaming services. I am very interested to address the issues rasied by the WG, and also suggestions and remarks to enhance the proposed solutions for possible radius extensions. thanking you, gondi. Vamsi Krishna GONDI, 16 rue Jean Pierre Laurens, Fontenay Aux Roses, 92260, France. Ph no. +33 (0)6 20 38 51 53 ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 19 17:32:56 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA3128C3EB for ; Tue, 19 Feb 2008 17:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.616 X-Spam-Level: X-Spam-Status: No, score=0.616 tagged_above=-999 required=5 tests=[AWL=-2.489, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T3pmJgV1Kbp for ; Tue, 19 Feb 2008 17:32:55 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A753928C70A for ; Tue, 19 Feb 2008 17:32:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRdgm-000OTS-MJ for radiusext-data@psg.com; Wed, 20 Feb 2008 01:24:00 +0000 Received: from [65.55.175.205] (helo=blu139-omc3-s5.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JRdgj-000OT8-SA for radiusext@ops.ietf.org; Wed, 20 Feb 2008 01:23:59 +0000 Received: from BLU137-DS1 ([65.55.162.189]) by blu139-omc3-s5.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Feb 2008 17:23:56 -0800 X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: Call for Agenda items for IETF 71 RADEXT WG meeting Date: Tue, 19 Feb 2008 17:14:41 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C8731A.EA11FB10" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 20 Feb 2008 01:23:56.0899 (UTC) FILETIME=[43580B30:01C8735F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C8731A.EA11FB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 71, the RADEXT WG is currently scheduled to meet on Friday, = March 14 from 9 AM - 11:30 AM.=20 If you would like time on the RADEXT WG agenda at IETF 71, please send a = note to the chairs. ------=_NextPart_000_0090_01C8731A.EA11FB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 71, the RADEXT WG is currently = scheduled to=20 meet on Friday, March 14 from 9 AM - 11:30 AM.
If you would like time on the RADEXT WG = agenda at=20 IETF 71, please send a note to the chairs.
------=_NextPart_000_0090_01C8731A.EA11FB10-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 21 07:52:51 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0937128C712 for ; Thu, 21 Feb 2008 07:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhNqh-YeIMKk for ; Thu, 21 Feb 2008 07:52:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFEF628C9D4 for ; Thu, 21 Feb 2008 07:52:01 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSDbh-000Mc9-PM for radiusext-data@psg.com; Thu, 21 Feb 2008 15:45:09 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSDbY-000Mab-8j for radiusext@ops.ietf.org; Thu, 21 Feb 2008 15:45:03 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id B9EDE28CA3C; Thu, 21 Feb 2008 07:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-extended-attributes-01.txt Message-Id: <20080221154501.B9EDE28CA3C@core3.amsl.com> Date: Thu, 21 Feb 2008 07:45:01 -0800 (PST) Sender: owner-radiusext@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Extended Remote Authentication Dial In User Service (RADIUS) Attributes Author(s) : Y. Li, et al. Filename : draft-ietf-radext-extended-attributes-01.txt Pages : 13 Date : 2008-02-21 In order for the Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications the RADIUS attribute type space must be extended beyond the current limit of 255 possible attribute types while maintaining backwards compatibility with the existing protocol. This document defines a mechanism to accomplish that task, along with standard methods to group together related attributes and to encode values that don't fit into 253 octets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-extended-attributes-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-extended-attributes-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-21074336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-extended-attributes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-extended-attributes-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-21074336.I-D\@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 21 08:57:08 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669DC28C73A for ; Thu, 21 Feb 2008 08:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.607 X-Spam-Level: X-Spam-Status: No, score=-4.607 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX3j49dDmk3w for ; Thu, 21 Feb 2008 08:57:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F98528CB1D for ; Thu, 21 Feb 2008 08:51:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSEa5-0007Nh-DC for radiusext-data@psg.com; Thu, 21 Feb 2008 16:47:33 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSEZy-0007Ma-ES for radiusext@ops.ietf.org; Thu, 21 Feb 2008 16:47:31 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2008 08:47:26 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1LGlPp9030252; Thu, 21 Feb 2008 08:47:25 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1LGlMR2014753; Thu, 21 Feb 2008 16:47:24 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 08:47:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: request to recharter Date: Thu, 21 Feb 2008 08:48:07 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: request to recharter Thread-Index: AchvYNsBQjET5/gUS0ixPIZXy35shQFSAgew From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , "Alan DeKok" Cc: "Stefan Winter" , X-OriginalArrivalTime: 21 Feb 2008 16:47:22.0303 (UTC) FILETIME=[6DF384F0:01C874A9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1976; t=1203612445; x=1204476445; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20request=20to=20recharter |Sender:=20; bh=puXjXLPPquSzXUSDOfbbkqihJniKq7+9YGmSFyOISzo=; b=qM23lONBHQB/wHqJ5i9iPlCnQTd0GDa1/DgWwu4PVf3Yh61L31aNoQ1mmp 90DoA+xxw6fh3UIo3Rv9JSkxh+spu780Te6ExIwh6zZW2m+nao1bDfrMXgNo G7XLrPCIvSO3G2oiUATCsUY+Zoh7BaWFkACia1WQIq8r5Z5+lBuho=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-radiusext@ops.ietf.org Precedence: bulk I'm not in favor of taking RADSEC on as a working group item without a better understanding of the goals. There is more to RADSEC then just TCP transport and algorithmic agility. I think it would be appropriate to have a BOF to understand that scope of what RADSEC is trying to achieve.=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, February 14, 2008 3:25 PM > To: Alan DeKok > Cc: Stefan Winter; radiusext@ops.ietf.org > Subject: Re: request to recharter >=20 > > The "RADIUS over TCP" document could reference existing RADIUS=20 > > practices, and explain in excruciating detail why they=20 > won't work for TCP. > > > > Also, some issues relating to RADIUS PDU's over a stream transport=20 > > may be discussed. e.g. receiving half a RADIUS packet and=20 > then a FIN=20 > > is > > *not* a problem. > > > > The MIB counters for > > radiusAuthServMalformedAccessRequests should NOT be=20 > incremented. e.g. > > receiving a PDU with malformed attributes means that the TCP=20 > > connection SHOULD be closed. > > > > Many RADIUS practices related to handling error cases=20 > require a PDU=20 > > to be "silently discarded". This won't work for TCP. The=20 > connection=20 > > has to be closed, too. > > > > The existing RFC's have to be audited, and a new document=20 > issued which=20 > > explains the correct behavior. >=20 > This sounds like an outline of the issues that need to be=20 > handled in the RADSEC specification. > Regardless of whether the RADEXT WG ends up adding the RADSEC=20 > work to the Charter, it would be useful to include this=20 > material in the document.=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Feb 24 21:08:02 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654673A697D for ; Sun, 24 Feb 2008 21:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MWzxK1lvdMZ for ; Sun, 24 Feb 2008 21:08:01 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E81D328C21C for ; Sun, 24 Feb 2008 21:07:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTVRZ-000HLL-Fz for radiusext-data@psg.com; Mon, 25 Feb 2008 05:00:01 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTVRV-000HKm-Uf for radiusext@ops.ietf.org; Mon, 25 Feb 2008 04:59:59 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id D022F3A6B98; Sun, 24 Feb 2008 21:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-management-authorization-02.txt Message-Id: <20080225050001.D022F3A6B98@core3.amsl.com> Date: Sun, 24 Feb 2008 21:00:01 -0800 (PST) Sender: owner-radiusext@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-02.txt Pages : 20 Date : 2008-02-24 This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities, generally referred to as Network Access Servers (NASes). Specific provisions are made for remote management via framed management protocols, for granular levels of access rights and management privileges, and for specification of a protected transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-management-authorization-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-management-authorization-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-24205509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-management-authorization-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24205509.I-D\@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Feb 25 06:02:48 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD38528C711 for ; Mon, 25 Feb 2008 06:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.045 X-Spam-Level: X-Spam-Status: No, score=-1.045 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWjQWR6cwEse for ; Mon, 25 Feb 2008 06:02:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5871428C789 for ; Mon, 25 Feb 2008 06:01:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTdlC-000HU8-4a for radiusext-data@psg.com; Mon, 25 Feb 2008 13:52:50 +0000 Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTdl3-000HQi-Ek for radiusext@ops.ietf.org; Mon, 25 Feb 2008 13:52:44 +0000 Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id tncr1Y00P0S2fkCA50CZ00; Mon, 25 Feb 2008 13:51:56 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id tpsf1Y00424Kx1C8V00000; Mon, 25 Feb 2008 13:52:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=t5KqSjJfkoR1yp8hmnIA:9 a=1F1IWI-CtS8nqqw703sA:7 a=b59FLoVJtf6BK-pKICxqSMoBxkgA:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: References: <20080225050001.D022F3A6B98@core3.amsl.com> Subject: RE: I-D Action:draft-ietf-radext-management-authorization-02.txt Date: Mon, 25 Feb 2008 08:52:45 -0500 Message-ID: <147101c877b5$b3c00170$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach3a9803fi9WF6ARqSHoDl08+mcrAAR8w9A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080225050001.D022F3A6B98@core3.amsl.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the RADIUS EXTensions Working Group of the > IETF. > > Title : Remote Authentication Dial-In User Service > (RADIUS) Authorization for Network Access Server (NAS) Management > Author(s) : D. Nelson, G. Weber > Filename : draft-ietf-radext-management-authorization-02.txt > Pages : 20 > Date : 2008-02-24 > > This document describes Remote Authentication Dial-In User Service > (RADIUS) attributes for the authorization and service provisioning of > local and remote management of embedded systems and other managed > entities, generally referred to as Network Access Servers (NASes). > Specific provisions are made for remote management via framed > management protocols, for granular levels of access rights and > management privileges, and for specification of a protected transport > protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-management- > authorization-02.txt I'm forwarding a list of the open issues that I culled from the RADEXT mailing list, in preparing the -02 version of this draft. All of the open issues listed below have been addressed in one fashion or another. I would like to call attention to one change in particular. One particularly thorny issue with the -01 draft is the relationship (or lack thereof) between the application layer management protocols, as provisioned in the Framed-Management-Protocol attribute, and the protected transport protocols, as provisioned in the Management-Transport-Protocol attribute. Part of the confusion is whether the latter attribute should include "traditional" Layer 4 network transports (e.g. TCP, UDP, SCTP, etc.) or only "protected transports" (TLS, DTLS, SSH, etc.) The other part of the confusion is which transports can be use with which management applications. I think the -01 version suffers from "creeping complexity", caused partly by various review comments along the way, and partly by muddled thinking on my part. Having been away from this document for some months, it occurred to me that the problem was that the Management-Transport-Protocol attribute was simply over-specifying the problem. I don't think that anyone really needs to micro-manage the choice of protected transport protocol, any more than we need to micromanage the selection of remote terminal protocol in providing the NAS-Prompt service. The resolution to this particular set of comments was to change the attribute to Management-Transport-Protection, and only provision that which is important -- the level of protection required for the remote management session. The four possible values of this attribute are: o No-Protection: No transport protection is required. Accept connections via any supported transport. o Integrity-Protection: The management session requires protection in a secure or protected transport, that is supported by the management access protocol and implementation. The secure transport MUST provide Integrity Protection. o Confidentiality-Protection: The management session requires protection in a secure or protected transport, that is supported by the management access protocol and implementation. The secure transport MUST provide Confidentiality Protection. o Integrity-Confidentiality-Protection: The management session requires protection in a secure or protected transport, that is supported by the management access protocol and implementation. The secure transport MUST provide both Integrity Protection and Confidentiality Protection. The complete list of issues addressed in the -02 revision is as follows: -- Further explain the distinction between web-based management (HTML over HTTP) vs. other methods, such as NETCONF (XML over HTTP). Done. -- Provide informational text listing the "default" transport for each of the management protocols specified by Framed-Management-Protocol (e.g. for SNMP it's unprotected UDP). The "default" transport is no longer at issue. The Management-Transport-Protocols attribute has been re-cast as the Management-Transport-Protection attribute. -- Further explain what protocols (e.g. telnet, rlogin) are involved in providing the NAS-Prompt Service-Type with each value of Management-Transport-Protocol. No longer applicable. -- Explain the current remote console usage model of NAS-Port-Type of Virtual with Service-Type of NAS-Prompt. Done. -- Should Management-Privilege-Level apply to Framed-Management-Protocol? E.g. for access control of SNMP or NETCONF? No. Done. -- Would the locally stored policies referenced by Management-Policy-Id ever be too complicated to be stored on the NAS, requiring multiple policy and access control attributes from the RADIUS server to express that complexity? No. Done. -- Clarify the "local scope" of policy definitions on the NAS referenced by Management-Policy-Id? Done. -- The proposed RADIUS attributes do not carry what really counts - the security level, e.g. I might accept SNMP access as long as the actual security level is providing authPriv, regardless how this is achieved. Done? I think the Management-Transport-Protection attribute addresses this issue. -- The two new attributes Framed-Management-Protocol and Transport-Protocol are enumerations that may need to be extended (e.g. NETCONF is missing in the first one already). I suggest that the IANA section spells out the rules for extending these enumerations, e.g. by requiring a specification. Done. -- Are HTTP and HTTPS really two different framed management protocols? Or is HTTPS just HTTP with a transport of TLS? Done. -- I do not think SSH really carries telnet in the sense of the telnet protocol. Done. -- Would it be possible to indicate CLI access via telnet over tls? No longer applicable. -- I think that the way you would specify the secure remote terminal service of SSH would be using Service-Type=NAS-Prompt, Management-Transport-Protocol=SSH. No longer applicable. -- With respect to TLS/DTLS, what mode is intended? Mutual auth with certs? Server-only auth? TLS-PSK? No longer applicable. -- I thought you need to specify what "default" means for each Framed-Management entry. No longer applicable. -- The NAS-Prompt Service-Type works for all of: local console connections, telnet, rlogin, ssh, (and more) remote connections. Done. -- The only thing we are trying to specify here is whether the remote terminal service is being carried over a secure transport. Do we really care what the transport layer protocol is? I think that what we care about is whether it over a secure or non-secure transport. Done. As always, further comments are welcome. Hopefully you will find that this draft version has addressed your open issues in a satisfactory manner. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 26 02:57:49 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DBA13A6C1E for ; Tue, 26 Feb 2008 02:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.066 X-Spam-Level: X-Spam-Status: No, score=-0.066 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL973TvzzcW1 for ; Tue, 26 Feb 2008 02:57:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F3EE03A68FC for ; Tue, 26 Feb 2008 02:57:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTxOc-000DXf-SW for radiusext-data@psg.com; Tue, 26 Feb 2008 10:50:50 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTxOQ-000DVD-RO for radiusext@ops.ietf.org; Tue, 26 Feb 2008 10:50:46 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1733C8A3F6; Tue, 26 Feb 2008 11:50:38 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 00438-02-27; Tue, 26 Feb 2008 11:50:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC20D8A57C; Tue, 26 Feb 2008 11:46:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A2DB64D0373; Tue, 26 Feb 2008 11:46:43 +0100 (CET) Date: Tue, 26 Feb 2008 11:46:43 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-management-authorization-02.txt Message-ID: <20080226104643.GB2112@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org References: <20080225050001.D022F3A6B98@core3.amsl.com> <147101c877b5$b3c00170$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147101c877b5$b3c00170$011716ac@NEWTON603> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-radiusext@ops.ietf.org Precedence: bulk On Mon, Feb 25, 2008 at 08:52:45AM -0500, David B. Nelson wrote: > The resolution to this particular set of comments was to change the > attribute to Management-Transport-Protection, and only provision that which > is important -- the level of protection required for the remote management > session. The four possible values of this attribute are: > > o No-Protection: No transport protection is required. Accept > connections via any supported transport. > > o Integrity-Protection: The management session requires protection > in a secure or protected transport, that is supported by the > management access protocol and implementation. The secure > transport MUST provide Integrity Protection. > > o Confidentiality-Protection: The management session requires > protection in a secure or protected transport, that is supported > by the management access protocol and implementation. The secure > transport MUST provide Confidentiality Protection. > > o Integrity-Confidentiality-Protection: The management session > requires protection in a secure or protected transport, that is > supported by the management access protocol and implementation. > The secure transport MUST provide both Integrity Protection and > Confidentiality Protection. I like the general approach. I am wondering however how authentication fits into the above list or whether you assume integrity-protection and confidentiality-protection imply authentication of the two parties involved. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 26 05:02:15 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9AB3A6BCA for ; Tue, 26 Feb 2008 05:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.059 X-Spam-Level: X-Spam-Status: No, score=-0.059 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CKtC8DgtuTi for ; Tue, 26 Feb 2008 05:02:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD7AC3A695D for ; Tue, 26 Feb 2008 05:02:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTzMP-0006Xh-DJ for radiusext-data@psg.com; Tue, 26 Feb 2008 12:56:41 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTzLe-0006Mb-OL for radiusext@ops.ietf.org; Tue, 26 Feb 2008 12:56:17 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 316118B175; Tue, 26 Feb 2008 13:55:53 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14874-02-48; Tue, 26 Feb 2008 13:55:47 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 919438A4F4; Tue, 26 Feb 2008 13:33:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 821F14D086F; Tue, 26 Feb 2008 13:33:35 +0100 (CET) Date: Tue, 26 Feb 2008 13:33:35 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-management-authorization-02.txt Message-ID: <20080226123335.GB2536@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org References: <20080225050001.D022F3A6B98@core3.amsl.com> <147101c877b5$b3c00170$011716ac@NEWTON603> <20080226104643.GB2112@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080226104643.GB2112@elstar.local> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-radiusext@ops.ietf.org Precedence: bulk On Tue, Feb 26, 2008 at 11:46:43AM +0100, Juergen Schoenwaelder wrote: > On Mon, Feb 25, 2008 at 08:52:45AM -0500, David B. Nelson wrote: > > > The resolution to this particular set of comments was to change the > > attribute to Management-Transport-Protection, and only provision that which > > is important -- the level of protection required for the remote management > > session. The four possible values of this attribute are: > > > > o No-Protection: No transport protection is required. Accept > > connections via any supported transport. > > > > o Integrity-Protection: The management session requires protection > > in a secure or protected transport, that is supported by the > > management access protocol and implementation. The secure > > transport MUST provide Integrity Protection. > > > > o Confidentiality-Protection: The management session requires > > protection in a secure or protected transport, that is supported > > by the management access protocol and implementation. The secure > > transport MUST provide Confidentiality Protection. > > > > o Integrity-Confidentiality-Protection: The management session > > requires protection in a secure or protected transport, that is > > supported by the management access protocol and implementation. > > The secure transport MUST provide both Integrity Protection and > > Confidentiality Protection. > > I like the general approach. > > I am wondering however how authentication fits into the above list or > whether you assume integrity-protection and confidentiality-protection > imply authentication of the two parties involved. I now realize that my comment is kind of stupid since the fact that there is a RADIUS request kind of implies authentication happening. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 26 05:23:34 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DA728C315 for ; Tue, 26 Feb 2008 05:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzSwbeq5lqse for ; Tue, 26 Feb 2008 05:23:33 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 69C8C28C311 for ; Tue, 26 Feb 2008 05:23:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTzi1-0009U6-BJ for radiusext-data@psg.com; Tue, 26 Feb 2008 13:19:01 +0000 Received: from [76.96.30.96] (helo=QMTA09.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTzhu-0009T1-NC for radiusext@ops.ietf.org; Tue, 26 Feb 2008 13:18:56 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id u9dN1Y0090cQ2SLA90Ca00; Tue, 26 Feb 2008 13:18:15 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id uDJs1Y00E24Kx1C8W00000; Tue, 26 Feb 2008 13:18:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=SjwyaUyHFlJ-liQSRAwA:9 a=DSL--aAioOxNqPQo6m6rOrcmVtEA:4 a=3I_whO4B8K8A:10 From: "David B. Nelson" To: References: <20080225050001.D022F3A6B98@core3.amsl.com> <147101c877b5$b3c00170$011716ac@NEWTON603> <20080226104643.GB2112@elstar.local> Subject: RE: I-D Action:draft-ietf-radext-management-authorization-02.txt Date: Tue, 26 Feb 2008 08:18:59 -0500 Message-ID: <1a2401c8787a$26c72df0$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach4ZW8JIzANLltKT/aHWN4zvAhHbQAEUp6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080226104643.GB2112@elstar.local> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Juergen Schoenwaelder writes... > > The resolution to this particular set of comments was to change > > the attribute to Management-Transport-Protection, and only > > provision that which is important -- the level of protection > > required for the remote management session. The four possible > > values of this attribute are: > > > > o No-Protection: No transport protection is required. Accept > > connections via any supported transport. > > > > o Integrity-Protection: The management session requires protection > > in a secure or protected transport, that is supported by the > > management access protocol and implementation. The secure > > transport MUST provide Integrity Protection. > > > > o Confidentiality-Protection: The management session requires > > protection in a secure or protected transport, that is supported > > by the management access protocol and implementation. The secure > > transport MUST provide Confidentiality Protection. > > > > o Integrity-Confidentiality-Protection: The management session > > requires protection in a secure or protected transport, that is > > supported by the management access protocol and implementation. > > The secure transport MUST provide both Integrity Protection and > > Confidentiality Protection. > > I like the general approach. > > I am wondering however how authentication fits into the above list or > whether you assume integrity-protection and confidentiality-protection > imply authentication of the two parties involved. RADIUS is all about authentication. That basic function of RADIUS has not changed. The RADIUS server authenticates the user (via one of the supported authentication methods) before choosing to send an Access-Accept message. If the RADIUS server chooses not to authenticate an actual user (e.g. Call-Check) it would likely not authorize provision of a service that required a protected transport. (Although there may be valid uses case for doing so...) It is reasonable to assume that in any use case where authentication of the user (e.g. the SNMP principal attempting to connect to the NAS) is important, that receipt of an Access-Accept message at the NAS indicates that the user has been authenticated by the RADIUS server. What is not specified in this mechanism is a cryptographic binding between the authenticated RADIUS user identity and the keys, certificates, or other credentials used to establish the protected transport session. The NAS may be in a position to perform this "binding" by relating the authenticated RADIUS user identity to some local transport session handle. The details of this would be a matter of implementation, I would think. If the NAS is capable of determining, via its API to the transport security layer, that a protected transport is in use and what its properties are, the NAS is in a position or enforce the provisions of the Management-Transport-Protection attribute. If the NAS is not capable of making that kind of determination (e.g. because of limitations in the APIs, etc.), then the whole issue of requiring a protected transport is very questionable, whether you call it out by name (e.g. SSH or TLS) or you call it out by property (e.g. Integrity-Protection or Confidentiality-Protection). Does that line of thinking make sense to you? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 26 05:39:25 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D2528C44D for ; Tue, 26 Feb 2008 05:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.048 X-Spam-Level: X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[AWL=-1.470, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERSZwGT-wjoL for ; Tue, 26 Feb 2008 05:39:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A2DE28C44F for ; Tue, 26 Feb 2008 05:39:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTzy6-000BiH-Ch for radiusext-data@psg.com; Tue, 26 Feb 2008 13:35:38 +0000 Received: from [76.96.30.96] (helo=QMTA09.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JTzy3-000Bhk-6q for radiusext@ops.ietf.org; Tue, 26 Feb 2008 13:35:37 +0000 Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id uB8u1Y0030EPchoA907g00; Tue, 26 Feb 2008 13:34:56 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id uDbY1Y00E24Kx1C8M00000; Tue, 26 Feb 2008 13:35:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=YvAXcyLmAQRW4H__-b0A:9 a=ZYQeThF7wxhnHcfKj6TGVu14bYYA:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: Cc: References: <20080225050001.D022F3A6B98@core3.amsl.com> <147101c877b5$b3c00170$011716ac@NEWTON603> <20080226104643.GB2112@elstar.local> <20080226123335.GB2536@elstar.local> Subject: RE: I-D Action:draft-ietf-radext-management-authorization-02.txt Date: Tue, 26 Feb 2008 08:35:39 -0500 Message-ID: <1a2d01c8787c$7b15c040$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach4dvMYMUqVzU8fRJGkFJV8cwucmQABVD0A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080226123335.GB2536@elstar.local> Sender: owner-radiusext@ops.ietf.org Precedence: bulk > I now realize that my comment is kind of stupid since the fact that > there is a RADIUS request kind of implies authentication happening. Ooops. Response collision. Sorry. BTW, no comment is stupid, and all are appreciated. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Feb 26 20:15:58 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8753A695D for ; Tue, 26 Feb 2008 20:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[AWL=-1.788, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfh59VmVM+Lz for ; Tue, 26 Feb 2008 20:15:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF5433A6933 for ; Tue, 26 Feb 2008 20:15:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUDdr-000DXe-A4 for radiusext-data@psg.com; Wed, 27 Feb 2008 04:11:39 +0000 Received: from [65.55.175.214] (helo=blu139-omc3-s14.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUDdn-000DWp-SV for radiusext@ops.ietf.org; Wed, 27 Feb 2008 04:11:37 +0000 Received: from BLU137-W17 ([65.55.162.188]) by blu139-omc3-s14.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Feb 2008 20:11:35 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_c6ec3162-00de-48c7-bb4d-dd92f8738a0f_" X-Originating-IP: [131.107.0.74] From: Bernard Aboba To: Subject: RADEXT WG Last Call on NAS Management Authorization Specification Date: Tue, 26 Feb 2008 20:11:35 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2008 04:11:35.0275 (UTC) FILETIME=[D77EABB0:01C878F6] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_c6ec3162-00de-48c7-bb4d-dd92f8738a0f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is to announce a RADEXT WG last call on the NAS Management Authorizati= on specification prior to its being sent on to the IESG for consideration a= s a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizat= ion-02.txt =20 RADEXT WG last call will last until Friday, March 28, 2008. Please respon= d to this WG last call announcement indicating whether or not you approve o= f the document, even if you have no comments to offer. If you have comment= s to offer, please send them to the RADEXT WG mailing list in the format de= scribed in the RADEXT WG Issues list: =20 http://www.drizzle.com/~aboba/RADEXT/= --_c6ec3162-00de-48c7-bb4d-dd92f8738a0f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is to announce a RADEXT WG last call on the NAS Management Authorizati= on specification prior to its being sent on to the IESG for consideration a= s a Proposed Standard.  The document is available for inspection here:=
http://www.ietf.org/internet-drafts/draft-ietf-radex= t-management-authorization-02.txt
 
RADEXT WG last call will last until Friday, March 28, 2008.   Ple= ase respond to this WG last call announcement indicating whether or not you= approve of the document, even if you have no comments to offer.  If y= ou have comments to offer, please send them to the RADEXT WG mailing list i= n the format described in the RADEXT WG Issues list: 
http://www.drizzle.com/~a= boba/RADEXT/
= --_c6ec3162-00de-48c7-bb4d-dd92f8738a0f_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Feb 28 08:15:29 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877D528C86D for ; Thu, 28 Feb 2008 08:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=-3.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGVLK6-nJV7T for ; Thu, 28 Feb 2008 08:15:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49CFE28C66C for ; Thu, 28 Feb 2008 08:15:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUlJH-000CvW-5T for radiusext-data@psg.com; Thu, 28 Feb 2008 16:08:39 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JUlJB-000CuZ-Ci for radiusext@ops.ietf.org; Thu, 28 Feb 2008 16:08:38 +0000 Received: (qmail 24406 invoked from network); 28 Feb 2008 11:08:31 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 28 Feb 2008 11:08:31 -0500 From: "David B. Nelson" To: References: Subject: RADEXT Meeting Slot (was RE: Call for Agenda items for IETF 71 RADEXT WG meeting) Date: Thu, 28 Feb 2008 11:07:35 -0500 Organization: Elbrys Networks, Inc. Message-ID: <001201c87a24$082da6c0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AchzYE8HsZ3JgCUwRx6xgkVKp/Rk9wGwxw0g Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba writes... > At IETF 71, the RADEXT WG is currently scheduled to meet on > Friday, March 14 from 9 AM - 11:30 AM. Just a "heads-up" to the WG members that the IETF-71 Meeting Agenda is apparently not final, and that there is a conflict for the O&M Area Directors in the Friday morning slot. There was some discussion of moving RADEXT to a Monday afternoon slot, if the schedule can be so juggled. Stay tuned... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Feb 29 08:39:18 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB163A6926 for ; Fri, 29 Feb 2008 08:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd80xTnDullz for ; Fri, 29 Feb 2008 08:39:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2B7528C1BB for ; Fri, 29 Feb 2008 08:39:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV89A-000CA0-Ep for radiusext-data@psg.com; Fri, 29 Feb 2008 16:31:44 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JV895-000C8j-N8 for radiusext@ops.ietf.org; Fri, 29 Feb 2008 16:31:42 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D920876F79; Fri, 29 Feb 2008 10:26:02 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id C740476F4F; Fri, 29 Feb 2008 10:26:02 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: "Joseph Salowey (jsalowey)" Subject: Re: request to recharter Date: Fri, 29 Feb 2008 10:26:02 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org References: In-Reply-To: X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart1442808.16tUsvbSVo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > I'm not in favor of taking RADSEC on as a working group item without a > better understanding of the goals. There is more to RADSEC then just > TCP transport and algorithmic agility. I think it would be appropriate > to have a BOF to understand that scope of what RADSEC is trying to > achieve. I have just sent a note to ietf, ops-area and int-area that I'd like to=20 solicit opinions on the topic of roaming in general during the upcoming=20 meeting. RadSec is one topic of course, but it's about more. This is not a BoF, since a BoF is a well-defined process, but I hope it wil= l=20 generate some insight aynway. As for the scope of RadSec: its primary purpose is really just that: make=20 RADIUS more robust and secure. This happens to make it also more flexible,= =20 i.e. no shared secrets and IP bindings, right, so it might achieve more tha= n=20 that. Still, it is a topic very closely related to RADIUS (Glen might disagree, I= =20 know) and so I for one am very confident that radext is the place to go for= =20 this draft. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart1442808.16tUsvbSVo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHx8+q+jm90f8eFWYRAlVVAJ4tAxZlh6CmmLhvevOaJLHWjX7gfwCfaY69 BihSQ1a+yGGiUa433UCUclY= =QqrG -----END PGP SIGNATURE----- --nextPart1442808.16tUsvbSVo-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 28 Feb 2008 16:09:35 +0000 From: "David B. Nelson" To: Subject: RADEXT Meeting Slot (was RE: Call for Agenda items for IETF 71 RADEXT WG meeting) Date: Thu, 28 Feb 2008 11:07:35 -0500 Organization: Elbrys Networks, Inc. Message-ID: <001201c87a24$082da6c0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AchzYE8HsZ3JgCUwRx6xgkVKp/Rk9wGwxw0g Bernard Aboba writes... > At IETF 71, the RADEXT WG is currently scheduled to meet on > Friday, March 14 from 9 AM - 11:30 AM. Just a "heads-up" to the WG members that the IETF-71 Meeting Agenda is apparently not final, and that there is a conflict for the O&M Area Directors in the Friday morning slot. There was some discussion of moving RADEXT to a Monday afternoon slot, if the schedule can be so juggled. Stay tuned... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 27 Feb 2008 04:12:20 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_c6ec3162-00de-48c7-bb4d-dd92f8738a0f_" From: Bernard Aboba To: Subject: RADEXT WG Last Call on NAS Management Authorization Specification Date: Tue, 26 Feb 2008 20:11:35 -0800 MIME-Version: 1.0 --_c6ec3162-00de-48c7-bb4d-dd92f8738a0f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is to announce a RADEXT WG last call on the NAS Management Authorizati= on specification prior to its being sent on to the IESG for consideration a= s a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizat= ion-02.txt =20 RADEXT WG last call will last until Friday, March 28, 2008. Please respon= d to this WG last call announcement indicating whether or not you approve o= f the document, even if you have no comments to offer. If you have comment= s to offer, please send them to the RADEXT WG mailing list in the format de= scribed in the RADEXT WG Issues list: =20 http://www.drizzle.com/~aboba/RADEXT/= --_c6ec3162-00de-48c7-bb4d-dd92f8738a0f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is to announce a RADEXT WG last call on the NAS Management Authorizati= on specification prior to its being sent on to the IESG for consideration a= s a Proposed Standard.  The document is available for inspection here:=
http://www.ietf.org/internet-drafts/draft-ietf-radex= t-management-authorization-02.txt
 
RADEXT WG last call will last until Friday, March 28, 2008.   Ple= ase respond to this WG last call announcement indicating whether or not you= approve of the document, even if you have no comments to offer.  If y= ou have comments to offer, please send them to the RADEXT WG mailing list i= n the format described in the RADEXT WG Issues list: 
http://www.drizzle.com/~a= boba/RADEXT/
= --_c6ec3162-00de-48c7-bb4d-dd92f8738a0f_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 26 Feb 2008 13:35:57 +0000 From: "David B. Nelson" To: Cc: Subject: RE: I-D Action:draft-ietf-radext-management-authorization-02.txt Date: Tue, 26 Feb 2008 08:35:39 -0500 Message-ID: <1a2d01c8787c$7b15c040$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: Ach4dvMYMUqVzU8fRJGkFJV8cwucmQABVD0A > I now realize that my comment is kind of stupid since the fact that > there is a RADIUS request kind of implies authentication happening. Ooops. Response collision. Sorry. BTW, no comment is stupid, and all are appreciated. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 26 Feb 2008 13:19:18 +0000 From: "David B. Nelson" To: Subject: RE: I-D Action:draft-ietf-radext-management-authorization-02.txt Date: Tue, 26 Feb 2008 08:18:59 -0500 Message-ID: <1a2401c8787a$26c72df0$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: Ach4ZW8JIzANLltKT/aHWN4zvAhHbQAEUp6A Juergen Schoenwaelder writes... > > The resolution to this particular set of comments was to change > > the attribute to Management-Transport-Protection, and only > > provision that which is important -- the level of protection > > required for the remote management session. The four possible > > values of this attribute are: > > > > o No-Protection: No transport protection is required. Accept > > connections via any supported transport. > > > > o Integrity-Protection: The management session requires protection > > in a secure or protected transport, that is supported by the > > management access protocol and implementation. The secure > > transport MUST provide Integrity Protection. > > > > o Confidentiality-Protection: The management session requires > > protection in a secure or protected transport, that is supported > > by the management access protocol and implementation. The secure > > transport MUST provide Confidentiality Protection. > > > > o Integrity-Confidentiality-Protection: The management session > > requires protection in a secure or protected transport, that is > > supported by the management access protocol and implementation. > > The secure transport MUST provide both Integrity Protection and > > Confidentiality Protection. > > I like the general approach. > > I am wondering however how authentication fits into the above list or > whether you assume integrity-protection and confidentiality-protection > imply authentication of the two parties involved. RADIUS is all about authentication. That basic function of RADIUS has not changed. The RADIUS server authenticates the user (via one of the supported authentication methods) before choosing to send an Access-Accept message. If the RADIUS server chooses not to authenticate an actual user (e.g. Call-Check) it would likely not authorize provision of a service that required a protected transport. (Although there may be valid uses case for doing so...) It is reasonable to assume that in any use case where authentication of the user (e.g. the SNMP principal attempting to connect to the NAS) is important, that receipt of an Access-Accept message at the NAS indicates that the user has been authenticated by the RADIUS server. What is not specified in this mechanism is a cryptographic binding between the authenticated RADIUS user identity and the keys, certificates, or other credentials used to establish the protected transport session. The NAS may be in a position to perform this "binding" by relating the authenticated RADIUS user identity to some local transport session handle. The details of this would be a matter of implementation, I would think. If the NAS is capable of determining, via its API to the transport security layer, that a protected transport is in use and what its properties are, the NAS is in a position or enforce the provisions of the Management-Transport-Protection attribute. If the NAS is not capable of making that kind of determination (e.g. because of limitations in the APIs, etc.), then the whole issue of requiring a protected transport is very questionable, whether you call it out by name (e.g. SSH or TLS) or you call it out by property (e.g. Integrity-Protection or Confidentiality-Protection). Does that line of thinking make sense to you? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 26 Feb 2008 12:57:30 +0000 Date: Tue, 26 Feb 2008 13:33:35 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-management-authorization-02.txt Message-ID: <20080226123335.GB2536@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) On Tue, Feb 26, 2008 at 11:46:43AM +0100, Juergen Schoenwaelder wrote: > On Mon, Feb 25, 2008 at 08:52:45AM -0500, David B. Nelson wrote: > > > The resolution to this particular set of comments was to change the > > attribute to Management-Transport-Protection, and only provision that which > > is important -- the level of protection required for the remote management > > session. The four possible values of this attribute are: > > > > o No-Protection: No transport protection is required. Accept > > connections via any supported transport. > > > > o Integrity-Protection: The management session requires protection > > in a secure or protected transport, that is supported by the > > management access protocol and implementation. The secure > > transport MUST provide Integrity Protection. > > > > o Confidentiality-Protection: The management session requires > > protection in a secure or protected transport, that is supported > > by the management access protocol and implementation. The secure > > transport MUST provide Confidentiality Protection. > > > > o Integrity-Confidentiality-Protection: The management session > > requires protection in a secure or protected transport, that is > > supported by the management access protocol and implementation. > > The secure transport MUST provide both Integrity Protection and > > Confidentiality Protection. > > I like the general approach. > > I am wondering however how authentication fits into the above list or > whether you assume integrity-protection and confidentiality-protection > imply authentication of the two parties involved. I now realize that my comment is kind of stupid since the fact that there is a RADIUS request kind of implies authentication happening. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 26 Feb 2008 10:51:45 +0000 Date: Tue, 26 Feb 2008 11:46:43 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-management-authorization-02.txt Message-ID: <20080226104643.GB2112@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) On Mon, Feb 25, 2008 at 08:52:45AM -0500, David B. Nelson wrote: > The resolution to this particular set of comments was to change the > attribute to Management-Transport-Protection, and only provision that which > is important -- the level of protection required for the remote management > session. The four possible values of this attribute are: > > o No-Protection: No transport protection is required. Accept > connections via any supported transport. > > o Integrity-Protection: The management session requires protection > in a secure or protected transport, that is supported by the > management access protocol and implementation. The secure > transport MUST provide Integrity Protection. > > o Confidentiality-Protection: The management session requires > protection in a secure or protected transport, that is supported > by the management access protocol and implementation. The secure > transport MUST provide Confidentiality Protection. > > o Integrity-Confidentiality-Protection: The management session > requires protection in a secure or protected transport, that is > supported by the management access protocol and implementation. > The secure transport MUST provide both Integrity Protection and > Confidentiality Protection. I like the general approach. I am wondering however how authentication fits into the above list or whether you assume integrity-protection and confidentiality-protection imply authentication of the two parties involved. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 25 Feb 2008 13:53:23 +0000 From: "David B. Nelson" To: Subject: RE: I-D Action:draft-ietf-radext-management-authorization-02.txt Date: Mon, 25 Feb 2008 08:52:45 -0500 Message-ID: <147101c877b5$b3c00170$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: Ach3a9803fi9WF6ARqSHoDl08+mcrAAR8w9A > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the RADIUS EXTensions Working Group of the > IETF. > > Title : Remote Authentication Dial-In User Service > (RADIUS) Authorization for Network Access Server (NAS) Management > Author(s) : D. Nelson, G. Weber > Filename : draft-ietf-radext-management-authorization-02.txt > Pages : 20 > Date : 2008-02-24 > > This document describes Remote Authentication Dial-In User Service > (RADIUS) attributes for the authorization and service provisioning of > local and remote management of embedded systems and other managed > entities, generally referred to as Network Access Servers (NASes). > Specific provisions are made for remote management via framed > management protocols, for granular levels of access rights and > management privileges, and for specification of a protected transport > protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-management- > authorization-02.txt I'm forwarding a list of the open issues that I culled from the RADEXT mailing list, in preparing the -02 version of this draft. All of the open issues listed below have been addressed in one fashion or another. I would like to call attention to one change in particular. One particularly thorny issue with the -01 draft is the relationship (or lack thereof) between the application layer management protocols, as provisioned in the Framed-Management-Protocol attribute, and the protected transport protocols, as provisioned in the Management-Transport-Protocol attribute. Part of the confusion is whether the latter attribute should include "traditional" Layer 4 network transports (e.g. TCP, UDP, SCTP, etc.) or only "protected transports" (TLS, DTLS, SSH, etc.) The other part of the confusion is which transports can be use with which management applications. I think the -01 version suffers from "creeping complexity", caused partly by various review comments along the way, and partly by muddled thinking on my part. Having been away from this document for some months, it occurred to me that the problem was that the Management-Transport-Protocol attribute was simply over-specifying the problem. I don't think that anyone really needs to micro-manage the choice of protected transport protocol, any more than we need to micromanage the selection of remote terminal protocol in providing the NAS-Prompt service. The resolution to this particular set of comments was to change the attribute to Management-Transport-Protection, and only provision that which is important -- the level of protection required for the remote management session. The four possible values of this attribute are: o No-Protection: No transport protection is required. Accept connections via any supported transport. o Integrity-Protection: The management session requires protection in a secure or protected transport, that is supported by the management access protocol and implementation. The secure transport MUST provide Integrity Protection. o Confidentiality-Protection: The management session requires protection in a secure or protected transport, that is supported by the management access protocol and implementation. The secure transport MUST provide Confidentiality Protection. o Integrity-Confidentiality-Protection: The management session requires protection in a secure or protected transport, that is supported by the management access protocol and implementation. The secure transport MUST provide both Integrity Protection and Confidentiality Protection. The complete list of issues addressed in the -02 revision is as follows: -- Further explain the distinction between web-based management (HTML over HTTP) vs. other methods, such as NETCONF (XML over HTTP). Done. -- Provide informational text listing the "default" transport for each of the management protocols specified by Framed-Management-Protocol (e.g. for SNMP it's unprotected UDP). The "default" transport is no longer at issue. The Management-Transport-Protocols attribute has been re-cast as the Management-Transport-Protection attribute. -- Further explain what protocols (e.g. telnet, rlogin) are involved in providing the NAS-Prompt Service-Type with each value of Management-Transport-Protocol. No longer applicable. -- Explain the current remote console usage model of NAS-Port-Type of Virtual with Service-Type of NAS-Prompt. Done. -- Should Management-Privilege-Level apply to Framed-Management-Protocol? E.g. for access control of SNMP or NETCONF? No. Done. -- Would the locally stored policies referenced by Management-Policy-Id ever be too complicated to be stored on the NAS, requiring multiple policy and access control attributes from the RADIUS server to express that complexity? No. Done. -- Clarify the "local scope" of policy definitions on the NAS referenced by Management-Policy-Id? Done. -- The proposed RADIUS attributes do not carry what really counts - the security level, e.g. I might accept SNMP access as long as the actual security level is providing authPriv, regardless how this is achieved. Done? I think the Management-Transport-Protection attribute addresses this issue. -- The two new attributes Framed-Management-Protocol and Transport-Protocol are enumerations that may need to be extended (e.g. NETCONF is missing in the first one already). I suggest that the IANA section spells out the rules for extending these enumerations, e.g. by requiring a specification. Done. -- Are HTTP and HTTPS really two different framed management protocols? Or is HTTPS just HTTP with a transport of TLS? Done. -- I do not think SSH really carries telnet in the sense of the telnet protocol. Done. -- Would it be possible to indicate CLI access via telnet over tls? No longer applicable. -- I think that the way you would specify the secure remote terminal service of SSH would be using Service-Type=NAS-Prompt, Management-Transport-Protocol=SSH. No longer applicable. -- With respect to TLS/DTLS, what mode is intended? Mutual auth with certs? Server-only auth? TLS-PSK? No longer applicable. -- I thought you need to specify what "default" means for each Framed-Management entry. No longer applicable. -- The NAS-Prompt Service-Type works for all of: local console connections, telnet, rlogin, ssh, (and more) remote connections. Done. -- The only thing we are trying to specify here is whether the remote terminal service is being carried over a secure transport. Do we really care what the transport layer protocol is? I think that what we care about is whether it over a secure or non-secure transport. Done. As always, further comments are welcome. Hopefully you will find that this draft version has addressed your open issues in a satisfactory manner. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 25 Feb 2008 05:00:59 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-management-authorization-02.txt Message-Id: <20080225050001.D022F3A6B98@core3.amsl.com> Date: Sun, 24 Feb 2008 21:00:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-02.txt Pages : 20 Date : 2008-02-24 This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities, generally referred to as Network Access Servers (NASes). Specific provisions are made for remote management via framed management protocols, for granular levels of access rights and management privileges, and for specification of a protected transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-management-authorization-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-management-authorization-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-24205509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-management-authorization-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24205509.I-D\@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 21 Feb 2008 16:48:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: request to recharter Date: Thu, 21 Feb 2008 08:48:07 -0800 Message-ID: Thread-Topic: request to recharter Thread-Index: AchvYNsBQjET5/gUS0ixPIZXy35shQFSAgew From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , "Alan DeKok" Cc: "Stefan Winter" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1976; t=1203612445; x=1204476445; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20request=20to=20recharter |Sender:=20; bh=puXjXLPPquSzXUSDOfbbkqihJniKq7+9YGmSFyOISzo=; b=qM23lONBHQB/wHqJ5i9iPlCnQTd0GDa1/DgWwu4PVf3Yh61L31aNoQ1mmp 90DoA+xxw6fh3UIo3Rv9JSkxh+spu780Te6ExIwh6zZW2m+nao1bDfrMXgNo G7XLrPCIvSO3G2oiUATCsUY+Zoh7BaWFkACia1WQIq8r5Z5+lBuho=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); I'm not in favor of taking RADSEC on as a working group item without a better understanding of the goals. There is more to RADSEC then just TCP transport and algorithmic agility. I think it would be appropriate to have a BOF to understand that scope of what RADSEC is trying to achieve.=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, February 14, 2008 3:25 PM > To: Alan DeKok > Cc: Stefan Winter; radiusext@ops.ietf.org > Subject: Re: request to recharter >=20 > > The "RADIUS over TCP" document could reference existing RADIUS=20 > > practices, and explain in excruciating detail why they=20 > won't work for TCP. > > > > Also, some issues relating to RADIUS PDU's over a stream transport=20 > > may be discussed. e.g. receiving half a RADIUS packet and=20 > then a FIN=20 > > is > > *not* a problem. > > > > The MIB counters for > > radiusAuthServMalformedAccessRequests should NOT be=20 > incremented. e.g. > > receiving a PDU with malformed attributes means that the TCP=20 > > connection SHOULD be closed. > > > > Many RADIUS practices related to handling error cases=20 > require a PDU=20 > > to be "silently discarded". This won't work for TCP. The=20 > connection=20 > > has to be closed, too. > > > > The existing RFC's have to be audited, and a new document=20 > issued which=20 > > explains the correct behavior. >=20 > This sounds like an outline of the issues that need to be=20 > handled in the RADSEC specification. > Regardless of whether the RADEXT WG ends up adding the RADSEC=20 > work to the Charter, it would be useful to include this=20 > material in the document.=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 21 Feb 2008 15:46:21 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-extended-attributes-01.txt Message-Id: <20080221154501.B9EDE28CA3C@core3.amsl.com> Date: Thu, 21 Feb 2008 07:45:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Extended Remote Authentication Dial In User Service (RADIUS) Attributes Author(s) : Y. Li, et al. Filename : draft-ietf-radext-extended-attributes-01.txt Pages : 13 Date : 2008-02-21 In order for the Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications the RADIUS attribute type space must be extended beyond the current limit of 255 possible attribute types while maintaining backwards compatibility with the existing protocol. This document defines a mechanism to accomplish that task, along with standard methods to group together related attributes and to encode values that don't fit into 253 octets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-extended-attributes-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-extended-attributes-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-21074336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-extended-attributes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-extended-attributes-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-21074336.I-D\@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 20 Feb 2008 01:24:55 +0000 Message-ID: From: "Bernard Aboba" To: Subject: Call for Agenda items for IETF 71 RADEXT WG meeting Date: Tue, 19 Feb 2008 17:14:41 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C8731A.EA11FB10" This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C8731A.EA11FB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 71, the RADEXT WG is currently scheduled to meet on Friday, = March 14 from 9 AM - 11:30 AM.=20 If you would like time on the RADEXT WG agenda at IETF 71, please send a = note to the chairs. ------=_NextPart_000_0090_01C8731A.EA11FB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 71, the RADEXT WG is currently = scheduled to=20 meet on Friday, March 14 from 9 AM - 11:30 AM.
If you would like time on the RADEXT WG = agenda at=20 IETF 71, please send a note to the chairs.
------=_NextPart_000_0090_01C8731A.EA11FB10-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 19 Feb 2008 12:52:21 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=anSQocG5Fq8ZeIUqs6jmTJyyfpHSyP+xjNst6FXFGHXHnHAQ+thmq9Ttb6Z6nejnXqPhuGsSR33h4aBYHo4TURmF62ZwPULm/zgn8mGBTZOyvPquOdjUY6mnf6boeVLWTy3Y7LE+QScSlVSjbI1cu6Msw985ohs35QR95HD/iNQ=; Date: Tue, 19 Feb 2008 04:52:07 -0800 (PST) From: vamsi krishna Subject: new draft proposal on Radius support for roaming and handovers To: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <13150.3575.qm@web30903.mail.mud.yahoo.com> Dear all, I am proposing another new draft for this WG on new extensions for radius supporting roaming and handover. you can check it at this link. Roaming Extensions for radius server http://tools.ietf.org/wg/radext/draft-gondi-radext-radius-roaming-01.txt In this draft we have proposed different extensions for extending the functionalities of radius server for not only to authenticatio, authorization and accounting but also for wireless mobiity. In this draft we have proposed 4 new mechanisms which can be extended later, on network selection, handover management, security context transfer management and mobility context management. In ths draf we have proposed new attributes to support RADIUS for extending functionalities for supporting seamless roaming services. I am very interested to address the issues rasied by the WG, and also suggestions and remarks to enhance the proposed solutions for possible radius extensions. thanking you, gondi. Vamsi Krishna GONDI, 16 rue Jean Pierre Laurens, Fontenay Aux Roses, 92260, France. Ph no. +33 (0)6 20 38 51 53 ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 19 Feb 2008 12:45:50 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=5OoFWJ0vM5b2OftJuqtDc9iu7G1hAsiK2ilTUf/r6rswSgQagIgDHSx/aZtSQErTbhynCPszuJgM/7PsKe6Kn+V6lRl8TY9Le7SOairDvSMYCINtH68m33pVgW14jLo9aWNcQ75liyf5yJLbZXqO22b287t4rajFc4JLGKpwc+w=; Date: Tue, 19 Feb 2008 04:44:50 -0800 (PST) From: vamsi krishna Subject: new draft proposal To: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <825804.56409.qm@web30901.mail.mud.yahoo.com> Dear All, I am proposing a new draft in the radext WG on Radius Mobility Extensions. you can fnd it at this link http://tools.ietf.org/wg/radext/draft-gondi-radext-radius-mobility-00.txt The main aim of the draft is to extebd the functionalities of RADIUS server for mobility management. In this context we have proposed new modules and attributes where a Radius server can communicate with the different network entities and another radius servers for mobility context transfer. We have demobnstrated its capabilities using PMIPv4. i am keen to discuss the issues raised by the WG in the mailing list to enhance our proposed solution. thankng you, gondi. Vamsi Krishna GONDI, 16 rue Jean Pierre Laurens, Fontenay Aux Roses, 92260, France. Ph no. +33 (0)6 20 38 51 53 ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 15 Feb 2008 17:13:40 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Murtaza Chiba \(mchiba\)'" , Subject: RE: inconsistency in RFC 5176 Date: Sat, 16 Feb 2008 00:12:19 +0700 Message-ID: <003201c86ff5$ff777a70$8bd3797c@arubanetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C87030.ABD65270" thread-index: Achv5agwON227gTLTXeU72ZWj6fc/QAECBiw This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C87030.ABD65270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Error 201 is defined. However, RFC 5716 only defines to how modify authorizations or delete current sessions. Presumably if a session were not active, then current implementations would return a Disconnect-NAK or CoA-NAK, rather than a Disconnect-ACK with Error-Code value 201. OK, but shouldn't the Error-Cause attribute still be allowed in the table? > From: glenzorn@comcast.net > To: Bernard_Aboba@hotmail.com; mchiba@cisco.com; radiusext@ops.ietf.org > Subject: RE: inconsistency in RFC 5176 > Date: Fri, 15 Feb 2008 12:19:27 +0700 > > Bernard Aboba <> scribbled on Friday, February 15, 2008 6:07 AM: > > > There is no contradiction here. Section 3.5 says: > > > > "Values 200-299 represent successful completion, so that these > > values may only be sent within CoA-ACK or Disconnect-ACK packets and > > MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet." > > > > There are only two values in the range 200-299 which are defined: > > > > 201 Residual Session Context Removed > > 202 Invalid EAP Packet (Ignored) > > > > Error 202 is explicitly prohibited for use by RFC 5176 > > implementations: > > > > "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST > > NOT be sent by implementations of this specification. > > > > Error 201 is also not currently defined for use with RFC 5176 since > > it refers to removal of key context, not modification or > > disconnection of sessions. > > > > Therefore, Section 3.5 and 3.6 are in agreement. > > Thanks, Bernard, I was just about to respond in that very fashion, > except that the table headed "Disconnect Messages" in section 3.6 > completely disallows the use of the Error-Cause Attribute in > Disconnect-ACK messages, while section 3.5 says; > > "Residual Session Context Removed" is sent in response to a > Disconnect-Request if one or more user sessions are no longer > active, but residual session context was found and successfully > removed. This value is only sent within a Disconnect-ACK and MUST > NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK. > > It seems that the table is in error to me. BTW, I can't find anything > in the document that says that Error 201 is currently undefined; what am > I missing? > > ... > ------=_NextPart_000_0033_01C87030.ABD65270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Error 201 is = defined.  However,=20 RFC 5716 only defines to  how modify authorizations
or delete = current=20 sessions.  Presumably if a session were not active, then=20 current
implementations would return a Disconnect-NAK or CoA-NAK, = rather than=20 a
Disconnect-ACK with Error-Code value 201.  
 
OK, but=20 shouldn't the Error-Cause attribute still be allowed in the=20 table? 

> From: = glenzorn@comcast.net
> To:=20 Bernard_Aboba@hotmail.com; mchiba@cisco.com; = radiusext@ops.ietf.org
>=20 Subject: RE: inconsistency in RFC 5176
> Date: Fri, 15 Feb 2008 = 12:19:27=20 +0700
>
> Bernard Aboba <> scribbled on Friday, = February 15,=20 2008 6:07 AM:
>
> > There is no contradiction here. = Section 3.5=20 says:
> >
> > "Values 200-299 represent successful=20 completion, so that these
> > values may only be sent within = CoA-ACK=20 or Disconnect-ACK packets and
> > MUST NOT be sent within a = CoA-NAK or=20 Disconnect-NAK packet."
> >
> > There are only two = values in=20 the range 200-299 which are defined:
> >
> > 201 = Residual=20 Session Context Removed
> > 202 Invalid EAP Packet = (Ignored)
>=20 >
> > Error 202 is explicitly prohibited for use by RFC=20 5176
> > implementations:
> >
> > "Invalid = EAP=20 Packet (Ignored)" is a non-fatal error that MUST
> > NOT be = sent by=20 implementations of this specification.
> >
> > Error = 201 is=20 also not currently defined for use with RFC 5176 since
> > it = refers to=20 removal of key context, not modification or
> > disconnection = of=20 sessions.
> >
> > Therefore, Section 3.5 and 3.6 are = in=20 agreement.
>
> Thanks, Bernard, I was just about to respond = in that=20 very fashion,
> except that the table headed "Disconnect Messages" = in=20 section 3.6
> completely disallows the use of the Error-Cause = Attribute=20 in
> Disconnect-ACK messages, while section 3.5 says;
> =
>=20 "Residual Session Context Removed" is sent in response to a
>=20 Disconnect-Request if one or more user sessions are no longer
> = active,=20 but residual session context was found and successfully
> removed. = This=20 value is only sent within a Disconnect-ACK and MUST
> NOT be sent = within a=20 CoA-ACK, Disconnect-NAK, or CoA-NAK.
>
> It seems that the = table is=20 in error to me. BTW, I can't find anything
> in the document that = says=20 that Error 201 is currently undefined; what am
> I = missing?
>=20
> ...
>
------=_NextPart_000_0033_01C87030.ABD65270-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 15 Feb 2008 15:12:19 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_220d8099-f519-465d-bfe2-85ef69b920f9_" From: Bernard Aboba To: Glen Zorn , "'Murtaza Chiba (mchiba)'" , Subject: RE: inconsistency in RFC 5176 Date: Fri, 15 Feb 2008 07:11:58 -0800 MIME-Version: 1.0 --_220d8099-f519-465d-bfe2-85ef69b920f9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Error 201 is defined. However, RFC 5716 only defines to how modify author= izations or delete current sessions. Presumably if a session were not active, then = current implementations would return a Disconnect-NAK or CoA-NAK, rather than a Disconnect-ACK with Error-Code value 201.=20 > From: glenzorn@comcast.net > To: Bernard_Aboba@hotmail.com; mchiba@cisco.com; radiusext@ops.ietf.org > Subject: RE: inconsistency in RFC 5176 > Date: Fri, 15 Feb 2008 12:19:27 +0700 >=20 > Bernard Aboba <> scribbled on Friday, February 15, 2008 6:07 AM: >=20 > > There is no contradiction here. Section 3.5 says: > >=20 > > "Values 200-299 represent successful completion, so that these=20 > > values may only be sent within CoA-ACK or Disconnect-ACK packets and > > MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet." =20 > >=20 > > There are only two values in the range 200-299 which are defined: > >=20 > > 201 Residual Session Context Removed > > 202 Invalid EAP Packet (Ignored) > >=20 > > Error 202 is explicitly prohibited for use by RFC 5176 > > implementations:=20 > >=20 > > "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST > > NOT be sent by implementations of this specification. > >=20 > > Error 201 is also not currently defined for use with RFC 5176 since > > it refers to removal of key context, not modification or > > disconnection of sessions. =20 > >=20 > > Therefore, Section 3.5 and 3.6 are in agreement. >=20 > Thanks, Bernard, I was just about to respond in that very fashion, > except that the table headed "Disconnect Messages" in section 3.6 > completely disallows the use of the Error-Cause Attribute in > Disconnect-ACK messages, while section 3.5 says;=20 >=20 > "Residual Session Context Removed" is sent in response to a > Disconnect-Request if one or more user sessions are no longer > active, but residual session context was found and successfully > removed. This value is only sent within a Disconnect-ACK and MUST > NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK. >=20 > It seems that the table is in error to me. BTW, I can't find anything > in the document that says that Error 201 is currently undefined; what am > I missing? >=20 > ... >=20 --_220d8099-f519-465d-bfe2-85ef69b920f9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Error 201 is defined.  However, RFC 5716 only defines to  how mod= ify authorizations
or delete current sessions.  Presumably if a ses= sion were not active, then current
implementations would return a Discon= nect-NAK or CoA-NAK, rather than a
Disconnect-ACK with Error-Code value = 201.

> From: glenzorn@comcast.net
> To: Bernard_Aboba@hotm= ail.com; mchiba@cisco.com; radiusext@ops.ietf.org
> Subject: RE: inco= nsistency in RFC 5176
> Date: Fri, 15 Feb 2008 12:19:27 +0700
>=
> Bernard Aboba <> scribbled on Friday, February 15, 2008 6:0= 7 AM:
>
> > There is no contradiction here. Section 3.5 = says:
> >
> > "Values 200-299 represent successful compl= etion, so that these
> > values may only be sent within CoA-ACK o= r Disconnect-ACK packets and
> > MUST NOT be sent within a CoA-NA= K or Disconnect-NAK packet."
> >
> > There are only tw= o values in the range 200-299 which are defined:
> >
> >= 201 Residual Session Context Removed
> > 202 In= valid EAP Packet (Ignored)
> >
> > Error 202 is explicit= ly prohibited for use by RFC 5176
> > implementations:
> &g= t;
> > "Invalid EAP Packet (Ignored)" is a non-fatal error = that MUST
> > NOT be sent by implementations of this specifi= cation.
> >
> > Error 201 is also not currently defined = for use with RFC 5176 since
> > it refers to removal of key contex= t, not modification or
> > disconnection of sessions.
> &g= t;
> > Therefore, Section 3.5 and 3.6 are in agreement.
> =
> Thanks, Bernard, I was just about to respond in that very fashion,=
> except that the table headed "Disconnect Messages" in section 3.6<= br>> completely disallows the use of the Error-Cause Attribute in
>= ; Disconnect-ACK messages, while section 3.5 says;
>
> = "Residual Session Context Removed" is sent in response to a
> D= isconnect-Request if one or more user sessions are no longer
> = active, but residual session context was found and successfully
> = removed. This value is only sent within a Disconnect-ACK and MUST
&g= t; NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK.
> =
> It seems that the table is in error to me. BTW, I can't find anyt= hing
> in the document that says that Error 201 is currently undefine= d; what am
> I missing?
>
> ...
>
= --_220d8099-f519-465d-bfe2-85ef69b920f9_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 15 Feb 2008 14:42:35 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: request to recharter Date: Fri, 15 Feb 2008 15:41:40 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: "'Klaas Wierenga'" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2274283.rqoavQJ91C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802151541.44312.stefan.winter@restena.lu> --nextPart2274283.rqoavQJ91C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > I'm extremely pleased to hear that! For example, I'm inclined to think > that TLSoSCTP might be a choice far less destructive of RADIUS semantics > that TLSoTCP... SCTP was also considered, and in fact the Radiator implementation also offe= rs=20 SCTP as an option. The choice for TCP was a rather pragmatic one. SCTP is available on less=20 platforms and the implementations appeared to be a bit more flaky - e.g. th= e=20 SCTP implementation in Linux has had several DoS advisories, and I for one= =20 wouldn't want to rely on it yet. Regarding platforms: that LANCOM Access Point implementation wouldn't exist= if=20 SCTP would have been the transport - to my best knowledge, that feature is= =20 not even anywhere near their radar. So, the choice was to concentrate on something that works today and almost= =20 everywhere. If I take a look at how Diameter approached this: clients TCP and optional= =20 SCTP, servers both required: if we were to follow that, we'd still have to= =20 deal with all the complexities of TCP and add on top of that SCTP. And I'm= =20 not sure that trying SCTP first and falling back to TCP if that doesn't wor= k=20 really fits to the KISS mantra of the IETF. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart2274283.rqoavQJ91C Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHtaSo+jm90f8eFWYRAg8TAJ0VTSV/OM2SkjV4RlQaJE63BNTq/ACfc/Sb p4ckW4U+/pDd75hEYgcCdpc= =GfTz -----END PGP SIGNATURE----- --nextPart2274283.rqoavQJ91C-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 15 Feb 2008 09:19:54 +0000 From: "Glen Zorn" To: "'Klaas Wierenga'" Cc: "'Stefan Winter'" , Subject: RE: request to recharter Date: Fri, 15 Feb 2008 16:18:46 +0700 Message-ID: <006801c86fb3$d488bfa0$addf787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Achu5AxrjeWCuOGvTSO1ht0i2Rs4agAzt+LQ Klaas Wierenga scribbled on Thursday, February 14, 2008 3:32 PM: ... > > Nobody expects the IETF to just rubberstamp this work, on the > contrary, this is an effort to sollicit comments and make this better > than it would be if it was just thought up by a few individuals. I'm extremely pleased to hear that! For example, I'm inclined to think that TLSoSCTP might be a choice far less destructive of RADIUS semantics that TLSoTCP... > We > have built an infrastructure on what was available and ran into > operational problems with it, I believe it is perfectly legitimate > to try to address these problems. No doubt. The only question is where & how. I strongly believe that the radext WG is not the right place,\. The IETF standardization process may be the "how"; the normal way this is discovered is through the BOF process. > > Klaas Wierenga > (creator of eduroam) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 15 Feb 2008 05:20:33 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Murtaza Chiba \(mchiba\)'" , Subject: RE: inconsistency in RFC 5176 Date: Fri, 15 Feb 2008 12:19:27 +0700 Message-ID: <005801c86f92$61cbbe70$addf787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchvXtAoq56LQbSASh+JB7x4lrv7HgAMSPUw Bernard Aboba <> scribbled on Friday, February 15, 2008 6:07 AM: > There is no contradiction here. Section 3.5 says: > > "Values 200-299 represent successful completion, so that these > values may only be sent within CoA-ACK or Disconnect-ACK packets and > MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet." > > There are only two values in the range 200-299 which are defined: > > 201 Residual Session Context Removed > 202 Invalid EAP Packet (Ignored) > > Error 202 is explicitly prohibited for use by RFC 5176 > implementations: > > "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST > NOT be sent by implementations of this specification. > > Error 201 is also not currently defined for use with RFC 5176 since > it refers to removal of key context, not modification or > disconnection of sessions. > > Therefore, Section 3.5 and 3.6 are in agreement. Thanks, Bernard, I was just about to respond in that very fashion, except that the table headed "Disconnect Messages" in section 3.6 completely disallows the use of the Error-Cause Attribute in Disconnect-ACK messages, while section 3.5 says; "Residual Session Context Removed" is sent in response to a Disconnect-Request if one or more user sessions are no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK. It seems that the table is in error to me. BTW, I can't find anything in the document that says that Error 201 is currently undefined; what am I missing? ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 15 Feb 2008 02:11:22 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5090 on RADIUS Extension for Digest Authentication From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org Message-Id: <20080215021032.D17DE113E4C@bosco.isi.edu> Date: Thu, 14 Feb 2008 18:10:32 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5090 Title: RADIUS Extension for Digest Authentication Author: B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck Status: Standards Track Date: February 2008 Mailbox: baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, beckw@t-systems.com Pages: 33 Characters: 68299 Obsoletes: RFC4590 I-D Tag: draft-ietf-radext-rfc4590bis-02.txt URL: http://www.rfc-editor.org/rfc/rfc5090.txt This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Feb 2008 23:25:00 +0000 Message-ID: From: "Bernard Aboba" To: "Alan DeKok" Cc: "Stefan Winter" , Subject: Re: request to recharter Date: Thu, 14 Feb 2008 15:24:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > The "RADIUS over TCP" document could reference existing RADIUS > practices, and explain in excruciating detail why they won't work for TCP. > > Also, some issues relating to RADIUS PDU's over a stream transport may > be discussed. e.g. receiving half a RADIUS packet and then a FIN is > *not* a problem. > > The MIB counters for > radiusAuthServMalformedAccessRequests should NOT be incremented. e.g. > receiving a PDU with malformed attributes means that the TCP connection > SHOULD be closed. > > Many RADIUS practices related to handling error cases require a PDU to > be "silently discarded". This won't work for TCP. The connection has > to be closed, too. > > The existing RFC's have to be audited, and a new > document issued which explains the correct behavior. This sounds like an outline of the issues that need to be handled in the RADSEC specification. Regardless of whether the RADEXT WG ends up adding the RADSEC work to the Charter, it would be useful to include this material in the document. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Feb 2008 23:07:59 +0000 Message-ID: From: "Bernard Aboba" To: "Murtaza Chiba \(mchiba\)" , Subject: Re: inconsistency in RFC 5176 Date: Thu, 14 Feb 2008 15:06:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit There is no contradiction here. Section 3.5 says: "Values 200-299 represent successful completion, so that these values may only be sent within CoA-ACK or Disconnect-ACK packets and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet." There are only two values in the range 200-299 which are defined: 201 Residual Session Context Removed 202 Invalid EAP Packet (Ignored) Error 202 is explicitly prohibited for use by RFC 5176 implementations: "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification. Error 201 is also not currently defined for use with RFC 5176 since it refers to removal of key context, not modification or disconnection of sessions. Therefore, Section 3.5 and 3.6 are in agreement. > -----Original Message----- > From: Alfred HÎnes [mailto:ah@tr-sys.de] > Sent: Wednesday, February 13, 2008 5:51 PM > To: Murtaza Chiba (mchiba); Gopal Dommety (gdommety); Mark Eklund > (meklund); david@mitton.com > Cc: rfc-editor@rfc-editor.org > Subject: inconsistency in RFC 5176 > > Hello, > after studying the recently published RFC 5176 (RADIUS Dyn.Auth.) authored > by you, I stumbled over an apparent serious inconsistency in Section 3.5 > of that memo. > > The first clause there (on page 16) says: > > 3.5. Error-Cause > > Description > > It is possible that a Dynamic Authorization Server cannot honor > Disconnect-Request or CoA-Request packets for some reason. The > Error-Cause Attribute provides more detail on the cause of the > | problem. It MAY be included within CoA-NAK and Disconnect-NAK > | packets. > > The last sentence is consistent with the tables in Section 3.6 (pages > 20..22) that also exclude the use of the Error-Clause Attribute for the > CoA-ACK and Disconnect-ACK messages/packets. > > But surprisingly, the text in the "Value" clause in Section 3.5, from the > bottom of page 16 until page 18 repeatedly deals with inclusion or > non-inclusion of the Error-Clause Attribute into the CoA-ACK and > Disconnect-ACK messages/packets. Some of these sentences are only > confusing, but those that state applicability of the Error-Clause > Attribute contradict the intent ot the other parts of the memo. > > Please check. > > I suggest that this issue should be resolved by RFC Errata Notes > invalidating/removing all phrases in the "Value" clause that mention > CoA-ACK and Disconnect-ACK. > > > Kind regards, > Alfred HÎnes. > > P.S.: Due to inappropriate blackholing of DNS requests, apparently > caused by packet filtering based on *sorce* port somewhere > in Redmont, I cannot send a copy of this message to your > co-author Bernard Aboba. Please arrange to forward to him > a copy of this message -- thanks in advance. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Feb 2008 08:40:26 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: request to recharter Date: Thu, 14 Feb 2008 09:39:44 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2914344.vqQyJgVDnk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802140939.48497.stefan.winter@restena.lu> --nextPart2914344.vqQyJgVDnk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > As the chairs have pointed out, the WG has almost completed its work & > it seems like the only thing being considered to continue radext is > radsec. So if there is not enough work to justify a WG (something I > doubt very much) then it doesn't seem to justify the continuation of > radext, either. Just publish an Informational RFC & be done with it. > BTW, what do the members of the "worldwide-operating roaming consortium" > think about giving up change control to the IETF (or do they think that > we will simply rubberstamp this work of sheer genius)? It is clear to everyone that change control goes to the IETF. It is not at = all=20 a problem. We are in the lucky position that we don't have any commercial=20 interest or pressure, but do this work for (excuse the pathos) "the greater= =20 good of humanity" - at least the subset of humanity we are concerned with:= =20 educational users and researchers. As such, we have no interest in=20 locked-down Intellectual Property. In fact, being a (former) GPL programmer= ,=20 I have an open source guy's typical aversion against closed, IPO'ed, NDA'ed= =20 stuff. Regarding the "genius" part: I'm aware that there are several parts in the= =20 current draft that need to be looked over carefully and modified, as the=20 discussion of the last few days has already shown. I'm happy that the=20 discussion is happening, that improvements are pointed out etc. Actually, t= he=20 discussion almost looks like WG work on it has already begun :-) Greetings, Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart2914344.vqQyJgVDnk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHs/5U+jm90f8eFWYRAjKsAJ0S40HwFWCH/dQUiuKsA0d2n5sO0ACffUc3 rmRLt03WtzcUg5mgvhS4uxg= =zcnb -----END PGP SIGNATURE----- --nextPart2914344.vqQyJgVDnk-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Feb 2008 08:07:53 +0000 From: "Glen Zorn" To: "'Stefan Winter'" Cc: Subject: RE: request to recharter Date: Thu, 14 Feb 2008 15:07:22 +0700 Message-ID: <000d01c86ee0$aa4753b0$d0d8787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C86F1B.56A62BB0" Thread-Index: AchuTxjxFT0KhVCmRjC8JWczBR8ywwAiu80A This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C86F1B.56A62BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stefan Winter scribbled on Wednesday, February 13, 2008 9:45 PM: > Hi, > >> Yes, there has been a popular upswell of support for abandoning our >> work in favor of yours -- oh, wait, that would be you alone... > > well, first: it's not abandoning abandoning RADIUS work. In fact, the > RADIUS payload is left completely untouched. > > Second: it wasn't me alone. I was the one who showed up at IETF, > that's right. > But as you very well know, there was an implementation out there for > years which had customers, and RadSec has proved useful to a > worldwide-operating roaming consortium, and has been implemented by > other parties meanwhile. If I had gotten an outright reject from the > radext group as whole I wouldn't have taken the step to ask for > rechartering. But if you recall IETF69+70, there *was* support for > the work. Yes, there has also been an outcry to ignore RadSec > completely -- oh, wait, that was you alone... I'm afraid you are incorrect. From your first appearance at radext I have expressed the opinion that, while the radsec work was interesting, it is not RADIUS & therefore does not belong in the radext WG. > >> No, no, NO! "radsec" is not RADIUS, period. Not an extension, not >> even a perversion, not RADIUS. > > We've had a discussion on that topic before on this list. That time, > at the end you resorted to a strange analogy of ducks and snakes > IIRC, not providing a reasonable argumentation. I assume that you are referring to the following exchange (https://ops.ietf.org/lists/radiusext/2007/msg00603.html): > Well, except that in order to place these things in a common category it > is necessary to ignore one of the defining characteristics of RADIUS: > that it is only and intentionally defined as a connectionless protocol. >> The impact of connectionless vs. connection is not very significant when >> discussing the protocol's *security*, IMO. So I gather that as far as you're concerned a network "protocol" solely consists of the format of the innermost PDU? > might like to believe so, RadSec is _not_ RADIUS, >> Well, it's _almost_ RADIUS, especially if one takes into account the >> mechanisms in RADIUS to detect duplication, retransmission etc, which already >> contains parts of the merits of TCP. By that logic, a cobra is _almost_ a pigeon. > & therefore far out of > scope of not just the crypto-agility discussions but of this WG. > RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS & > therefore _is_ in scope. >> I have understood that DTLS is considered in scope, while RadSec is out of >> scope (Reminder: I never claimed otherwise). Just keep in mind that DTLS >> itself requires even more characteristics of TCP, so when combining the >> RADIUS mechanisms that come on top of UDP + the transport mechanisms in DTLS, >> the end result is getting very close to TCP already. So the distance between >> in-scope and out-of-scope is a very thin line. Only if snakes are almost birds... I'm sorry that you didn't understand that simile. Perhaps you also don't recall (or didn't understand) the message that elicited it (https://ops.ietf.org/lists/radiusext/2007/msg00590.html): > I agree that it is not relevant for crypto-agility discussions. As I > see it, DTLS and RadSec fall under a common category in this respect: > whole packet encryption, with encryption negotiation happening > outside of RADIUS. Well, except that in order to place these things in a common category it is necessary to ignore one of the defining characteristics of RADIUS: that it is only and intentionally defined as a connectionless protocol. This is not an accidental result of the transport choice as you seem to imply below ("{some transport}+{the equivalent of TLS for that transport}"), but a fundamental quality of RADIUS itself. Much as you might like to believe so, RadSec is _not_ RADIUS, & therefore far out of scope of not just the crypto-agility discussions but of this WG. RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS & therefore _is_ in scope. Since the "strange analogy" you deride was an attempt to explain the above statement (what part of it is "unreasonable", exactly?) I won't risk further derision by attempting to explain it again. > >> I would support a radsec BOF & WG, but I will not support this. > > *Thank you*! It is very nice to read that you would support a WG for > that work, which appears to imply that you see the concept as worthy > for exploration and eventual standardisation. See above; actually, I'm not really sure about standardization, but surely it could be documented. > Actually, I had been > thinking about this way forward as well. The outcome was that > creating a whole new working group for this one thing probably isn't > justified. After all, it is not likely to create follow-up work, it's > pretty much a standalone thing to add to RADIUS. So, if a working > group isn't justified due to lack of amount of work, but the work is > still somewhat important, where would the place to go be? My > conclusion was that radext is the place to go. As the chairs have pointed out, the WG has almost completed its work & it seems like the only thing being considered to continue radext is radsec. So if there is not enough work to justify a WG (something I doubt very much) then it doesn't seem to justify the continuation of radext, either. Just publish an Informational RFC & be done with it. BTW, what do the members of the "worldwide-operating roaming consortium" think about giving up change control to the IETF (or do they think that we will simply rubberstamp this work of sheer genius)? > And I still think that > reasoning is justified, Bernard's reply in the thread looks like it > is at least deemed worth a consideration. > > Greetings, > > Stefan Winter ------=_NextPart_000_000E_01C86F1B.56A62BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan Winter <mailto:stefan.winter@restena.lu<= /A>>=20 scribbled on Wednesday, February 13, 2008 9:45 PM:

>=20 Hi,
>
>> Yes, there has been a popular upswell of support = for=20 abandoning our
>> work in favor of yours -- oh, wait, that = would be you=20 alone...
>
> well, first: it's not abandoning abandoning = RADIUS=20 work. In fact, the
> RADIUS payload is left completely=20 untouched.
>
> Second: it wasn't me alone. I was the one who = showed=20 up at IETF,
> that's right.
> But as you very well know, = there was=20 an implementation out there for
> years which had customers, and = RadSec=20 has proved useful to a
> worldwide-operating roaming consortium, = and has=20 been implemented by
> other parties meanwhile. If I had gotten an = outright=20 reject from the
> radext group as whole I wouldn't have taken the = step to=20 ask for
> rechartering. But if you recall IETF69+70, there *was* = support=20 for
> the work. Yes, there has also been an outcry to ignore=20 RadSec
> completely -- oh, wait, that was you = alone... 

I'm afraid you are incorrect.  From your first = appearance at=20 radext I have expressed the opinion that, while the radsec work was = interesting,=20 it is not RADIUS & therefore does not belong in the radext=20 WG. 
 
>
>> No, no, NO!  = "radsec" is not=20 RADIUS, period.  Not an extension, not
>> even a = perversion, not=20 RADIUS.
>
> We've had a discussion on that topic before on = this=20 list. That time,
> at the end you resorted to a strange analogy of = ducks=20 and snakes
> IIRC, not providing a reasonable=20 argumentation. 

I assume that you are = referring=20 to the following exchange (https://= ops.ietf.org/lists/radiusext/2007/msg00603.html):

<QUOTE>
> Well, except that in order to = place these=20 things in a common category it
> is necessary to ignore one of the = defining characteristics of RADIUS:
> that it is only and = intentionally=20 defined as a connectionless protocol.

>> The impact of=20 connectionless vs. connection is not very significant when
>>=20 discussing the protocol's *security*, IMO.

So I gather that as = far as=20 you're concerned a network "protocol" solely consists of the format of = the=20 innermost PDU?

> might like to believe so, RadSec is _not_=20 RADIUS,

>> Well, it's _almost_ RADIUS, especially if one = takes into=20 account the
>> mechanisms in RADIUS to detect duplication,=20 retransmission etc, which already
>> contains parts of the = merits of=20 TCP.

By that logic, a cobra is _almost_ a pigeon.

> = &=20 therefore far out of
> scope of not just the crypto-agility = discussions=20 but of this WG.
> RADIUSoDTLS, OTOH, doesn't alter the fundamental = nature=20 of RADIUS &
> therefore _is_ in scope.

>> I have=20 understood that DTLS is considered in scope, while RadSec is out = of
>>=20 scope (Reminder: I never claimed otherwise). Just keep in mind that=20 DTLS
>> itself requires even more characteristics of TCP, so = when=20 combining the
>> RADIUS mechanisms that come on top of UDP + = the=20 transport mechanisms in DTLS,
>> the end result is getting very = close=20 to TCP already. So the distance between
>> in-scope and = out-of-scope is=20 a very thin line.

Only if snakes are almost=20 birds...
</QUOTE>

I'm sorry = that you=20 didn't understand that simile.  Perhaps you also don't recall (or = didn't=20 understand) the message that elicited it (https://= ops.ietf.org/lists/radiusext/2007/msg00590.html):
<QUOTE>
> I agree that it is not relevant = for=20 crypto-agility discussions. As I
> see it, DTLS and RadSec fall = under a=20 common category in this respect:
> whole packet encryption, with=20 encryption negotiation happening
> outside of=20 RADIUS.  

Well, except that in order to place these = things in a=20 common category it
is necessary to ignore one of the defining = characteristics=20 of RADIUS:
that it is only and intentionally defined as a = connectionless=20 protocol.
This is not an accidental result of the transport choice as = you=20 seem to
imply below ("{some transport}+{the equivalent of TLS for=20 that
transport}"), but a fundamental quality of RADIUS itself.  = Much as=20 you
might like to believe so, RadSec is _not_ RADIUS, & therefore = far out=20 of
scope of not just the crypto-agility discussions but of this=20 WG.
RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS = &
therefore _is_ in scope.
</QUOTE>

Since the "strange analogy" you deride was an attempt to = explain=20 the above statement (what part of it is "unreasonable", exactly?)  = I won't=20 risk further derision by attempting to explain it=20 again.

>
>> I would support a radsec BOF & = WG, but=20 I will not support this.
>
> *Thank you*! It is very nice to = read=20 that you would support a WG for
> that work, which appears to = imply that=20 you see the concept as worthy
> for exploration and eventual=20 standardisation.

See above; actually, I'm not really = sure about=20 standardization, but surely it could be documented. 

> Actually, I had been
> thinking about this = way=20 forward as well. The outcome was that
> creating a whole new = working group=20 for this one thing probably isn't
> justified. After all, it is = not likely=20 to create follow-up work, it's
> pretty much a standalone thing to = add to=20 RADIUS. So, if a working
> group isn't justified due to lack of = amount of=20 work, but the work is
> still somewhat important, where would the = place to=20 go be? My
> conclusion was that radext is the place to go. =

As the chairs have pointed out, the WG = has almost=20 completed its work & it seems like the only thing being considered = to=20 continue radext is radsec.  So if there is not enough work to = justify a WG=20 (something I doubt very much) then it doesn't seem to justify the = continuation=20 of radext, either.  Just publish an Informational RFC & be done = with=20 it.  BTW, what do the members of the "worldwide-operating = roaming=20 consortium" think about giving up change control to the IETF (or do they = think=20 that we will simply rubberstamp this work of sheer genius)?

> And I still think that
> reasoning is = justified,=20 Bernard's reply in the thread looks like it
> is at least deemed = worth a=20 consideration.         
&= gt;
>=20 Greetings,
>
> Stefan Winter

------=_NextPart_000_000E_01C86F1B.56A62BB0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Feb 2008 07:59:13 +0000 From: Stefan Winter Organization: Fondation RESTENA To: Alan DeKok Subject: Re: request to recharter Date: Thu, 14 Feb 2008 08:58:24 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Bernard Aboba , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3320479.kJetg781WW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802140858.28754.stefan.winter@restena.lu> --nextPart3320479.kJetg781WW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Partly psychological... people are more likely to read a "RADIUS over > TCP" document than an "AAA over TCP" document. Also, standardizing TCP > as a RADIUS transport would require the publication of *some* kind of > document, if I understand the IETF process correctly. We couldn't just > announce that it's OK... The draft currently already references 3539, in section "Connection=20 Keepalive":=20 " A RadSec node which initiates a RadSec connection SHOULD send the Status-Server packets defined in [10] according to the state machine in section 3.4 of [6] since RadSec operates on a reliable transport protocol." where [6] is a reference to 3539. That text could be made more explicitly=20 though, and reference 3539 as a whole, not just the one section with the=20 state machine. > The "RADIUS over TCP" document could reference existing RADIUS > practices, and explain in excruciating detail why they won't work for TCP. > > Also, some issues relating to RADIUS PDU's over a stream transport may > be discussed. e.g. receiving half a RADIUS packet and then a FIN is > *not* a problem. The MIB counters for > radiusAuthServMalformedAccessRequests should NOT be incremented. e.g. > receiving a PDU with malformed attributes means that the TCP connection > SHOULD be closed. > > Many RADIUS practices related to handling error cases require a PDU to > be "silently discarded". This won't work for TCP. The connection has > to be closed, too. The existing RFC's have to be audited, and a new > document issued which explains the correct behavior. Sounds plausible. Greetings, Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart3320479.kJetg781WW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHs/Sk+jm90f8eFWYRAniKAKCKP8FmUakhX7UYSULgJowOCoxi8ACfQBXQ V+/xPafSKjJMGyr3M6wjPJY= =gjxt -----END PGP SIGNATURE----- --nextPart3320479.kJetg781WW-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Feb 2008 06:17:12 +0000 Message-ID: <47B3DC02.7070709@nitros9.org> Date: Thu, 14 Feb 2008 07:13:22 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: Stefan Winter , radiusext@ops.ietf.org Subject: Re: request to recharter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Since RFC 3539 already defines the transport profile and failover algorithms > for AAA running over TCP/SCTP, I am not clear what remaining work is > required in that area. Partly psychological... people are more likely to read a "RADIUS over TCP" document than an "AAA over TCP" document. Also, standardizing TCP as a RADIUS transport would require the publication of *some* kind of document, if I understand the IETF process correctly. We couldn't just announce that it's OK... The "RADIUS over TCP" document could reference existing RADIUS practices, and explain in excruciating detail why they won't work for TCP. Also, some issues relating to RADIUS PDU's over a stream transport may be discussed. e.g. receiving half a RADIUS packet and then a FIN is *not* a problem. The MIB counters for radiusAuthServMalformedAccessRequests should NOT be incremented. e.g. receiving a PDU with malformed attributes means that the TCP connection SHOULD be closed. Many RADIUS practices related to handling error cases require a PDU to be "silently discarded". This won't work for TCP. The connection has to be closed, too. The existing RFC's have to be audited, and a new document issued which explains the correct behavior. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Feb 2008 02:22:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: inconsistency in RFC 5176 Date: Wed, 13 Feb 2008 18:21:48 -0800 Message-ID: Thread-Topic: inconsistency in RFC 5176 Thread-Index: AchurF1toURjm34sRTCZ45MRUMM1gAAA9zQw From: "Murtaza Chiba (mchiba)" To: , "Bernard Aboba" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2391; t=1202955722; x=1203819722; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20FW=3A=20inconsistency=20in=20RFC=205176 |Sender:=20; bh=N1A8K0X8fl0QkJCbg9YvQpLUDarjscq2U7jWeLJsQyY=; b=GjgaFhaPamiCvGcTb3HzDF2pVgXBAoTmasI2iKmTMwIfoFbO+QmWFAyXdQ XXxvlfimi0fqjuDuMpRFiTdCXf2ZkHo2P0rVyn9di+g7dbzCtL8vin72NZfo PC9f21M90C; Authentication-Results: sj-dkim-4; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); =20 -----Original Message----- From: Alfred H=CEnes [mailto:ah@tr-sys.de]=20 Sent: Wednesday, February 13, 2008 5:51 PM To: Murtaza Chiba (mchiba); Gopal Dommety (gdommety); Mark Eklund = (meklund); david@mitton.com Cc: rfc-editor@rfc-editor.org Subject: inconsistency in RFC 5176 Hello, after studying the recently published RFC 5176 (RADIUS Dyn.Auth.) = authored by you, I stumbled over an apparent serious inconsistency in = Section 3.5 of that memo. The first clause there (on page 16) says: 3.5. Error-Cause Description It is possible that a Dynamic Authorization Server cannot honor Disconnect-Request or CoA-Request packets for some reason. The Error-Cause Attribute provides more detail on the cause of the | problem. It MAY be included within CoA-NAK and Disconnect-NAK | packets. The last sentence is consistent with the tables in Section 3.6 (pages = 20..22) that also exclude the use of the Error-Clause Attribute for the = CoA-ACK and Disconnect-ACK messages/packets. But surprisingly, the text in the "Value" clause in Section 3.5, from = the bottom of page 16 until page 18 repeatedly deals with inclusion or = non-inclusion of the Error-Clause Attribute into the CoA-ACK and = Disconnect-ACK messages/packets. Some of these sentences are only = confusing, but those that state applicability of the Error-Clause = Attribute contradict the intent ot the other parts of the memo. Please check. I suggest that this issue should be resolved by RFC Errata Notes = invalidating/removing all phrases in the "Value" clause that mention = CoA-ACK and Disconnect-ACK. Kind regards, Alfred H=CEnes. P.S.: Due to inappropriate blackholing of DNS requests, apparently caused by packet filtering based on *sorce* port somewhere in Redmont, I cannot send a copy of this message to your co-author Bernard Aboba. Please arrange to forward to him a copy of this message -- thanks in advance. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Feb 2008 00:48:17 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_0bac74ce-4cb2-4fa1-9e61-718c09c046b2_" From: Bernard Aboba To: Subject: RFC 5090 published as a Proposed Standard Date: Wed, 13 Feb 2008 16:47:41 -0800 MIME-Version: 1.0 --_0bac74ce-4cb2-4fa1-9e61-718c09c046b2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 5090 (RADIUS Digest Authentication) has now been published as an RFC: http://www.ietf.org/rfc/rfc5090.txt Congratulations to the authors, as well as everyone who worked on this "min= or update" to RFC 4590 that ended up being more work than any of us expecte= d :) --_0bac74ce-4cb2-4fa1-9e61-718c09c046b2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 5090 (RADIUS Digest Authentication) has now been published as an RFC:http://www.ietf.org/rfc/rfc5090.txt

Congratulations to the authors= , as well as everyone who worked on this "minor update" to RFC 4590 that en= ded up being more work than any of us expected :)
= --_0bac74ce-4cb2-4fa1-9e61-718c09c046b2_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Feb 2008 23:21:50 +0000 From: "David B. Nelson" To: Subject: RE: request to recharter Date: Wed, 13 Feb 2008 18:21:33 -0500 Message-ID: <00a001c86e97$2c6bf9d0$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchulTgSa3VmN9EXTkSkpAzxnLqOQAAAa44g Bernard Aboba writes... > There is already a proposed standard for the transport of AAA protocols > over TCP, "Authentication, Authorization and Accounting (AAA) Transport > Profile", RFC 3539. Yes. Alan pointed that out in a follow up message. Was that document created as part of the Diameter requirements work? Just curious. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Feb 2008 23:09:29 +0000 Message-ID: From: Bernard Aboba To: Alan DeKok , Stefan Winter CC: Subject: RE: request to recharter Date: Wed, 13 Feb 2008 15:09:15 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 > If TCP is accepted, I would suggest a draft focussed on issues relating t= o TCP as a transport > protocol. The RadSec document can then reference this draft. Since RFC 3539 already defines the transport profile and failover algorithm= s for AAA running over TCP/SCTP, I am not clear what remaining work is required in that area. = -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Feb 2008 23:04:52 +0000 Message-ID: From: Bernard Aboba To: "David B. Nelson" , Subject: RE: request to recharter Date: Wed, 13 Feb 2008 15:04:07 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 > I think that would be warranted, whether in a separate document or > integrated. Someone sent me an off-list reply, expressing concern about > changes to the RADIUS paradigm for timeouts and retransmissions, when usi= ng > TCP. Those issues would certainly need to be addressed. There is already a proposed standard for the transport of AAA protocols ove= r TCP, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC= 3539. = -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Feb 2008 18:04:24 +0000 Message-ID: <47B3304F.9030005@nitros9.org> Date: Wed, 13 Feb 2008 19:00:47 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: request to recharter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > I think that would be warranted, whether in a separate document or > integrated. Someone sent me an off-list reply, expressing concern about > changes to the RADIUS paradigm for timeouts and retransmissions, when using > TCP. Those issues would certainly need to be addressed. RFC 3539 already has a suggested retransmission and timeout algorithm for AAA protocols over TCP. I think that could be used. Any document for RADIUS + TCP would need to concentrate on RADIUS-specific issues. e.g. UDP RADIUS practices are NOT appropriate when TCP is used as a transport protocol. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Feb 2008 17:39:44 +0000 From: "David B. Nelson" To: Subject: RE: request to recharter Date: Wed, 13 Feb 2008 12:39:23 -0500 Message-ID: <078001c86e67$5fec7d00$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AchuYqCUQ3pEYVGESwSMVkPhtIQfIQABEzAw Alan DeKok writes... > If TCP is accepted, I would suggest a draft focussed on issues > relating to TCP as a transport protocol. I think that would be warranted, whether in a separate document or integrated. Someone sent me an off-list reply, expressing concern about changes to the RADIUS paradigm for timeouts and retransmissions, when using TCP. Those issues would certainly need to be addressed. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Feb 2008 17:00:34 +0000 Message-ID: <47B3214B.4050407@nitros9.org> Date: Wed, 13 Feb 2008 17:56:43 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Winter CC: radiusext@ops.ietf.org Subject: Re: request to recharter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stefan Winter wrote: > The points above make me think that it is about time to seriously consider > that the radext charter is modified to include RadSec into the working group > scope. I have no objections, presuming that TCP is also accepted as a transport protocol. > The only part in the charter that would need to be changed is, obviously, the > line > > "- No new RADIUS transports (e.g. TCP, SCTP) will be defined." > > which I request to purge from the charter. I'm not sure I understand all of Glen's concerns, but TCP as a transport protocol is a fairly large change to RADIUS. The basic send/receive concepts don't change. The packet formats don't change, but there are issues relating to TCP && AAA stability, as discussed in RFC 3539. I have no major objections to this. If TCP is accepted, I would suggest a draft focussed on issues relating to TCP as a transport protocol. The RadSec document can then reference this draft. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Feb 2008 14:46:37 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: request to recharter Date: Wed, 13 Feb 2008 15:45:29 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1746412.3UTehyOUJ2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802131545.33245.stefan.winter@restena.lu> --nextPart1746412.3UTehyOUJ2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Yes, there has been a popular upswell of support for abandoning our work > in favor of yours -- oh, wait, that would be you alone... well, first: it's not abandoning abandoning RADIUS work. In fact, the RADIU= S=20 payload is left completely untouched. Second: it wasn't me alone. I was the one who showed up at IETF, that's rig= ht.=20 But as you very well know, there was an implementation out there for years= =20 which had customers, and RadSec has proved useful to a worldwide-operating= =20 roaming consortium, and has been implemented by other parties meanwhile. If= I=20 had gotten an outright reject from the radext group as whole I wouldn't hav= e=20 taken the step to ask for rechartering. But if you recall IETF69+70, there= =20 *was* support for the work. Yes, there has also been an outcry to ignore=20 RadSec completely -- oh, wait, that was you alone... > No, no, NO! "radsec" is not RADIUS, period. Not an extension, not even > a perversion, not RADIUS.=20 We've had a discussion on that topic before on this list. That time, at the= =20 end you resorted to a strange analogy of ducks and snakes IIRC, not providi= ng=20 a reasonable argumentation. > I would support a radsec BOF & WG, but I will not support this. *Thank you*! It is very nice to read that you would support a WG for that=20 work, which appears to imply that you see the concept as worthy for=20 exploration and eventual standardisation. Actually, I had been thinking abo= ut=20 this way forward as well. The outcome was that creating a whole new working= =20 group for this one thing probably isn't justified. After all, it is not=20 likely to create follow-up work, it's pretty much a standalone thing to add= =20 to RADIUS. So, if a working group isn't justified due to lack of amount of work, but t= he=20 work is still somewhat important, where would the place to go be? My=20 conclusion was that radext is the place to go. And I still think that=20 reasoning is justified, Bernard's reply in the thread looks like it is at=20 least deemed worth a consideration. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart1746412.3UTehyOUJ2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHswKN+jm90f8eFWYRArOVAJ42rr5nS5gLX36f8ITCJnmJj1MRQwCbBuzh AG0QdoKJ4OQ6KhoWg5xuYCw= =k9/G -----END PGP SIGNATURE----- --nextPart1746412.3UTehyOUJ2-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 12 Feb 2008 16:08:53 +0000 From: "David B. Nelson" To: Subject: RE: request to recharter Date: Tue, 12 Feb 2008 11:04:03 -0500 Organization: Elbrys Networks, Inc. Message-ID: <010e01c86d90$e3756920$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchsmO0sxJh8DZt2QmSwaf2B7i/MqgAeHcSAAB+sv7A= Glen Zorn writes... > No, no, NO! "radsec" is not RADIUS, period. Not an extension, > not even a perversion, not RADIUS. Without offering any opinion as to whether RADEXT should seek to amend its charter to include RADSEC, let me ask why RADIUS over TLS/TCP is conceptually so different from RADIUS over IPSec? Seems to me that both are RADIUS encapsulated in protected transport. We are also considering RADIUS over DTLS/UDP, and you don't seem to be quire so concerned about that proposal. Is it the use of TCP that bothers you so much? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 12 Feb 2008 13:19:18 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'Greg Weber'" , Subject: RE: LC cmts: Extended Attrs Date: Tue, 12 Feb 2008 20:18:10 +0700 Message-ID: <000e01c86d79$c0da46e0$e3e6787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C86DB4.6D391EE0" Thread-Index: AchtP58ea4I8p1DuRqyPdH6mcWB+UQAOSZ2Q This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C86DB4.6D391EE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have some additional comments on the document: 1. Diameter Considerations. There currently is no Diameter Considerations section. One issue that arises is how to map the Extended Attribute space into the Diameter attribute space. Since Diameter AVP numbers have been assigned with codes >255, the mapping requires an offset to be added to RADIUS Extended Attribute codes. Off the top of my head, I am clear what this offset should be. Also, I think there is the issue of how the extended grouped attributes are mapped into grouped Diameter AVPs. Why don't you think that section 9.6.2 of RFC 4005 applies here (w/the possible exception of setting the Mandatory bit)?. 2. IANA considerations. The text in the current document is minimal, and I think there is room for considerably more discussion there. Given the potential differences in treatment of attributes within the VSA space and standard RADIUS attributes, I think that the IANA considerations should indicate that Extended Attributes should initially be allocated only on request. I disagree. It seems to me that the new, empty space should be used first whenever possible; it is conceivable that some application might absolutely require a legacy standard attribute when they're all gone. In addition, I think that phasing in extended attributes slowly might lessen the chance that implementors will ignore them until the last minute. OTOH, I'm not religious about it. However, as the standard RADIUS attribute space is exhausted, there will eventually be no choice but to allocate out of the extended space. The question is how attributes should be allocated. > Date: Mon, 11 Feb 2008 23:30:50 -0500 > From: gdweber@gmail.com > To: radiusext@ops.ietf.org > Subject: LC cmts: Extended Attrs > > I have some comments on: draft-ietf-radext-extended-attributes-00.txt > > * In section 5, the Ext-Length field is defined as the length of the Extended > Attribute. I think you mean it's the length of the TLV (multiple TLVs can be > in the Extended Attribute). I think that would make the value ">=3", not ">=4". > > * It's probably worth calling out any artifacts of overloading attribute 26 > which wouldn't apply to standard attributes in the original number space > (or apply to overloading a new attribute instead of 26). For example, > attribute 26 is already specifically excluded from some RADIUS message > types, e.g. CoA-NAK, so new Extended Attributes couldn't be included in > those messages, but new standard attribute could be. Also, are malformed > VSAs always treated just like malformed non-VSAs? > > * I think it would be useful to explicitly mention if recursive grouping is > allowed and that Extended Attributes cannot be grouped with non-Extended > Attributes. > > * It's probably useful to mention what happens when an Extended Attribute's > tag is non-zero and it contains multiple TLVs (this does not seem to be > excluded -as multiple TLVs are when the M-bit is on). > > * RFC2865 specifically calls out the proxies can't reorder attributes > of the same > type; does this doc need to create the same restriction for Ext-Type? > > * I actually didn't have a lot of editorial comments :-) Possibly the M-bit > could be renamed to avoid potential confusion with Diameter. > > Greg > > > On Feb 10, 2008 3:50 PM, Bernard Aboba wrote: > > > > This is a reminder of the ongoing RADEXT WG last call on the Extended > > RADIUS Attributes document, prior to sending it to the IESG for > > consideration as a Proposed Standard. The document is available for > > inspection here: > > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute s-00.txt > > > > RADEXT WG last call will last until February 14, 2008. Please send comments > > to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format > > described on the RADEXT WG Issues page: > > http://www.drizzle.com/~aboba/RADEXT/ > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: ------=_NextPart_000_000F_01C86DB4.6D391EE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have some additional comments on the=20 document:
 
1. Diameter Considerations.  There currently = is no=20 Diameter Considerations section.
One issue that arises is how to map = the=20 Extended Attribute space into the Diameter
attribute space.  = Since=20 Diameter AVP numbers have been assigned with codes >255,
the = mapping=20 requires an offset to be added to RADIUS Extended Attribute = codes.
Off the=20 top of my head, I am clear what this offset should be. =
 
Also, I=20 think there is the issue of how the extended grouped attributes are=20 mapped
into grouped Diameter AVPs.   
Why don't you think that section 9.6.2 of RFC 4005 = applies here=20 (w/the possible exception of setting the Mandatory=20 bit)?.  
 
2. IANA = considerations.=20   The text in the current document is minimal, and I think
there = is room=20 for considerably more discussion there.
Given the potential = differences in=20 treatment of attributes
within the VSA space and standard RADIUS = attributes,=20 I think that the IANA considerations
should indicate that Extended = Attributes=20 should initially be allocated only on request.  
I disagree.  It seems to me that the new, empty = space should=20 be used first whenever possible; it is conceivable that some application = might=20 absolutely require a legacy standard attribute when they're all = gone.  In=20 addition, I think that phasing in extended attributes slowly might = lessen the=20 chance that implementors will ignore them until the last minute.  = OTOH, I'm=20 not religious about it.
However, as the standard RADIUS = attribute space is exhausted, there will eventually
be no choice but = to=20 allocate out of the extended space.  The question is how=20 attributes
should be allocated. 

> Date: Mon, 11 Feb = 2008=20 23:30:50 -0500
> From: gdweber@gmail.com
> To:=20 radiusext@ops.ietf.org
> Subject: LC cmts: Extended Attrs
> =
>=20 I have some comments on: = draft-ietf-radext-extended-attributes-00.txt
>=20
> * In section 5, the Ext-Length field is defined as the length = of the=20 Extended
> Attribute. I think you mean it's the length of the TLV=20 (multiple TLVs can be
> in the Extended Attribute). I think that = would=20 make the value ">=3D3", not ">=3D4".
>
> * It's = probably worth=20 calling out any artifacts of overloading attribute 26
> which = wouldn't=20 apply to standard attributes in the original number space
> (or = apply to=20 overloading a new attribute instead of 26). For example,
> = attribute 26 is=20 already specifically excluded from some RADIUS message
> types, = e.g.=20 CoA-NAK, so new Extended Attributes couldn't be included in
> = those=20 messages, but new standard attribute could be. Also, are = malformed
> VSAs=20 always treated just like malformed non-VSAs?
>
> * I think = it would=20 be useful to explicitly mention if recursive grouping is
> allowed = and=20 that Extended Attributes cannot be grouped with non-Extended
>=20 Attributes.
>
> * It's probably useful to mention what = happens when=20 an Extended Attribute's
> tag is non-zero and it contains multiple = TLVs=20 (this does not seem to be
> excluded -as multiple TLVs are when = the M-bit=20 is on).
>
> * RFC2865 specifically calls out the proxies = can't=20 reorder attributes
> of the same
> type; does this doc need = to=20 create the same restriction for Ext-Type?
>
> * I actually = didn't=20 have a lot of editorial comments :-) Possibly the M-bit
> could be = renamed=20 to avoid potential confusion with Diameter.
>
> = Greg
>=20
>
> On Feb 10, 2008 3:50 PM, Bernard Aboba=20 <bernard_aboba@hotmail.com> wrote:
> >
> > This = is a=20 reminder of the ongoing RADEXT WG last call on the Extended
> > = RADIUS=20 Attributes document, prior to sending it to the IESG for
> >=20 consideration as a Proposed Standard. The document is available = for
> >=20 inspection here:
> >=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes= -00.txt
>=20 >
> > RADEXT WG last call will last until February 14, 2008. = Please=20 send comments
> > to the RADEXT WG mailing list=20 (radiusext@ops.ietf.org) in the format
> > described on the = RADEXT WG=20 Issues page:
> > http://www.drizzle.com/~aboba/RADEXT/
> =
>=20 --
> to unsubscribe send a message to = radiusext-request@ops.ietf.org=20 with
> the word 'unsubscribe' in a single line as the message text = body.
> archive:=20 <http://psg.com/lists/radiusext/>

------=_NextPart_000_000F_01C86DB4.6D391EE0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 12 Feb 2008 06:19:22 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_a47af0b9-587b-413c-8d6b-95d15e55a8d5_" From: Bernard Aboba To: Greg Weber , Subject: RE: LC cmts: Extended Attrs Date: Mon, 11 Feb 2008 22:18:37 -0800 MIME-Version: 1.0 --_a47af0b9-587b-413c-8d6b-95d15e55a8d5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have some additional comments on the document: =20 1. Diameter Considerations. There currently is no Diameter Considerations = section.=20 One issue that arises is how to map the Extended Attribute space into the D= iameter attribute space. Since Diameter AVP numbers have been assigned with codes = >255, the mapping requires an offset to be added to RADIUS Extended Attribute cod= es. Off the top of my head, I am clear what this offset should be.=20 =20 Also, I think there is the issue of how the extended grouped attributes are= mapped into grouped Diameter AVPs. =20 =20 2. IANA considerations. The text in the current document is minimal, and = I think there is room for considerably more discussion there. Given the potential differences in treatment of attributes within the VSA space and standard RADIUS attributes, I think that the IANA = considerations should indicate that Extended Attributes should initially be allocated only= on request.=20 However, as the standard RADIUS attribute space is exhausted, there will ev= entually be no choice but to allocate out of the extended space. The question is ho= w attributes should be allocated. > Date: Mon, 11 Feb 2008 23:30:50 -0500> From: gdwebe= r@gmail.com> To: radiusext@ops.ietf.org> Subject: LC cmts: Extended Attrs> = > I have some comments on: draft-ietf-radext-extended-attributes-00.txt> > = * In section 5, the Ext-Length field is defined as the length of the Extend= ed> Attribute. I think you mean it's the length of the TLV (multiple TLVs c= an be> in the Extended Attribute). I think that would make the value ">=3D3= ", not ">=3D4".> > * It's probably worth calling out any artifacts of overl= oading attribute 26> which wouldn't apply to standard attributes in the ori= ginal number space> (or apply to overloading a new attribute instead of 26)= . For example,> attribute 26 is already specifically excluded from some RAD= IUS message> types, e.g. CoA-NAK, so new Extended Attributes couldn't be in= cluded in> those messages, but new standard attribute could be. Also, are m= alformed> VSAs always treated just like malformed non-VSAs?> > * I think it= would be useful to explicitly mention if recursive grouping is> allowed an= d that Extended Attributes cannot be grouped with non-Extended> Attributes.= > > * It's probably useful to mention what happens when an Extended Attribu= te's> tag is non-zero and it contains multiple TLVs (this does not seem to = be> excluded -as multiple TLVs are when the M-bit is on).> > * RFC2865 spec= ifically calls out the proxies can't reorder attributes> of the same> type;= does this doc need to create the same restriction for Ext-Type?> > * I act= ually didn't have a lot of editorial comments :-) Possibly the M-bit> could= be renamed to avoid potential confusion with Diameter.> > Greg> > > On Feb= 10, 2008 3:50 PM, Bernard Aboba wrote:> >> > T= his is a reminder of the ongoing RADEXT WG last call on the Extended> > RAD= IUS Attributes document, prior to sending it to the IESG for> > considerati= on as a Proposed Standard. The document is available for> > inspection here= :> > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribu= tes-00.txt> >> > RADEXT WG last call will last until February 14, 2008. Ple= ase send comments> > to the RADEXT WG mailing list (radiusext@ops.ietf.org)= in the format> > described on the RADEXT WG Issues page:> > http://www.dri= zzle.com/~aboba/RADEXT/> > --> to unsubscribe send a message to radiusext-r= equest@ops.ietf.org with> the word 'unsubscribe' in a single line as the me= ssage text body.> archive: = --_a47af0b9-587b-413c-8d6b-95d15e55a8d5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have some additional comments on the document:
 
1. Diameter Considerations.  There currently is no Diameter Considerat= ions section.
One issue that arises is how to map the Extended Attribute space into the D= iameter
attribute space.  Since Diameter AVP numbers have been assigned with c= odes >255,
the mapping requires an offset to be added to RADIUS Extended Attribute cod= es.
Off the top of my head, I am clear what this offset should be.
 
Also, I think there is the issue of how the extended grouped attributes are= mapped
into grouped Diameter AVPs. 
 
2. IANA considerations.   The text in the current document is min= imal, and I think
there is room for considerably more discussion there.
Given the potential differences in treatment of attributes
within the VSA space and standard RADIUS attributes, I think that the IANA = considerations
should indicate that Extended Attributes should initially be allocated only= on request.
However, as the standard RADIUS attribute space is exhausted, there will ev= entually
be no choice but to allocate out of the extended space.  The question = is how attributes
should be allocated. 

> Date: Mon, 11 Feb 2008 23:30:50 -05= 00
> From: gdweber@gmail.com
> To: radiusext@ops.ietf.org
&g= t; Subject: LC cmts: Extended Attrs
>
> I have some comments o= n: draft-ietf-radext-extended-attributes-00.txt
>
> * In secti= on 5, the Ext-Length field is defined as the length of the Extended
>= Attribute. I think you mean it's the length of the TLV (multiple TLVs can = be
> in the Extended Attribute). I think that would make the value "&= gt;=3D3", not ">=3D4".
>
> * It's probably worth calling ou= t any artifacts of overloading attribute 26
> which wouldn't apply to= standard attributes in the original number space
> (or apply to over= loading a new attribute instead of 26). For example,
> attribute 26 i= s already specifically excluded from some RADIUS message
> types, e.g= . CoA-NAK, so new Extended Attributes couldn't be included in
> those= messages, but new standard attribute could be. Also, are malformed
>= VSAs always treated just like malformed non-VSAs?
>
> * I thi= nk it would be useful to explicitly mention if recursive grouping is
>= ; allowed and that Extended Attributes cannot be grouped with non-Extended<= BR>> Attributes.
>
> * It's probably useful to mention what= happens when an Extended Attribute's
> tag is non-zero and it contai= ns multiple TLVs (this does not seem to be
> excluded -as multiple TL= Vs are when the M-bit is on).
>
> * RFC2865 specifically calls= out the proxies can't reorder attributes
> of the same
> type;= does this doc need to create the same restriction for Ext-Type?
> > * I actually didn't have a lot of editorial comments :-) Possibly th= e M-bit
> could be renamed to avoid potential confusion with Diameter= .
>
> Greg
>
>
> On Feb 10, 2008 3:50 PM, = Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> >
>= > This is a reminder of the ongoing RADEXT WG last call on the Extended=
> > RADIUS Attributes document, prior to sending it to the IESG f= or
> > consideration as a Proposed Standard. The document is avail= able for
> > inspection here:
> > http://www.ietf.org/int= ernet-drafts/draft-ietf-radext-extended-attributes-00.txt
> >
&= gt; > RADEXT WG last call will last until February 14, 2008. Please send= comments
> > to the RADEXT WG mailing list (radiusext@ops.ietf.or= g) in the format
> > described on the RADEXT WG Issues page:
&g= t; > http://www.drizzle.com/~aboba/RADEXT/
>
> --
> t= o unsubscribe send a message to radiusext-request@ops.ietf.org with
>= the word 'unsubscribe' in a single line as the message text body.
> = archive: <http://psg.com/lists/radiusext/>

= --_a47af0b9-587b-413c-8d6b-95d15e55a8d5_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 12 Feb 2008 04:31:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=OZ6BYPysRViGx9smcGB1bwcYKfEIDOZo7qY7GXEn3E4=; b=nwgSZgi/LAaxXvtbSmOJ3Uv7KpSV/4jmUBuGjRXXYwwty4UvTKCn2VCwUbGNiu4vOg1P+YpeidEndx1gOXt3pSvkUWQYEKIBEvbn8vGVqGg6aGKjentdMvWVZOxQeZpb1ic8glb5ESItATUGcP+LDfSWZFgzyz6Aetn/AfOil/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=K6tAd4u+6XAafcryGFKj2qMj6jj3YxGAa0uy/MyTlCRuv5inmDc5ylyE9NM28MG38rj/bnbkpf2Vm8YnumjD461sVLpupYIED7rk3asNwFu3elrgPvr715kouCUlElW1GAirZ8H4s7/1gwDAvvfIY11LmZVRUzqDkm6D0+fh/Lg= Message-ID: Date: Mon, 11 Feb 2008 23:30:50 -0500 From: "Greg Weber" To: radiusext@ops.ietf.org Subject: LC cmts: Extended Attrs MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have some comments on: draft-ietf-radext-extended-attributes-00.txt * In section 5, the Ext-Length field is defined as the length of the Extended Attribute. I think you mean it's the length of the TLV (multiple TLVs can be in the Extended Attribute). I think that would make the value ">=3", not ">=4". * It's probably worth calling out any artifacts of overloading attribute 26 which wouldn't apply to standard attributes in the original number space (or apply to overloading a new attribute instead of 26). For example, attribute 26 is already specifically excluded from some RADIUS message types, e.g. CoA-NAK, so new Extended Attributes couldn't be included in those messages, but new standard attribute could be. Also, are malformed VSAs always treated just like malformed non-VSAs? * I think it would be useful to explicitly mention if recursive grouping is allowed and that Extended Attributes cannot be grouped with non-Extended Attributes. * It's probably useful to mention what happens when an Extended Attribute's tag is non-zero and it contains multiple TLVs (this does not seem to be excluded -as multiple TLVs are when the M-bit is on). * RFC2865 specifically calls out the proxies can't reorder attributes of the same type; does this doc need to create the same restriction for Ext-Type? * I actually didn't have a lot of editorial comments :-) Possibly the M-bit could be renamed to avoid potential confusion with Diameter. Greg On Feb 10, 2008 3:50 PM, Bernard Aboba wrote: > > This is a reminder of the ongoing RADEXT WG last call on the Extended > RADIUS Attributes document, prior to sending it to the IESG for > consideration as a Proposed Standard. The document is available for > inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00.txt > > RADEXT WG last call will last until February 14, 2008. Please send comments > to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format > described on the RADEXT WG Issues page: > http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 12 Feb 2008 02:25:33 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Stefan Winter'" , Subject: RE: request to recharter Date: Mon, 11 Feb 2008 18:24:59 -0800 Message-ID: <00a601c86d1e$807a8a20$aedd787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AchtHUWlUay6LIOYRjOpYYiiBPXpigAAKw/Q Bernard Aboba <> scribbled on Monday, February 11, 2008 6:13 PM: >> Yes, there has been a popular upswell of support for abandoning our >> work in favor of yours -- oh, wait, that would be you again... > > [BA] Completion of the existing RADEXT WG work items has always been a > precondition for re-chartering. There has never been a discussion of > "abandoning" existing work items. I didn't say "work items", I said "work", meaning RADIUS. This is a new & different protocol, more akin to Diameter than RADIUS & does not belong in this WG. > Once the Design Guidelines, > Management Attributes and Extended Attributes documents complete WG > last call and are forwarded to the IESG, the remaining work items > left will be the IEEE 802 attributes document, and the Crypto-agility > draft. > > At that point a discussion of Re-Chartering would be appropriate. > >> No, no, NO! "radsec" is not RADIUS, period. Not an extension, not >> even a perversion, not RADIUS. I would support a radsec BOF & WG, >> but I will not support this. > > [BA] The IETF process involves "rough consensus and running code". > During the RADEXT WG re-charter discussion, the opinion of all WG > participants will be taken into account. > > With respect to RADSEC, the minutes of IETF 69 show that as part of > the crypto-agility portion of the meeting, there was a consensus call > on > potential solutions, and that RADSEC got considerable support. > We did not follow up with a consensus call on the list since > RADSEC was outside the RADEXT WG charter. However, > during a re-charter discussion, this and other potential WG work > items will be open to discussion. Fine, just change the WG name "radsec" as well. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 12 Feb 2008 02:13:20 +0000 Message-ID: From: "Bernard Aboba" To: "'Stefan Winter'" , Subject: Re: request to recharter Date: Mon, 11 Feb 2008 18:12:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > Yes, there has been a popular upswell of support for abandoning our work > in favor of yours -- oh, wait, that would be you again... [BA] Completion of the existing RADEXT WG work items has always been a precondition for re-chartering. There has never been a discussion of "abandoning" existing work items. Once the Design Guidelines, Management Attributes and Extended Attributes documents complete WG last call and are forwarded to the IESG, the remaining work items left will be the IEEE 802 attributes document, and the Crypto-agility draft. At that point a discussion of Re-Chartering would be appropriate. > No, no, NO! "radsec" is not RADIUS, period. Not an extension, not even > a perversion, not RADIUS. I would support a radsec BOF & WG, but I will > not support this. [BA] The IETF process involves "rough consensus and running code". During the RADEXT WG re-charter discussion, the opinion of all WG participants will be taken into account. With respect to RADSEC, the minutes of IETF 69 show that as part of the crypto-agility portion of the meeting, there was a consensus call on potential solutions, and that RADSEC got considerable support. We did not follow up with a consensus call on the list since RADSEC was outside the RADEXT WG charter. However, during a re-charter discussion, this and other potential WG work items will be open to discussion. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 12 Feb 2008 01:05:07 +0000 From: "Glen Zorn" To: "'Stefan Winter'" , Subject: RE: request to recharter Date: Tue, 12 Feb 2008 08:03:49 +0700 Message-ID: <008b01c86d13$290663f0$aedd787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AchsmO0sxJh8DZt2QmSwaf2B7i/MqgAeHcSA Stefan Winter <> scribbled on Monday, February 11, 2008 5:26 PM: > Hello, > > the topic of re-chartering radiusext to accomodate the RadSec work > has been a continuous topic in the last two meetings, the mailing > list and in several offline discussions. Yes, there has been a popular upswell of support for abandoning our work in favor of yours -- oh, wait, that would be you alone... > The last meeting in Vancouver suggested to move the three most > promising crypto-agility suggestions (keywrap, dtls, radsec) to EXP > status within radext. > RadSec is being implemented in various independent codebases and is > in production use today. > > The points above make me think that it is about time to seriously > consider that the radext charter is modified to include RadSec into > the working group scope. Yes, there has been a popular upswell of support for abandoning our work in favor of yours -- oh, wait, that would be you again... > > The DTLS draft led to consensus that TLS-style payload encryption is > not considered being a new security mechanism for protecting RADIUS > (which would be excluded by the charter as-is). Then, the same holds > true for the TLS part of the radsec draft, which in turn means this > part of the charter does not need changing. > > The only part in the charter that would need to be changed is, > obviously, the line > > "- No new RADIUS transports (e.g. TCP, SCTP) will be defined." > > which I request to purge from the charter. No, no, NO! "radsec" is not RADIUS, period. Not an extension, not even a perversion, not RADIUS. I would support a radsec BOF & WG, but I will not support this. > > After being included in the radext WG scope, the radsec draft would > certainly be rewritten for more normative wording. Because up to now, > it was meant as an FYI description of existing implementations, not > in any way a standard. > When EXP is a target, language should change accordingly. I volunteer > to do this to the best of my knowledge - it is my first I-D at all. > > Greetings, > > Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 11 Feb 2008 10:37:21 +0000 From: Stefan Winter Organization: Fondation RESTENA To: Bernard Aboba Subject: Re: draft-winter-radsec-01 published Date: Mon, 11 Feb 2008 11:37:04 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Alan DeKok , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1509223.T8BsIcjxoV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802111137.05160.stefan.winter@restena.lu> --nextPart1509223.T8BsIcjxoV Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > As I don't use RADIUS-over-IPSec myself, I asked one of our national > eduroam operators for his practical experiences in that respect. I'll keep > you posted. I got: "I've seen fragmentation problems on IPsec only once, and that quite long ago so I can't recall more info than it was related to CISCO PIX FW in situation when we were using both AH and ESP headers. After droping AH it started working reliably. That time I realized that AH headers are not necessary and now we are using only ESP. [...] I'm doing from time to time test with big EAP requests to be sure that our Czech eduroam is running on correctly setup network. When I discover problem I ask admins to fix that. So far I never had to disconnect anyone for this incompatibility." Which looks like forcing admins to tweak stuff until it works. Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart1509223.T8BsIcjxoV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHsCVR+jm90f8eFWYRAptbAJ48ldtV4EjKyllBu2KNtG8phyEC/QCeIBiM s6KctBCciclNz7bwIFcJUro= =9urz -----END PGP SIGNATURE----- --nextPart1509223.T8BsIcjxoV-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 11 Feb 2008 10:26:36 +0000 From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org Subject: request to recharter Date: Mon, 11 Feb 2008 11:26:25 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2525371.U1nnMiPe13"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802111126.25340.stefan.winter@restena.lu> --nextPart2525371.U1nnMiPe13 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, the topic of re-chartering radiusext to accomodate the RadSec work has been= a=20 continuous topic in the last two meetings, the mailing list and in several= =20 offline discussions. The last meeting in Vancouver suggested to move the three most promising=20 crypto-agility suggestions (keywrap, dtls, radsec) to EXP status within=20 radext. RadSec is being implemented in various independent codebases and is in=20 production use today. The points above make me think that it is about time to seriously consider= =20 that the radext charter is modified to include RadSec into the working grou= p=20 scope. The DTLS draft led to consensus that TLS-style payload encryption is not=20 considered being a new security mechanism for protecting RADIUS (which woul= d=20 be excluded by the charter as-is). Then, the same holds true for the TLS pa= rt=20 of the radsec draft, which in turn means this part of the charter does not= =20 need changing. The only part in the charter that would need to be changed is, obviously, t= he=20 line "- No new RADIUS transports (e.g. TCP, SCTP) will be defined." which I request to purge from the charter. After being included in the radext WG scope, the radsec draft would certain= ly=20 be rewritten for more normative wording. Because up to now, it was meant as= =20 an FYI description of existing implementations, not in any way a standard.= =20 When EXP is a target, language should change accordingly. I volunteer to do= =20 this to the best of my knowledge - it is my first I-D at all. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart2525371.U1nnMiPe13 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHsCLR+jm90f8eFWYRAlIYAJ0cwdUYqMqNM2Mnt821y/veSM9SewCfdjnh vmxO0DOuKD0gmbJFBnrwKXU= =R8zv -----END PGP SIGNATURE----- --nextPart2525371.U1nnMiPe13-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 11 Feb 2008 10:25:08 +0000 From: Stefan Winter Organization: Fondation RESTENA To: Bernard Aboba Subject: Re: draft-winter-radsec-01 published Date: Mon, 11 Feb 2008 11:24:09 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Alan DeKok , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10647522.34XRZU3o58"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802111124.09919.stefan.winter@restena.lu> --nextPart10647522.34XRZU3o58 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > To be clear, this fragmentation issue is a problem for RADIUS, but not > RADSEC, correct? I'd assume that TCP MSS negotiation combined with > Packetization Layer Path MTU discovery should make fragmentation of TCP > segments relatively unlikely. That is correct, a reliable transport makes this problem go away, or at lea= st=20 makes life a lot easier in that respect. Still, even though I'm quite=20 enthusiastic about RadSec, I can still imagine people using just plain RADI= US=20 who suffer from that problem. > BTW, how does IPsec solve the fragmentation problem for RADIUS? Couldn't > it make it worse? As I don't use RADIUS-over-IPSec myself, I asked one of our national eduroa= m=20 operators for his practical experiences in that respect. I'll keep you=20 posted. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart10647522.34XRZU3o58 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHsCJJ+jm90f8eFWYRArQBAJ9piHxogql8ZyjPxzQ9bILKn7//OwCeOLS7 VERHiTRVj7YK9a0oevAr0bk= =Tyfc -----END PGP SIGNATURE----- --nextPart10647522.34XRZU3o58-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 10 Feb 2008 20:50:44 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_9e27425a-f09b-415e-8201-cabdf6471a42_" From: Bernard Aboba To: Subject: REMINDER: Ongoing RADEXT WG last call on the Extended RADIUS Attributes document Date: Sun, 10 Feb 2008 12:50:36 -0800 MIME-Version: 1.0 --_9e27425a-f09b-415e-8201-cabdf6471a42_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a reminder of the ongoing RADEXT WG last call on the Extended RADIU= S Attributes document, prior to sending it to the IESG for consideration as a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-0= 0.txt RADEXT WG last call will last until February 14, 2008. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/= --_9e27425a-f09b-415e-8201-cabdf6471a42_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a reminder of the ongoing RADEXT WG last call on the Extended RADIU= S Attributes document, prior to sending it to the IESG for consideration as a Proposed Standard.   The document is available for inspectio= n here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-a= ttributes-00.txt

RADEXT WG last call will last until February 14, 2008.  Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RA= DEXT/ = --_9e27425a-f09b-415e-8201-cabdf6471a42_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 10 Feb 2008 20:46:27 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_d08605a4-ce3b-4a52-bd70-e9d3530fdd11_" From: Bernard Aboba To: Alan DeKok , 'radext mailing list' Subject: RE: Review of RADIUS Design Guidelines document Date: Sun, 10 Feb 2008 12:45:46 -0800 MIME-Version: 1.0 --_d08605a4-ce3b-4a52-bd70-e9d3530fdd11_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Hmm... I'm trying to come up with something that the WG could agree > with, but which isn't banal to the point of being meaningless. >=20 > The comments about the State attribute are a good start. =20 [BA] Yes, because they relate to fundamental assumptions of the protocol de= sign.=20 > Other points are: >=20 > - RADIUS is a transport protocol for authentication credentials, > authorization information, and accounting data for user sessions [BA] Is this implying a requirement for a user session to be in progress at a NAS that originates a request? Or is it a statement relating to=20 the kinds of purposes for which attributes can be used?=20 > - authorization is possible only after a session has been successfully > authenticated [BA] Is this a statement about what messages authorizations can be included within (e.g. Access-Reject or Access-Challenge messages)? > - the protocol is "hop by hop", and not "end to end" [BA] There are protocol elements (e.g. NAS-Identifier, NAS-IP-Address, NAS-IPv6-Address) that refer to the original NAS. However, other fields (Message-Authenticator, Proxy-State, Authenticator field) are recalculated = by=20 intermediate nodes. How should specifications think about these distinctions? =20 > - all data transported by RADIUS is visible to all intermediate nodes [BA] Is this a design principle, or just a statement of how things currentl= y work?=20 > - authentication servers do not have to be co-located with accounting > servers > - no action may be taken on Access-Reject other than disconnecting the > user session that was attempting authentication > - no information may be sent in an Accounting-Response > - Any PDU may not reach it's intended destination. Implementations > should be robust in the event of lost, missing, or incomplete information [BA] These seem reasonable.=20 >=20 > Suggestions for more? [BA] It might be worth saying that RADIUS attribute specifications do not d= efine services, they describe how services that have already been defined should be provisioned.=20 >=20 > > Given the concern about SHA-1 collisions, is it worth recommending > > against use of this algorithm in new attributes? >=20 > Yes. >=20 > > I also something might be worth saying about the use of RADIUS without > > user authentication. >=20 > This can be mentioned as part of the set of assumptions. >=20 > > Section 1 > >=20 > > Suggest changing: ... To: ... >=20 > Looks good to me. >=20 >=20 > > Section 5 > >=20 > > Suggest changing ... To: ... >=20 > Looks good to me. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --_d08605a4-ce3b-4a52-bd70-e9d3530fdd11_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  > Hmm... I'm trying to come up with something that the WG could = agree
> with, but which isn't banal to the point of being meaningless= .
>
> The comments about the State attribute are a good star= t.

[BA] Yes, because they relate to fundamental assumptions of the= protocol design.

> Other points are:
>
> - RADIUS= is a transport protocol for authentication credentials,
> authorizat= ion information, and accounting data for user sessions

[BA]  Is= this implying a requirement for a user session to be in progress
at a N= AS that originates a request?  Or is it a statement relating to
th= e kinds of purposes for which attributes can be used?

> - autho= rization is possible only after a session has been successfully
> aut= henticated

[BA] Is this a statement about what messages authorizatio= ns can be
included within (e.g. Access-Reject or Access-Challenge messag= es)?

> - the protocol is "hop by hop", and not "end to end"
<= br>[BA]  There are protocol elements (e.g. NAS-Identifier, NAS-IP-Addr= ess,
NAS-IPv6-Address) that refer to the original NAS.  However, ot= her fields
(Message-Authenticator, Proxy-State, Authenticator field) are= recalculated by
intermediate nodes.  How should specifications th= ink about these
distinctions? 

> - all data transported= by RADIUS is visible to all intermediate nodes

[BA] Is this a desig= n principle, or just a statement of how things currently
work?

&= gt; - authentication servers do not have to be co-located with accounting<= br>> servers
> - no action may be taken on Access-Reject other th= an disconnecting the
> user session that was attempting authenticatio= n
> - no information may be sent in an Accounting-Response
> = - Any PDU may not reach it's intended destination. Implementations
>= should be robust in the event of lost, missing, or incomplete information<= br>
[BA] These seem reasonable.

>
> Suggestions for = more?

[BA] It might be worth saying that RADIUS attribute specificat= ions do not define
services, they describe how services that have alread= y been defined should
be provisioned.

>
> > Given t= he concern about SHA-1 collisions, is it worth recommending
> > ag= ainst use of this algorithm in new attributes?
>
> Yes.
&= gt;
> > I also something might be worth saying about the use of R= ADIUS without
> > user authentication.
>
> This can= be mentioned as part of the set of assumptions.
>
> > Sect= ion 1
> >
> > Suggest changing: ... To: ...
>
= > Looks good to me.
>
>
> > Section 5
> &= gt;
> > Suggest changing ... To: ...
>
> Looks goo= d to me.
>
> Alan DeKok.
>
> --
> to unsu= bscribe send a message to radiusext-request@ops.ietf.org with
> the w= ord 'unsubscribe' in a single line as the message text body.
> archiv= e: <http://psg.com/lists/radiusext/>
= --_d08605a4-ce3b-4a52-bd70-e9d3530fdd11_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 09 Feb 2008 08:02:31 +0000 Message-ID: <47AD5D3A.8040806@nitros9.org> Date: Sat, 09 Feb 2008 08:58:50 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: "David B. Nelson" , Stefan Winter , radiusext@ops.ietf.org Subject: Re: draft-winter-radsec-01 published Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > To even know whether the packets are IPsec/IKE, it would be necessary to > reassemble them. So > I don't see how they could be treated differently. They won't. But administrators can lower the MTU for IPSec connections until it "just works". At that point, protocols transported inside of IPSec are fine. This can't be done on the supplicant, because it only sees it's local MTU. There is no feedback mechanism to lower this MTU to account for later RADIUS encapsulation. The IPSec solution is less about automated path MTU discovery than administrator trial and error until "it seems to work". Adding a feedback mechanism to EAP for MTU could be useful. The only reasonable place to put this information is in the first packet sent by the EAP server. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 16:09:52 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_817f26f1-f645-4f53-a413-c327529cae9d_" From: Bernard Aboba To: "David B. Nelson" CC: Alan DeKok , Stefan Winter , Alan DeKok , Subject: RE: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 08:09:07 -0800 MIME-Version: 1.0 --_817f26f1-f645-4f53-a413-c327529cae9d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To even know whether the packets are IPsec/IKE, it would be necessary to re= assemble them. So I don't see how they could be treated differently.=20 > Date: Fri, 8 Feb 2008 09:30:33 -0500 > From: dnelson@elbrysnetworks.com > To: bernard_aboba@hotmail.com > CC: aland@deployingradius.com; stefan.winter@restena.lu; aland@nitros9.or= g; radiusext@ops.ietf.org > Subject: Re: draft-winter-radsec-01 published >=20 > Bernard Aboba wrote: >=20 > > BTW, how does IPsec solve the fragmentation problem for RADIUS? >=20 > Maybe it prevents the "broken" firewalls from peeking into the packets,=20 > seeing UDP fragments, and dropping them. They skate by via means of an=20 > IPsec pass through feature. Just a guess. >=20 --_817f26f1-f645-4f53-a413-c327529cae9d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To even know whet= her the packets are IPsec/IKE, it would be necessary to reassemble them.&nb= sp; So
I don't see how they could be treated differently.
> Date: Fri, 8 Feb 2008 09:30:33 -0500
> From: dnelson@elbrysnetw= orks.com
> To: bernard_aboba@hotmail.com
> CC: aland@deployingr= adius.com; stefan.winter@restena.lu; aland@nitros9.org; radiusext@ops.ietf.= org
> Subject: Re: draft-winter-radsec-01 published
>
> = Bernard Aboba wrote:
>
> > BTW, how does IPsec solve the fr= agmentation problem for RADIUS?
>
> Maybe it prevents the "bro= ken" firewalls from peeking into the packets,
> seeing UDP fragments= , and dropping them. They skate by via means of an
> IPsec pass thr= ough feature. Just a guess.
>
= --_817f26f1-f645-4f53-a413-c327529cae9d_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 14:30:49 +0000 Message-ID: <47AC6789.4050002@elbrysnetworks.com> Date: Fri, 08 Feb 2008 09:30:33 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba CC: Alan DeKok , Stefan Winter , Alan DeKok , radiusext@ops.ietf.org Subject: Re: draft-winter-radsec-01 published Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > BTW, how does IPsec solve the fragmentation problem for RADIUS? Maybe it prevents the "broken" firewalls from peeking into the packets, seeing UDP fragments, and dropping them. They skate by via means of an IPsec pass through feature. Just a guess. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 14:16:27 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_4297b688-cf14-44be-9ee3-38f1a9d3f748_" From: Bernard Aboba To: Alan DeKok , Stefan Winter CC: Alan DeKok , Subject: RE: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 06:15:44 -0800 MIME-Version: 1.0 --_4297b688-cf14-44be-9ee3-38f1a9d3f748_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To be clear, this fragmentation issue is a problem for RADIUS, but not RADS= EC, correct?=20 I'd assume that TCP MSS negotiation combined with Packetization Layer Path = MTU discovery should make fragmentation of TCP segments relatively unlikely.=20 BTW, how does IPsec solve the fragmentation problem for RADIUS? Couldn't i= t make it worse?=20 > Date: Fri, 8 Feb 2008 11:23:05 +0100 > From: aland@deployingradius.com > To: stefan.winter@restena.lu > CC: aland@nitros9.org; radiusext@ops.ietf.org > Subject: Re: draft-winter-radsec-01 published >=20 > Stefan Winter wrote: > > The issue is more about the supplicant knowing its MTU, sending the max= imum=20 > > payload possible (typically, in EAP-TLS where the supplicant has a lot = to=20 > > say), the authenticator encapsulating that in a RADIUS packet, which gr= ows=20 > > larger than the MTU on its own uplink, leading to fragmentation of the = UDP=20 > > packet. >=20 > Ah. That's a completely separate problem. >=20 > > That is not in principle a problem, but practical experience has=20 > > shown that too many firewalls drop the fragments and auth doesn't work. >=20 > Broken firewalls are bad. Putting a firewall between a NAS and a > RADIUS server is generally not a good idea. Sending RADIUS over the > wider Internet isn't a good idea, unless encapsulation is used (IPSec, > etc.), which solves the UDP fragmentation problem. >=20 > > It would be desirable to be able to tell the supplicant that it should = send=20 > > *less* than its own MTU to prevent that from happening. >=20 > This is a path MTU discovery problem. It's hard. i.e. impossible, in > the general case. >=20 > > On the server side, EAP fragment size is statically configured, and is = often a=20 > > lot less than what supplicant could handle (1024 is a common default). = Thus,=20 > > sending less payload than would be possible means that a server has to = split=20 > > the EAP conversation in more RADIUS packets than need be, meaning more= =20 > > round-trips and longer time-to-auth.=20 >=20 > I'm not sure what else to say other than "Yes, that's life..." >=20 > I think it's a bad idea to add complexity to EAP in order to work > around firewall bugs. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --_4297b688-cf14-44be-9ee3-38f1a9d3f748_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To be clear, this= fragmentation issue is a problem for RADIUS, but not RADSEC, correct?
= I'd assume that TCP MSS negotiation combined with Packetization Layer Path = MTU discovery
should make fragmentation of TCP segments relatively unlik= ely.

BTW, how does IPsec solve the fragmentation problem for RADIUS= ?  Couldn't it make it worse?

> Date: Fri, 8 Feb 200= 8 11:23:05 +0100
> From: aland@deployingradius.com
> To: stefan= .winter@restena.lu
> CC: aland@nitros9.org; radiusext@ops.ietf.org> Subject: Re: draft-winter-radsec-01 published
>
> Stefan= Winter wrote:
> > The issue is more about the supplicant knowing = its MTU, sending the maximum
> > payload possible (typically, in = EAP-TLS where the supplicant has a lot to
> > say), the authentic= ator encapsulating that in a RADIUS packet, which grows
> > large= r than the MTU on its own uplink, leading to fragmentation of the UDP
&= gt; > packet.
>
> Ah. That's a completely separate probl= em.
>
> > That is not in principle a problem, but practical= experience has
> > shown that too many firewalls drop the fragme= nts and auth doesn't work.
>
> Broken firewalls are bad. Pu= tting a firewall between a NAS and a
> RADIUS server is generally not= a good idea. Sending RADIUS over the
> wider Internet isn't a good = idea, unless encapsulation is used (IPSec,
> etc.), which solves the = UDP fragmentation problem.
>
> > It would be desirable to b= e able to tell the supplicant that it should send
> > *less* than= its own MTU to prevent that from happening.
>
> This is a p= ath MTU discovery problem. It's hard. i.e. impossible, in
> the gen= eral case.
>
> > On the server side, EAP fragment size is s= tatically configured, and is often a
> > lot less than what suppl= icant could handle (1024 is a common default). Thus,
> > sending = less payload than would be possible means that a server has to split
&g= t; > the EAP conversation in more RADIUS packets than need be, meaning m= ore
> > round-trips and longer time-to-auth.
>
> = I'm not sure what else to say other than "Yes, that's life..."
>
= > I think it's a bad idea to add complexity to EAP in order to work> around firewall bugs.
>
> Alan DeKok.
>
>= --
> to unsubscribe send a message to radiusext-request@ops.ietf.org= with
> the word 'unsubscribe' in a single line as the message text b= ody.
> archive: <http://psg.com/lists/radiusext/>
= --_4297b688-cf14-44be-9ee3-38f1a9d3f748_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 10:41:55 +0000 From: Stefan Winter Organization: Fondation RESTENA To: Alan DeKok Subject: Re: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 11:41:28 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2407923.BYBiNbY0Af"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802081141.28282.stefan.winter@restena.lu> --nextPart2407923.BYBiNbY0Af Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > > On the server side, EAP fragment size is statically configured, and is > > often a lot less than what supplicant could handle (1024 is a common > > default). Thus, sending less payload than would be possible means that a > > server has to split the EAP conversation in more RADIUS packets than ne= ed > > be, meaning more round-trips and longer time-to-auth. > > I'm not sure what else to say other than "Yes, that's life..." The idea would be to make life better, if that's at all possible. Long=20 authentication time is bad. Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart2407923.BYBiNbY0Af Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHrDHY+jm90f8eFWYRApQCAJsEfg6uOe9rlDqO4ilL0HVIoExAAACfYtSE X5o3jCIqmDX/t8yblPwKgoU= =vj72 -----END PGP SIGNATURE----- --nextPart2407923.BYBiNbY0Af-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 10:26:01 +0000 Message-ID: <47AC2D89.1060604@deployingradius.com> Date: Fri, 08 Feb 2008 11:23:05 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Winter CC: Alan DeKok , radiusext@ops.ietf.org Subject: Re: draft-winter-radsec-01 published Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stefan Winter wrote: > The issue is more about the supplicant knowing its MTU, sending the maximum > payload possible (typically, in EAP-TLS where the supplicant has a lot to > say), the authenticator encapsulating that in a RADIUS packet, which grows > larger than the MTU on its own uplink, leading to fragmentation of the UDP > packet. Ah. That's a completely separate problem. > That is not in principle a problem, but practical experience has > shown that too many firewalls drop the fragments and auth doesn't work. Broken firewalls are bad. Putting a firewall between a NAS and a RADIUS server is generally not a good idea. Sending RADIUS over the wider Internet isn't a good idea, unless encapsulation is used (IPSec, etc.), which solves the UDP fragmentation problem. > It would be desirable to be able to tell the supplicant that it should send > *less* than its own MTU to prevent that from happening. This is a path MTU discovery problem. It's hard. i.e. impossible, in the general case. > On the server side, EAP fragment size is statically configured, and is often a > lot less than what supplicant could handle (1024 is a common default). Thus, > sending less payload than would be possible means that a server has to split > the EAP conversation in more RADIUS packets than need be, meaning more > round-trips and longer time-to-auth. I'm not sure what else to say other than "Yes, that's life..." I think it's a bad idea to add complexity to EAP in order to work around firewall bugs. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 10:15:17 +0000 From: Stefan Winter Organization: Fondation RESTENA To: Alan DeKok Subject: Re: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 11:14:57 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2848574.OIrO05vLX7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802081115.00527.stefan.winter@restena.lu> --nextPart2848574.OIrO05vLX7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > If the supplicant doesn't know what the local L2 MTU is, it's > completely broken. The issue is more about the supplicant knowing its MTU, sending the maximum= =20 payload possible (typically, in EAP-TLS where the supplicant has a lot to=20 say), the authenticator encapsulating that in a RADIUS packet, which grows= =20 larger than the MTU on its own uplink, leading to fragmentation of the UDP= =20 packet. That is not in principle a problem, but practical experience has=20 shown that too many firewalls drop the fragments and auth doesn't work. It would be desirable to be able to tell the supplicant that it should send= =20 *less* than its own MTU to prevent that from happening. On the server side, EAP fragment size is statically configured, and is ofte= n a=20 lot less than what supplicant could handle (1024 is a common default). Thus= ,=20 sending less payload than would be possible means that a server has to spli= t=20 the EAP conversation in more RADIUS packets than need be, meaning more=20 round-trips and longer time-to-auth.=20 greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart2848574.OIrO05vLX7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHrCuk+jm90f8eFWYRAsaGAKCFl3H7MUKkSLqQbvtgYbjWcjnrUACeNNh/ JVHHZ8/EPaCC1fM3PIiZO9w= =cvTG -----END PGP SIGNATURE----- --nextPart2848574.OIrO05vLX7-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 10:05:19 +0000 Message-ID: <47AC28B1.3030205@nitros9.org> Date: Fri, 08 Feb 2008 11:02:25 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Winter CC: Glen Zorn , radiusext@ops.ietf.org Subject: Re: draft-winter-radsec-01 published Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stefan Winter wrote: > I'm also about to write a draft for one of the EAP issues, about the problem > that it is sub-optimal to find out how much EAP payload exactly to put into a > RADIUS packet so that it doesn't fragment on the way but still fills the > available space. Currently, this is determined by guessing ? RFC 3579, Section 2.4 says that the NAS should Framed-MTU. All servers I know of use this to determine EAP payload. If the Framed-MTU isn't sent, then a "safe" assumption of normal Ethernet is used. i.e. eap_payload = Framed-MTU - eapol_header This calculation is extended to the contents of EAP types, by accounting for known, and fixed, EAP-type headers. > and > better-safe-than-sorry underestimations on the server side, and not at all > done on the supplicant side. ? If the supplicant doesn't know what the local L2 MTU is, it's completely broken. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 09:56:50 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 10:56:25 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6844755.QOo7syA114"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802081056.29687.stefan.winter@restena.lu> --nextPart6844755.QOo7syA114 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Are you planning to request a BOF slot in Philadephia? If not, I would > strongly encourage you to do so. It was considered, and I held a conf call with several ADs about it. The to= pic=20 would not be RadSec only, but also several other things about the use of=20 EAP/EAPoL in large federated roaming environments. Unfortunately, it is quite late to still do a well-prepared BOF for IETF71,= =20 and so it was suggested that I hold a "bar BoF", which I will do. As a matt= er=20 of fact, I'll be at the meeting the entire week, so there's plenty of time= =20 for discussion at any time. I'm also about to write a draft for one of the EAP issues, about the proble= m=20 that it is sub-optimal to find out how much EAP payload exactly to put into= a=20 RADIUS packet so that it doesn't fragment on the way but still fills the=20 available space. Currently, this is determined by guessing and=20 better-safe-than-sorry underestimations on the server side, and not at all= =20 done on the supplicant side. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart6844755.QOo7syA114 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHrCdN+jm90f8eFWYRAuKxAJ9GBwT8MvGfaTnYZO8NrrODRs0HNgCdFbFF UTVhEGOzE5oauH129NM0g8E= =7rpf -----END PGP SIGNATURE----- --nextPart6844755.QOo7syA114-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 09:37:39 +0000 From: "Glen Zorn" To: "'Stefan Winter'" Cc: Subject: RE: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 16:36:41 +0700 Message-ID: <006801c86a36$28c05250$5be2787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-index: AchqLeSE4G/aHf1ITWCA4y7YGjddJQACAxrg Are you planning to request a BOF slot in Philadephia? If not, I would strongly encourage you to do so. Stefan Winter <> scribbled on Friday, February 08, 2008 3:34 PM: > Hello, > > there is a new version of the RadSec draft available under > > http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt > > It contains the changes which were announced in IETF70 in Vancouver. > > The two main points are: > > - mention TLS with shared secrets as a possible means of establishing > the TLS tunnel (though no implementations currently offer that > option) > - The CA selection during the TLS handshake. This was presented in > the Vancouver meeting, but the problem has two sides: > server-to-client signalling of acceptable CAs can be signalled with > TLS 1.1, as presented in the Vancouver meeting. The other way round, > client-to-server signalling, is not possible with TLS 1.1. There is > ongoing work in the tls working group though, > http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-01.txt > , which will allow a Trusted CA indication later. A note that this > signalling is the suggested behaviour as soon as that draft is > ratified is added in the current radsec draft. > > Greetings, > > Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Feb 2008 08:34:46 +0000 From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org Subject: draft-winter-radsec-01 published Date: Fri, 8 Feb 2008 09:33:45 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3306979.0A814c2o6r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802080933.49040.stefan.winter@restena.lu> --nextPart3306979.0A814c2o6r Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, there is a new version of the RadSec draft available under http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt It contains the changes which were announced in IETF70 in Vancouver. The two main points are: =2D mention TLS with shared secrets as a possible means of establishing the= TLS=20 tunnel (though no implementations currently offer that option) =2D The CA selection during the TLS handshake. This was presented in the=20 Vancouver meeting, but the problem has two sides: server-to-client signalli= ng=20 of acceptable CAs can be signalled with TLS 1.1, as presented in the=20 Vancouver meeting. The other way round, client-to-server signalling, is not= =20 possible with TLS 1.1. There is ongoing work in the tls working group thoug= h,=20 http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-01.txt , whi= ch=20 will allow a Trusted CA indication later. A note that this signalling is th= e=20 suggested behaviour as soon as that draft is ratified is added in the curre= nt=20 radsec draft. Greetings, Stefan Winter =2D-=20 Stefan WINTER RESTENA Foundation - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education = Nationale et de=20 la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0=C2=A0+352= 424409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax:= =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart3306979.0A814c2o6r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHrBPt+jm90f8eFWYRAj6bAJ4hO7erD7hgFSQijMZWmeVlEDvD4wCeLKJz MvZyHyQYw5PReD+tUM8/7wQ= =XN1G -----END PGP SIGNATURE----- --nextPart3306979.0A814c2o6r-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Feb 2008 20:34:12 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_5468d955-92b5-40fb-8c7b-61ce6849ad02_" From: Bernard Aboba To: Subject: FW: Pending Errata for RADEXT documents Date: Mon, 4 Feb 2008 12:32:42 -0800 MIME-Version: 1.0 --_5468d955-92b5-40fb-8c7b-61ce6849ad02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI...> Date: Mon, 4 Feb 2008 11:40:25 +0100> From: dromasca@avaya.com> To:= radext-chairs@tools.ietf.org> CC: rbonica@juniper.net> Subject: Pending Er= rata for RADEXT documents> > RADEXT chairs,> > We are in the process of hel= ping the RFC Editor clean up the backlog of> unverified errata. There are a= number of such errata related to> documents issued by the RADEXT Working G= roup, which can be found at> http://www.rfc-editor.org/errata_list.php. > >= Specifically: > > | RFC4282 | 753 | 2006-08-14 | Frank Ellermann | radext = |> Technical | > | RFC4282 | 757 | 2005-12-13 | Peter Koch | radext |> Tech= nical | > | RFC4282 | 816 | 2005-12-18 | Alfred Hoenes | radext |> Technica= l | > | RFC4590 | 47 | 2006-09-21 | Alexander Schrab | radext |> Editorial = | > | RFC4668 | 29 | 2006-11-06 | Alfred Hoenes | radext |> Technical | > |= RFC4668 | 867 | 2006-11-06 | Alfred Hoenes | radext |> Editorial | > | RFC= 4668 | 884 | 2006-11-06 | Alfred Hoenes | radext |> Editorial | > | RFC4669= | 876 | 2006-11-06 | Alfred Hoenes | radext |> Editorial | > | RFC4670 | 2= 7 | 2006-11-06 | Alfred Hoenes | radext |> Technical | > | RFC4670 | 877 | = 2006-11-06 | Alfred Hoenes | radext |> Editorial | > | RFC4671 | 879 | 2006= -11-06 | Alfred Hoenes | radext |> Editorial | > | RFC4671 | 881 | 2006-11-= 06 | Alfred Hoenes | radext |> Editorial | > | RFC4671 | 882 | 2006-11-06 |= Alfred Hoenes | radext |> Editorial | > | RFC4673 | 891 | 2006-11-06 | Alf= red Hoenes | radext |> Editorial | > | RFC4675 | 24 | 2006-09-19 | Nikolai = Malykh | radext |> Editorial | > > Can you please have a look at these and = let us know what would be the> best process of verifying the accuracy of th= ese and approving what makes> sense. I would eliminate from start minor edi= torial issues that clearly> do not impact interoperability of the clarity o= f the secifications. > > Thanks and Regards,> > Dan> = --_5468d955-92b5-40fb-8c7b-61ce6849ad02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI...

> Date: Mon, 4 Feb 2008 11:40:25 +0100
> From: droma= sca@avaya.com
> To: radext-chairs@tools.ietf.org
> CC: rbonica@= juniper.net
> Subject: Pending Errata for RADEXT documents
> > RADEXT chairs,
>
> We are in the process of helping the= RFC Editor clean up the backlog of
> unverified errata. There are a = number of such errata related to
> documents issued by the RADEXT Wor= king Group, which can be found at
> http://www.rfc-editor.org/errata_= list.php.
>
> Specifically:
>
> | RFC4282 | 753= | 2006-08-14 | Frank Ellermann | radext |
> Technical |
> | R= FC4282 | 757 | 2005-12-13 | Peter Koch | radext |
> Technical |
&= gt; | RFC4282 | 816 | 2005-12-18 | Alfred Hoenes | radext |
> Technic= al |
> | RFC4590 | 47 | 2006-09-21 | Alexander Schrab | radext |
= > Editorial |
> | RFC4668 | 29 | 2006-11-06 | Alfred Hoenes | rad= ext |
> Technical |
> | RFC4668 | 867 | 2006-11-06 | Alfred Ho= enes | radext |
> Editorial |
> | RFC4668 | 884 | 2006-11-06 |= Alfred Hoenes | radext |
> Editorial |
> | RFC4669 | 876 | 20= 06-11-06 | Alfred Hoenes | radext |
> Editorial |
> | RFC4670 = | 27 | 2006-11-06 | Alfred Hoenes | radext |
> Technical |
> |= RFC4670 | 877 | 2006-11-06 | Alfred Hoenes | radext |
> Editorial | =
> | RFC4671 | 879 | 2006-11-06 | Alfred Hoenes | radext |
> Ed= itorial |
> | RFC4671 | 881 | 2006-11-06 | Alfred Hoenes | radext |<= BR>> Editorial |
> | RFC4671 | 882 | 2006-11-06 | Alfred Hoenes |= radext |
> Editorial |
> | RFC4673 | 891 | 2006-11-06 | Alfre= d Hoenes | radext |
> Editorial |
> | RFC4675 | 24 | 2006-09-1= 9 | Nikolai Malykh | radext |
> Editorial |
>
> Can you= please have a look at these and let us know what would be the
> best= process of verifying the accuracy of these and approving what makes
>= ; sense. I would eliminate from start minor editorial issues that clearly> do not impact interoperability of the clarity of the secifications. =
>
> Thanks and Regards,
>
> Dan
>
= --_5468d955-92b5-40fb-8c7b-61ce6849ad02_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 02 Feb 2008 05:48:53 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'radext mailing list'" Subject: RE: Question about RFC 2865 Date: Sat, 2 Feb 2008 12:47:18 +0700 Message-ID: <000001c8655f$1dd2c570$5601f00a@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Achj56XHPe3Ys+vzTMmwalvaeMVP6QBXvYMw Alan DeKok <> scribbled on Thursday, January 31, 2008 3:52 PM: > Section 5 (Attributes), page 25 says: > > ... > Value > > The Value field is zero or more octets and contains information > specific to the Attribute. > ... > > However, the following text defining type-specific formats does not > define any circumstance under which a Value field of zero octets is > permissible. Instead, the "string" and "text" types say: > > ...length zero (0) MUST NOT be sent; > omit the entire attribute instead. > > > This appears to be an inconsistency in the document. Is it a > problem? Probably. File an Errata w/the RFC Editor, I think. > > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 01 Feb 2008 01:25:11 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5176 on Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org Message-Id: <20080201012431.B67F010C7AD@bosco.isi.edu> Date: Thu, 31 Jan 2008 17:24:31 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5176 Title: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Author: M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba Status: Informational Date: January 2008 Mailbox: mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com, david@mitton.com, bernarda@microsoft.com Pages: 34 Characters: 79541 Obsoletes: RFC3576 See-Also: I-D Tag: draft-ietf-radext-rfc3576bis-13.txt URL: http://www.rfc-editor.org/rfc/rfc5176.txt This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community. This document is a product of the RADIUS EXTensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: