From owner-radiusext@ops.ietf.org Tue Apr 1 12:48: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 EA43C3A6D98 for ; Tue, 1 Apr 2008 12:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 CMrfmfPya22f for ; Tue, 1 Apr 2008 12:48:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5088828C61A for ; Tue, 1 Apr 2008 12:47:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JgmM5-000N0M-Ow for radiusext-data@psg.com; Tue, 01 Apr 2008 19:41:13 +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 1JgmLr-000Myc-Gy for radiusext@ops.ietf.org; Tue, 01 Apr 2008 19:41:04 +0000 Received: from BLU137-W48 ([65.55.162.188]) by blu139-omc3-s20.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Apr 2008 12:40:58 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3c05b5f9-ef01-411b-bfe3-fc22b7897dd4_" X-Originating-IP: [131.107.0.101] From: Bernard Aboba To: Subject: RADEXT WG re-charter Date: Tue, 1 Apr 2008 12:40:58 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2008 19:40:58.0495 (UTC) FILETIME=[4F0248F0:01C89430] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_3c05b5f9-ef01-411b-bfe3-fc22b7897dd4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. A st= rawman re-charter proposal is enclosed below. =20 Once comments from WG participants have been incorporated, we will begin a = formal WG consensus call on the proposed re-charter by the end of the month.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for=20 particular applications of authentication, authorization and=20 accounting such as NAS management and local area network (LAN) usage.=20 In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. =20 Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: =20 - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. =20 - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. =20 Work Items =20 The immediate goals of the RADEXT working group are to address the following issues: =20 - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. =20 - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP.=20 =20 -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. =20 -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20 relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. =20 - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. =20 - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. =20 Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC= --_3c05b5f9-ef01-411b-bfe3-fc22b7897dd4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. = A strawman re-charter proposal is enclosed below. 
Once comments from WG participants have been incorporated, we will begin a = formal WG consensus call on the proposed
re-charter by the end of the month.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Description of Working Group:
The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage.

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.
 

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:
 

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.
 

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
 

Work Items
 

The immediate goals of the RADEXT working group are to address the
following issues:
 

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.
 

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.
 

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.
 

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.
 

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.
 

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC<= BR> Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC draft submitted as an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC
 = --_3c05b5f9-ef01-411b-bfe3-fc22b7897dd4_-- -- 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 Apr 2 08:03: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 1268328C58E for ; Wed, 2 Apr 2008 08:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.324 X-Spam-Level: X-Spam-Status: No, score=0.324 tagged_above=-999 required=5 tests=[AWL=-1.098, 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 weVe8-g1V89F for ; Wed, 2 Apr 2008 08:03:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3750628C5C2 for ; Wed, 2 Apr 2008 08:02:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jh4Nj-000LM6-JX for radiusext-data@psg.com; Wed, 02 Apr 2008 14:56:07 +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 1Jh4Na-000LKR-Dn for radiusext@ops.ietf.org; Wed, 02 Apr 2008 14:56:02 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id 8av51Z0010cQ2SLA50Mk00; Wed, 02 Apr 2008 14:54:06 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id 8evk1Z00K24Kx1C8W00000; Wed, 02 Apr 2008 14:55:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=oUauNUO54RgXfi0pJKAA:9 a=2JFRK7dLvtvpmZJc8SHkt81BovgA:4 a=zoKOyUDlhksA:10 From: "David B. Nelson" To: References: Subject: RE: RADEXT WG re-charter Date: Wed, 2 Apr 2008 10:55:49 -0400 Message-ID: <039f01c894d1$a4aebd50$6401a8c0@NEWTON603> 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: AciUMQZLt2JWXcmmTKuI+NRYeHPQawAn/gww Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba writes... > As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. > A strawman re-charter proposal is enclosed below. Wow. Silence. I have to wonder if the RADEXT WG mailing list server is broken, or all the RADEXT WG members are on vacation. BTW, infer nothing from the date on which this message was issued. This is a serious proposal, not an April Fool's joke. :-) Discussion, please? -- 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 Apr 2 08:29:57 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 E2D3A3A6C24 for ; Wed, 2 Apr 2008 08:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 G4adHgIscU3I for ; Wed, 2 Apr 2008 08:29:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 031A53A6AA6 for ; Wed, 2 Apr 2008 08:29:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jh4r6-0001at-2v for radiusext-data@psg.com; Wed, 02 Apr 2008 15:26:28 +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 1Jh4r3-0001Zz-GN for radiusext@ops.ietf.org; Wed, 02 Apr 2008 15:26:26 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id E41C9A707E; Wed, 2 Apr 2008 08:26:20 -0700 (PDT) Message-ID: <47F3A4BC.9000008@nitros9.org> Date: Wed, 02 Apr 2008 17:22:36 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: RADEXT WG re-charter References: <039f01c894d1$a4aebd50$6401a8c0@NEWTON603> In-Reply-To: <039f01c894d1$a4aebd50$6401a8c0@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: > Discussion, please? The time frames look a little longer than "ideal". Given the past history of this WG, they should be fine. 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 Apr 4 00:47: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 B716228C242 for ; Fri, 4 Apr 2008 00:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 yLxn3La8zFyL for ; Fri, 4 Apr 2008 00:47:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A96A3A6BD1 for ; Fri, 4 Apr 2008 00:47:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhgX5-000Apk-4j for radiusext-data@psg.com; Fri, 04 Apr 2008 07:40:19 +0000 Received: from [158.64.1.34] (helo=smtp.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhgX2-000ApO-Gu for radiusext@ops.ietf.org; Fri, 04 Apr 2008 07:40:17 +0000 Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id F269A3027248 for ; Fri, 4 Apr 2008 09:40:14 +0200 (CEST) Received: from webmail.restena.lu (beren.restena.lu [158.64.1.20]) by smtp.restena.lu (Postfix) with ESMTP id E21673027247 for ; Fri, 4 Apr 2008 09:40:14 +0200 (CEST) Received: from 2001:4b88:108d:0:211:d8ff:fec5:6a6c ([2001:4b88:108d:0:211:d8ff:fec5:6a6c]) by webmail.restena.lu (Horde MIME library) with HTTP; Fri, 04 Apr 2008 09:40:14 +0200 Message-ID: <20080404094014.onnazg7rkc8g0cog@webmail.restena.lu> Date: Fri, 04 Apr 2008 09:40:14 +0200 From: stefan.winter@restena.lu To: radiusext@ops.ietf.org Subject: RE: RADEXT WG re-charter References: <039f01c894d1$a4aebd50$6401a8c0@NEWTON603> In-Reply-To: <039f01c894d1$a4aebd50$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk Hi, > Wow. Silence. I have to wonder if the RADEXT WG mailing list server is > broken, or all the RADEXT WG members are on vacation. BTW, infer nothing > from the date on which this message was issued. This is a serious > proposal, not an April Fool's joke. :-) > > Discussion, please? I'm on vacation indeed :-) The proposed text surpasses my expectations. I would have been fine with just taking out the one dash about no new transports. This new text also "fixes" the questions like "Why is DTLS not against the charter, being a new security mechanism?", which have been asked in the past several times, including at IETF-71. The new text has more "truth in advertising" in that respect. The proposed time frame of March 2009 looks plausible to me. 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 Apr 4 03:34: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 4E91F28C2ED for ; Fri, 4 Apr 2008 03:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 SwLhDsKUCe-9 for ; Fri, 4 Apr 2008 03:34:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E29EC3A6D59 for ; Fri, 4 Apr 2008 03:34:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhjCR-000CxS-PO for radiusext-data@psg.com; Fri, 04 Apr 2008 10:31:11 +0000 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhjCO-000Cww-0S for radiusext@ops.ietf.org; Fri, 04 Apr 2008 10:31:09 +0000 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 04 Apr 2008 03:31:07 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 03:31:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8963E.FC907E23" Subject: RE: RADEXT WG re-charter Date: Fri, 4 Apr 2008 06:30:24 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADEXT WG re-charter Thread-Index: AciUMMyP4/srMutaQdixNkO0vSekEACDJLtg References: From: "Stephen Hanna" To: "Bernard Aboba" , X-OriginalArrivalTime: 04 Apr 2008 10:31:06.0968 (UTC) FILETIME=[FDC40580:01C8963E] Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8963E.FC907E23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for taking a few days to respond. This looks like a good proposal to me. =20 One nit. The milestone for Extended Attributes says "RC" instead of RFC. =20 Thanks, =20 Steve ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, April 01, 2008 3:41 PM To: radiusext@ops.ietf.org Subject: RADEXT WG re-charter As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. A strawman re-charter proposal is enclosed below. =20 Once comments from WG participants have been incorporated, we will begin a formal WG consensus call on the proposed re-charter by the end of the month.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for=20 particular applications of authentication, authorization and=20 accounting such as NAS management and local area network (LAN) usage.=20 In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. =20 Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: =20 - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. =20 - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. =20 Work Items =20 The immediate goals of the RADEXT working group are to address the following issues: =20 - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. =20 - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP.=20 =20 -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. =20 -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20 relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. =20 - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. =20 - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. =20 Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC ------_=_NextPart_001_01C8963E.FC907E23 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sorry for taking a few days to respond. This looks like = a good=20 proposal to me.
 
One nit. The milestone for Extended Attributes says "RC" = instead=20 of RFC.
 
Thanks,
 
Steve

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Tuesday, April 01, 2008 3:41 PM
To:=20 radiusext@ops.ietf.org
Subject: RADEXT WG=20 re-charter

As we discussed at IETF 71, the RADEXT WG is looking at a=20 re-charter.  A strawman re-charter proposal is enclosed = below. =20
Once comments from WG participants have been incorporated, we will = begin a=20 formal WG consensus call on the proposed
re-charter by the end of the = month.=20
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Description of Working Group:
The RADIUS Extensions Working = Group=20 will focus on extensions to the
RADIUS protocol required to define = extensions=20 to the standard
attribute space as well as to address cryptographic=20 algorithm
agility and use over new secure transports. In addition, = RADEXT=20 will
work on RADIUS Design Guidelines and define new attributes for=20
particular applications of authentication, authorization and =
accounting=20 such as NAS management and local area network (LAN) usage.

In = order to=20 enable interoperation of heterogeneous RADIUS/Diameter
deployments, = all=20 RADEXT WG work items MUST contain a Diameter
compatibility section, = outlining=20 how interoperability with
Diameter will be=20 maintained.
 

Furthermore, to ensure backward = compatibility with=20 existing RADIUS
implementations, as well as compatibility between = RADIUS and=20 Diameter,
the following restrictions are imposed on extensions = considered by=20 the
RADEXT WG:
 

- All RADIUS work MUST be backward = compatible=20 with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, = 3579, 3580,=20 4668-4673,
4675, 5080, 5090 and 5176.
 

- All RADIUS = work MUST=20 be compatible with equivalent facilities in
Diameter. Where possible, = new=20 attributes should be defined so that
the same attribute can be used = in both=20 RADIUS and Diameter without
translation. In other cases a translation = considerations
section should be included in the=20 specification.
 

Work Items
 

The = immediate goals=20 of the RADEXT working group are to address the
following=20 issues:
 

- RADIUS design guidelines. This document will = provide=20 guidelines for
design of RADIUS attributes. It will specifically = consider=20 how
complex data types may be introduced in a robust manner,=20 maintaining
backwards compatibility with existing RADIUS RFCs, across = all=20 the
classes of attributes: Standard, Vendor-Specific and = SDO-Specific.
In=20 addition, it will review RADIUS data types and associated
backwards=20 compatibility issues.
 
- RADIUS Management authorization. = This=20 document will define the
use of RADIUS for NAS management over IP.=20
 

-RADIUS attribute space extension. The standard RADIUS = attribute
space is currently being depleted. This document will=20 provide
additional standard attribute space, while maintaining=20 backward
compatibility with existing = attributes.
 

-RADIUS=20 Cryptographic Algorithm Agility. RADIUS has traditionally
relied on = MD5 for=20 both per-packet integrity and authentication as well
as attribute=20 confidentiality. Given the increasingly successful
attacks being = mounted=20 against MD5, the ability to support
alternative algorithms is = required. This=20 work item will
include documentation of RADIUS crypto-agility=20 requirements,
as well as development of one or more Experimental RFCs = providing
support for negotiation of alternative cryptographic=20 algorithms
to protect RADIUS.
 

- IEEE 802 attributes. = New=20 attributes have been proposed to
support IEEE 802 standards for wired = and=20 wireless LANs. This
work item will support authentication, = authorization=20 and
accounting attributes needed by IEEE 802 groups including
IEEE = 802.1,=20 IEEE 802.11 and IEEE 802.16.
 

- New RADIUS transports. = New=20 secure transports for RADIUS will
be developed, including TCP/TLS = (RADSEC)=20 and UDP/DTLS.

- Documentation of Status-Server usage. A=20 document
describing usage of the Status-Server facility will=20 be
developed.
 

Goals and Milestones:
Jun 2008 = RADIUS=20 Design Guidelines submitted as a Best Current Practice RFC
Jun 2008 = RADIUS=20 Management Authorization I-D submitted as a Proposed Standard RFC
Sep = 2008=20 RADIUS Crypto-agility Requirements submitted as an Informational = RFC
Sep 2008=20 Extended Attributes I-D submitted as a Proposed Standard RC
Dec 2008 = IEEE 802=20 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 = Status-Server=20 I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC draft = submitted as=20 an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an=20 Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D = submitted as an Experimental RFC
------_=_NextPart_001_01C8963E.FC907E23-- -- 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 Apr 4 11:53:37 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 33B8328C464 for ; Fri, 4 Apr 2008 11:53:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.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 QdT2-jU2FY1H for ; Fri, 4 Apr 2008 11:53:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A68928C4A4 for ; Fri, 4 Apr 2008 11:53:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhqvY-000FCD-2T for radiusext-data@psg.com; Fri, 04 Apr 2008 18:46:16 +0000 Received: from [65.54.246.89] (helo=bay0-omc1-s17.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhqvV-000FBo-JH for radiusext@ops.ietf.org; Fri, 04 Apr 2008 18:46:14 +0000 Received: from hotmail.com ([10.4.31.17]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 11:46:13 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 4 Apr 2008 11:46:12 -0700 Message-ID: Received: from 131.107.0.105 by BLU137-DAV7.phx.gbl with DAV; Fri, 04 Apr 2008 18:46:11 +0000 X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'David B. Nelson'" , Cc: "'David Harrington'" , "'Jeffrey Hutzelman'" , References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2><017101c89464$6d185210$0600a8c0@china.huawei.com><038f01c894cb$7cbc5b50$6401a8c0@NEWTON603><020401c894df$ddb391d0$0600a8c0@china.huawei.com><00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> <002301c8966d$998dd530$1f0a0a0a@xpsuperdvd2> In-Reply-To: <002301c8966d$998dd530$1f0a0a0a@xpsuperdvd2> Subject: RE: [Isms] What granularity of attributes do we need for the secure transport? Date: Fri, 4 Apr 2008 11:46:11 -0700 Message-ID: <000f01c89684$2704bad0$750e3070$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciWXb72aIumfr7ySgavZNRm18UwfAABfApQAAGnR7AABiAO4A== Content-Language: en-us X-OriginalArrivalTime: 04 Apr 2008 18:46:12.0612 (UTC) FILETIME=[27B59440:01C89684] Sender: owner-radiusext@ops.ietf.org Precedence: bulk David Nelson spoke thusly: "My question is whether this sort of configuration of the secure transport protocol is something that needs to be checked by the NAS, using differing criteria, on each and every user authentication? I think that granularity of configuration is generally handled by, well... configuration, and not handled as part of user authorization." With respect to IEEE 802.11 access, there are no RADIUS attributes that specify whether a given user is allowed to do WEP/WPA/WPA2. It is assumed that security is negotiated between the AP and STA based on their configuration. This seems to work OK, particularly since separate SSIDs are typically provisioned for each supported security mechanism, so that user authorization can be handled based on the SSID (provided in the Called-Station-Id). A similar approach might well work here -- we assume that the NAS is set up to allow/require various security mechanisms. It might be useful for the NAS to tell the RADIUS server what security mechanism has been negotiated, and the RADIUS server might Accept/Reject the authentication based on that information as well as the user-name. But there is no notion that the RADIUS server can exercise *control* over what is negotiated -- it is "here is what I'm doing, take it or leave it". -- 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 Apr 4 12:04: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 D2FB33A6FDA for ; Fri, 4 Apr 2008 12:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 1C0hmr9S8J1w for ; Fri, 4 Apr 2008 12:04:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD2DB28C757 for ; Fri, 4 Apr 2008 12:03:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jhr7u-000H6f-HQ for radiusext-data@psg.com; Fri, 04 Apr 2008 18:59:02 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jhr7r-000H63-Fp for radiusext@ops.ietf.org; Fri, 04 Apr 2008 18:59:01 +0000 Received: (qmail 3122 invoked from network); 4 Apr 2008 14:58:58 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 4 Apr 2008 14:58:58 -0400 From: "David B. Nelson" To: Subject: FW: [Isms] What granularity of attributes do we need for the secure transport? Date: Fri, 4 Apr 2008 14:56:49 -0400 Organization: Elbrys Networks, Inc. Message-ID: <002d01c89685$a3a649e0$1f0a0a0a@xpsuperdvd2> 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: AciWeRBg/P7z/v4TRjSCSwEE+iDxZAAAYdLwAAAep4AAAnla8A== Sender: owner-radiusext@ops.ietf.org Precedence: bulk There is a discussion going on currently in the ISMS WG with regard to authorization and/or provisioning of management access to a NAS, specifically with respect to the security properties of the transport protocol (for remote management). Some of this discussion has been specific to SNMP and the ISMS work, but some is more generally related to NAS management authorization. I'll forward (cross-post) those messages of general interest to RADEXT. You may also review the ISMS WG mailing list archives for additional information. > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of > David B. Nelson > Sent: Friday, April 04, 2008 1:57 PM > To: isms@ietf.org > Subject: Re: [Isms] What granularity of attributes do we need for the > secure transport? > > David Harrington writes... > > > I do not believe we need to provision the security protocol; ... > > Meaning we don't need to specify such things as the selection of optional > modes, cipher suite, authentication mechanism, certificate chains, and so > forth. Right? > > > I think we should allow an operator to decide which secure transport > > they want to require as a condition of granting access to the SNMP > > service. > > Just the transport protocol name? Or do you want to sub-specify versions, > e.g. SSHv2, TLSv1? If you want to specify IPsec as one of these, do you > need to specify such things as IKEv2? > > I think the devil is in the details. > > If I understand your position correctly, to want to augment the existing > Management-Protocol-Protection attribute, which specifies the level of > security in an abstract fashion, with a reinstated > Management-Transport-Protocol attribute which names the mandated protocol > (and maybe the protocol version). Right? Do you anticipate that there > could be only one of these attributes in a RADIUS Access-Accept message, > or could there be more than one (i.e. acceptable alternatives)? > > That seems to be a middle ground choice, between having only an abstract > assertion about the security level and having all the details and > parameters > related to a secure transport protocol. > > What do others think about this decision point? > > -- Do we need only an abstract security level assertion? > > -- Do we need the transport protocol name? > > -- Do we need the transport protocol version? > > -- Do we need any further details of security parameters? > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms -- 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 Apr 4 12:04:47 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 1F3EA3A6FB1 for ; Fri, 4 Apr 2008 12:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=-0.334, 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 RFeNvgk89eZX for ; Fri, 4 Apr 2008 12:04:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2DD13A6FBC for ; Fri, 4 Apr 2008 12:03:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jhr8v-000HFZ-Mg for radiusext-data@psg.com; Fri, 04 Apr 2008 19:00:05 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jhr8s-000HEe-IG for radiusext@ops.ietf.org; Fri, 04 Apr 2008 19:00:04 +0000 Received: (qmail 3179 invoked from network); 4 Apr 2008 15:00:01 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 4 Apr 2008 15:00:01 -0400 From: "David B. Nelson" To: Subject: FW: [Isms] What granularity of attributes do we need for the secure transport? Date: Fri, 4 Apr 2008 14:57:53 -0400 Organization: Elbrys Networks, Inc. Message-ID: <002e01c89685$c9906780$1f0a0a0a@xpsuperdvd2> 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: AciWhDpr2rSN4pDwTsGIDg8/QH3aEgAAW0kw Sender: owner-radiusext@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, April 04, 2008 2:47 PM > To: David B. Nelson > Cc: isms@ietf.org > Subject: Re: [Isms] What granularity of attributes do we need for > the secure transport? > > On Fri, Apr 04, 2008 at 01:57:27PM -0400, David B. Nelson wrote: > > > What do others think about this decision point? > > > > -- Do we need only an abstract security level assertion? > > > > -- Do we need the transport protocol name? > > > > -- Do we need the transport protocol version? > > > > -- Do we need any further details of security parameters? > > As technical contributor, I like the abstract security level > assertion. More granular control can be achieved by means of > configuration of the SNMP engine or secure transport protocol. > > /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 Fri Apr 4 15:34: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 596CF28C328 for ; Fri, 4 Apr 2008 15:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.494 X-Spam-Level: X-Spam-Status: No, score=-8.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 cGS5ri9i9b0n for ; Fri, 4 Apr 2008 15:34:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB59F3A6C59 for ; Fri, 4 Apr 2008 15:34:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhuRH-000M7E-N3 for radiusext-data@psg.com; Fri, 04 Apr 2008 22:31:15 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhuRE-000M6m-QM for radiusext@ops.ietf.org; Fri, 04 Apr 2008 22:31:14 +0000 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.54.46.187) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 4 Apr 2008 15:31:12 -0700 Received: from NA-EXMSG-C114.redmond.corp.microsoft.com ([157.54.62.169]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.54.46.187]) with mapi; Fri, 4 Apr 2008 15:31:12 -0700 From: Mudit Goel To: Bernard Aboba , "radiusext@ops.ietf.org" Date: Fri, 4 Apr 2008 15:31:05 -0700 Subject: RE: RADEXT WG re-charter Thread-Topic: RADEXT WG re-charter Thread-Index: AciUMOKl93N4MjNVTAGZfkKjaBRf0QCcYLBQ Message-ID: <456A5146F9319946A179B523B9FC91D60D9E4E88F9@NA-EXMSG-C114.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_456A5146F9319946A179B523B9FC91D60D9E4E88F9NAEXMSGC114re_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_000_456A5146F9319946A179B523B9FC91D60D9E4E88F9NAEXMSGC114re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nicely worded. I like the proposal for the charter. Mudit Goel From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Bernard Aboba Sent: Tuesday, April 01, 2008 3:41 PM To: radiusext@ops.ietf.org Subject: RADEXT WG re-charter As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. A st= rawman re-charter proposal is enclosed below. Once comments from WG participants have been incorporated, we will begin a = formal WG consensus call on the proposed re-charter by the end of the month. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC --_000_456A5146F9319946A179B523B9FC91D60D9E4E88F9NAEXMSGC114re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nicely worded. I like the proposal for the charter.

 

Mudit Goel

 

 

From: owner-radiuse= xt@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, April 01, 2008 3:41 PM
To: radiusext@ops.ietf.org
Subject: RADEXT WG re-charter

 

As we discussed at IETF 71, the RADEXT WG is looking at a re-charter.  A strawman re-charter proposal is enclosed below. 
Once comments from WG participants have been incorporated, we will begin a formal WG consensus call on the proposed
re-charter by the end of the month.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Description of Working Group:
The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage.

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.
 

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:
 

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.
 

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
 

Work Items
 

The immediate goals of the RADEXT working group are to address the
following issues:
 

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.
 

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.
 

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.
 

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.
 

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.
 

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC<= br> Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC draft submitted as an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

--_000_456A5146F9319946A179B523B9FC91D60D9E4E88F9NAEXMSGC114re_-- -- 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 Apr 8 21:27: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 4CF923A6EFA for ; Tue, 8 Apr 2008 21:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=-0.926, 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 HMNUbhG8jrbK for ; Tue, 8 Apr 2008 21:27:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A56F63A68B4 for ; Tue, 8 Apr 2008 21:27:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjRoK-00053C-AP for radiusext-data@psg.com; Wed, 09 Apr 2008 04:21:24 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjRoH-00052q-84 for radiusext@ops.ietf.org; Wed, 09 Apr 2008 04:21:22 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2008 21:21:20 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m394LKbU008064; Tue, 8 Apr 2008 21:21:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m394LKwQ017563; Wed, 9 Apr 2008 04:21:20 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 21:21:20 -0700 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: RADEXT WG re-charter Date: Tue, 8 Apr 2008 21:22:09 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADEXT WG re-charter Thread-Index: AciUMIh5HDfC0ApORCe0YwuFp/hp0wFxZR0Q References: From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 09 Apr 2008 04:21:20.0205 (UTC) FILETIME=[297D67D0:01C899F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6674; t=1207714880; x=1208578880; c=relaxed/simple; s=sjdkim3002; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=RDCrQnnRWS/e+O+zWm6jqKYXsiBrRvFsYhrjBxqF8Kc=; b=M9FdYSO9IhO6LCyLHliB+5Tm6WdDbDPjGfSn0BYYw2rES9jWWccqDi5iQI GBV0CKvvt1Tw02a+0hppEWHO0bI9ySwMHo3iFLV0K9BWAXIJgq7abLc1/gIg 5MLSSqPLSY; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-radiusext@ops.ietf.org Precedence: bulk Some questions on the proposed charter: >All RADIUS work MUST be backward compatible with existing=20 > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579,=20 > 3580, 4668-4673, 4675, 5080, 5090 and 5176. What does it mean for a new transport to be backward compatible? > - New RADIUS transports. New secure transports for RADIUS will > be developed, including TCP/TLS (RADSEC) and UDP/DTLS. What are we trying to gain by including new transports, especially TCP? Is it just crypto agility or are there other goals as well? This seems like a lot of work to gain crypto agility, it would be good to understand what else we have to gain. What is the intended status of this work? Experimental? Standards track? =20 > -RADIUS Cryptographic Algorithm Agility. RADIUS has=20 > traditionally relied on MD5 for both per-packet integrity and=20 > authentication as well as attribute confidentiality. Given=20 > the increasingly successful attacks being mounted against=20 > MD5, the ability to support alternative algorithms is=20 > required. This work item will include documentation of RADIUS=20 > crypto-agility requirements, as well as development of one or=20 > more Experimental RFCs providing support for negotiation of=20 > alternative cryptographic algorithms to protect RADIUS. > =20 Now that we have a separate item for secure transports shouldn't this explicitly refer to attribute based encryption, message authentication and key transport? =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, April 01, 2008 12:41 PM > To: radiusext@ops.ietf.org > Subject: RADEXT WG re-charter >=20 > As we discussed at IETF 71, the RADEXT WG is looking at a=20 > re-charter. A strawman re-charter proposal is enclosed below. =20 > Once comments from WG participants have been incorporated, we=20 > will begin a formal WG consensus call on the proposed=20 > re-charter by the end of the month.=20 > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > Description of Working Group: > The RADIUS Extensions Working Group will focus on extensions=20 > to the RADIUS protocol required to define extensions to the=20 > standard attribute space as well as to address cryptographic=20 > algorithm agility and use over new secure transports. In=20 > addition, RADEXT will work on RADIUS Design Guidelines and=20 > define new attributes for particular applications of=20 > authentication, authorization and accounting such as NAS=20 > management and local area network (LAN) usage.=20 >=20 > In order to enable interoperation of heterogeneous=20 > RADIUS/Diameter deployments, all RADEXT WG work items MUST=20 > contain a Diameter compatibility section, outlining how=20 > interoperability with Diameter will be maintained. > =20 >=20 > Furthermore, to ensure backward compatibility with existing=20 > RADIUS implementations, as well as compatibility between=20 > RADIUS and Diameter, the following restrictions are imposed=20 > on extensions considered by the RADEXT WG: > =20 >=20 > - All RADIUS work MUST be backward compatible with existing=20 > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579,=20 > 3580, 4668-4673, 4675, 5080, 5090 and 5176. > =20 >=20 > - All RADIUS work MUST be compatible with equivalent=20 > facilities in Diameter. Where possible, new attributes should=20 > be defined so that the same attribute can be used in both=20 > RADIUS and Diameter without translation. In other cases a=20 > translation considerations section should be included in the=20 > specification. > =20 >=20 > Work Items > =20 >=20 > The immediate goals of the RADEXT working group are to=20 > address the following issues: > =20 >=20 > - RADIUS design guidelines. This document will provide=20 > guidelines for design of RADIUS attributes. It will=20 > specifically consider how complex data types may be=20 > introduced in a robust manner, maintaining backwards=20 > compatibility with existing RADIUS RFCs, across all the=20 > classes of attributes: Standard, Vendor-Specific and SDO-Specific. > In addition, it will review RADIUS data types and associated=20 > backwards compatibility issues. > =20 > - RADIUS Management authorization. This document will define=20 > the use of RADIUS for NAS management over IP.=20 > =20 >=20 > -RADIUS attribute space extension. The standard RADIUS=20 > attribute space is currently being depleted. This document=20 > will provide additional standard attribute space, while=20 > maintaining backward compatibility with existing attributes. > =20 >=20 > -RADIUS Cryptographic Algorithm Agility. RADIUS has=20 > traditionally relied on MD5 for both per-packet integrity and=20 > authentication as well as attribute confidentiality. Given=20 > the increasingly successful attacks being mounted against=20 > MD5, the ability to support alternative algorithms is=20 > required. This work item will include documentation of RADIUS=20 > crypto-agility requirements, as well as development of one or=20 > more Experimental RFCs providing support for negotiation of=20 > alternative cryptographic algorithms to protect RADIUS. > =20 >=20 > - IEEE 802 attributes. New attributes have been proposed to > support IEEE 802 standards for wired and wireless LANs. This > work item will support authentication, authorization and > accounting attributes needed by IEEE 802 groups including > IEEE 802.1, IEEE 802.11 and IEEE 802.16. > =20 >=20 > - New RADIUS transports. New secure transports for RADIUS will > be developed, including TCP/TLS (RADSEC) and UDP/DTLS. >=20 > - Documentation of Status-Server usage. A document > describing usage of the Status-Server facility will be > developed. > =20 >=20 > Goals and Milestones: > Jun 2008 RADIUS Design Guidelines submitted as a Best Current=20 > Practice RFC > Jun 2008 RADIUS Management Authorization I-D submitted as a=20 > Proposed Standard RFC > Sep 2008 RADIUS Crypto-agility Requirements submitted as an=20 > Informational RFC > Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC > Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC > Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC > Mar 2009 RADSEC draft submitted as an Experimental RFC > June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC > June 2009 RADIUS Cryptographic Algorithm Agility I-D=20 > submitted as an Experimental RFC >=20 >=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 Thu Apr 10 09:52:38 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 0C3E33A6C70 for ; Thu, 10 Apr 2008 09:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 Yj70cQjGPdra for ; Thu, 10 Apr 2008 09:52:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C66CC3A6B8B for ; Thu, 10 Apr 2008 09:52:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjzuV-000DjY-0q for radiusext-data@psg.com; Thu, 10 Apr 2008 16:46:03 +0000 Received: from [65.55.175.226] (helo=blu139-omc3-s26.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjzuR-000Dit-If for radiusext@ops.ietf.org; Thu, 10 Apr 2008 16:46:01 +0000 Received: from BLU137-DS3 ([65.55.162.189]) by blu139-omc3-s26.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 09:45:58 -0700 X-Originating-IP: [131.107.0.102] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: To: "Joseph Salowey \(jsalowey\)" , References: Subject: Re: RADEXT WG re-charter Date: Thu, 10 Apr 2008 09:45:58 -0700 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: 10 Apr 2008 16:45:58.0851 (UTC) FILETIME=[5A738130:01C89B2A] Sender: owner-radiusext@ops.ietf.org Precedence: bulk > What does it mean for a new transport to be backward compatible? I think it means that it is possible to write a transport proxy that goes to/from RADIUS as it exists today (e.g. over UDP) and encapsulates it to/from the new transport, with minimal (ideally no) changes to the RADIUS packet. > What are we trying to gain by including new transports, especially TCP? > Is it just crypto agility or are there other goals as well? This seems > like a lot of work to gain crypto agility, it would be good to > understand what else we have to gain? The contemplated work includes both DTLS/UDP and TLS/TCP transports. The arguments for the former relate primarily to security; the arguments for the later relate to both security and transport considerations. The benefits in both areas have been laid out in presentations to the RADEXT WG over the last year and a half. Transport issues were examined in detail in the AAA WG, which described AAA requirements (including transport) in RFC 2989. Reliable transport was chosen, as a result of concerns over accounting reliability as well as experience with the drawbacks of the undefined transport behavior of RADIUS (discussed in RFC 5080 Section 2.2.1). The behavior of AAA over reliable transport was analyzed in RFC 3539, which also develops a transport profile and suggests failover and load balancing algorithms. Together, these documents provide a response to RFC 2865 Section 2.4, which lays out four reasons why RADIUS uses UDP: 1. If the request to a primary Authentication server fails, a secondary server must be queried. 2. The timing requirements of this particular protocol are significantly different than TCP provides. 3. The stateless nature of this protocol simplifies the use of UDP. 4. UDP simplifies the server implementation. RFC 3539 provides for failover and load balancing (1 & 2). Since RADIUS was first standardized in the mid 1990s, implementations have grown in sophistication and the underlying hardware has increased by several orders of magnitude in performance. As a result, considerations 3 and 4 have lessened in importance. > What is the intended status of this work? Experimental? Standards > track? The transport documents are slated for Experimental status (as stated in the charter). > Now that we have a separate item for secure transports shouldn't this > explicitly refer to attribute based encryption, message authentication > and key transport? The detailed requirements are going to be developed in a separate document. However, as discussed in the HOKEY WG meeting, the focus of the RADEXT WG will be on providing a generic security solution, including confidentiality, and message integrity/authentication. As discussed in the HOKEY WG meeting, key management attributes specific to ERX will be developed in HOKEY WG and will be independent of the specific RADIUS crypto-agility mechanism. >> -----Original Message----- >> From: owner-radiusext@ops.ietf.org >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >> Sent: Tuesday, April 01, 2008 12:41 PM >> To: radiusext@ops.ietf.org >> Subject: RADEXT WG re-charter >> >> As we discussed at IETF 71, the RADEXT WG is looking at a >> re-charter. A strawman re-charter proposal is enclosed below. >> Once comments from WG participants have been incorporated, we >> will begin a formal WG consensus call on the proposed >> re-charter by the end of the month. >> >> ================================== >> >> Description of Working Group: >> The RADIUS Extensions Working Group will focus on extensions >> to the RADIUS protocol required to define extensions to the >> standard attribute space as well as to address cryptographic >> algorithm agility and use over new secure transports. In >> addition, RADEXT will work on RADIUS Design Guidelines and >> define new attributes for particular applications of >> authentication, authorization and accounting such as NAS >> management and local area network (LAN) usage. >> >> In order to enable interoperation of heterogeneous >> RADIUS/Diameter deployments, all RADEXT WG work items MUST >> contain a Diameter compatibility section, outlining how >> interoperability with Diameter will be maintained. >> >> >> Furthermore, to ensure backward compatibility with existing >> RADIUS implementations, as well as compatibility between >> RADIUS and Diameter, the following restrictions are imposed >> on extensions considered by the RADEXT WG: >> >> >> - All RADIUS work MUST be backward compatible with existing >> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, >> 3580, 4668-4673, 4675, 5080, 5090 and 5176. >> >> >> - All RADIUS work MUST be compatible with equivalent >> facilities in Diameter. Where possible, new attributes should >> be defined so that the same attribute can be used in both >> RADIUS and Diameter without translation. In other cases a >> translation considerations section should be included in the >> specification. >> >> >> Work Items >> >> >> The immediate goals of the RADEXT working group are to >> address the following issues: >> >> >> - RADIUS design guidelines. This document will provide >> guidelines for design of RADIUS attributes. It will >> specifically consider how complex data types may be >> introduced in a robust manner, maintaining backwards >> compatibility with existing RADIUS RFCs, across all the >> classes of attributes: Standard, Vendor-Specific and SDO-Specific. >> In addition, it will review RADIUS data types and associated >> backwards compatibility issues. >> >> - RADIUS Management authorization. This document will define >> the use of RADIUS for NAS management over IP. >> >> >> -RADIUS attribute space extension. The standard RADIUS >> attribute space is currently being depleted. This document >> will provide additional standard attribute space, while >> maintaining backward compatibility with existing attributes. >> >> >> -RADIUS Cryptographic Algorithm Agility. RADIUS has >> traditionally relied on MD5 for both per-packet integrity and >> authentication as well as attribute confidentiality. Given >> the increasingly successful attacks being mounted against >> MD5, the ability to support alternative algorithms is >> required. This work item will include documentation of RADIUS >> crypto-agility requirements, as well as development of one or >> more Experimental RFCs providing support for negotiation of >> alternative cryptographic algorithms to protect RADIUS. >> >> >> - IEEE 802 attributes. New attributes have been proposed to >> support IEEE 802 standards for wired and wireless LANs. This >> work item will support authentication, authorization and >> accounting attributes needed by IEEE 802 groups including >> IEEE 802.1, IEEE 802.11 and IEEE 802.16. >> >> >> - New RADIUS transports. New secure transports for RADIUS will >> be developed, including TCP/TLS (RADSEC) and UDP/DTLS. >> >> - Documentation of Status-Server usage. A document >> describing usage of the Status-Server facility will be >> developed. >> >> >> Goals and Milestones: >> Jun 2008 RADIUS Design Guidelines submitted as a Best Current >> Practice RFC >> Jun 2008 RADIUS Management Authorization I-D submitted as a >> Proposed Standard RFC >> Sep 2008 RADIUS Crypto-agility Requirements submitted as an >> Informational RFC >> Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC >> Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC >> Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC >> Mar 2009 RADSEC draft submitted as an Experimental RFC >> June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC >> June 2009 RADIUS Cryptographic Algorithm Agility I-D >> submitted as an Experimental RFC >> >> > -- 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 Apr 10 22:00:38 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 D03013A6BF5 for ; Thu, 10 Apr 2008 22:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 jlv1Xb2UqKvh for ; Thu, 10 Apr 2008 22:00:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 456E83A6D16 for ; Thu, 10 Apr 2008 22:00:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkBGb-000D6P-5a for radiusext-data@psg.com; Fri, 11 Apr 2008 04:53:37 +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 1JkBGY-000D5G-DD for radiusext@ops.ietf.org; Fri, 11 Apr 2008 04:53:35 +0000 Received: from BLU137-W10 ([65.55.162.189]) by blu139-omc3-s3.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 21:53:33 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a791bdd9-2836-4b55-b5b7-ebd2aeb3c188_" X-Originating-IP: [24.18.144.82] From: Bernard Aboba To: Subject: Minutes from IETF 71 Date: Thu, 10 Apr 2008 21:53:33 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2008 04:53:33.0607 (UTC) FILETIME=[FEB6A370:01C89B8F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_a791bdd9-2836-4b55-b5b7-ebd2aeb3c188_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you took minutes at the RADEXT WG meeting at IETF 71, please send them = to Dave and myself.=20 --_a791bdd9-2836-4b55-b5b7-ebd2aeb3c188_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you took minutes at the RADEXT WG meeting at IETF  71, please send = them to Dave and myself.


= --_a791bdd9-2836-4b55-b5b7-ebd2aeb3c188_-- -- 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 Apr 11 15:42:24 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 98FE728C193 for ; Fri, 11 Apr 2008 15:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.354 X-Spam-Level: X-Spam-Status: No, score=-5.354 tagged_above=-999 required=5 tests=[AWL=-0.859, 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 oShU0i0bhPbz for ; Fri, 11 Apr 2008 15:42:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20FDC28C138 for ; Fri, 11 Apr 2008 15:42:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkRs2-000KAz-9S for radiusext-data@psg.com; Fri, 11 Apr 2008 22:37:22 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkRry-000KAb-Em for radiusext@ops.ietf.org; Fri, 11 Apr 2008 22:37:20 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2008 15:36:43 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3BMahG2027710; Fri, 11 Apr 2008 15:36:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3BMaheG021568; Fri, 11 Apr 2008 22:36:43 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 15:36:43 -0700 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: RADEXT WG re-charter Date: Fri, 11 Apr 2008 15:37:32 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADEXT WG re-charter Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQA References: From: "Joseph Salowey (jsalowey)" To: , X-OriginalArrivalTime: 11 Apr 2008 22:36:43.0709 (UTC) FILETIME=[8493BED0:01C89C24] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9097; t=1207953403; x=1208817403; c=relaxed/simple; s=sjdkim2002; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=G8NbLvGSyQpqk7YpJ9ms3qz/gpwOvUmT9Sz4kBIMYOo=; b=voevJokygoeJLjO7eHZxL6SnQHFJC9NXMS1MLOyZgRuuYbCdUry46Yjao7 sY34YevGha6vTFE0UK3XjDSyuLPMoHBidLZEuVgT7bimz1sDXx495teoFRXr xqNCy9zCiG; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-radiusext@ops.ietf.org Precedence: bulk Hi Bernard, Thanks for the detailed explanation.=20 With respect to the key transport item, I don't recall this discussion on the HOKEY list. I might have missed it. In any case I don't think this is the right approach. Key transport is a general problem that can be solved with a general solution.=20 Joe > > What does it mean for a new transport to be backward compatible? >=20 > I think it means that it is possible to write a transport=20 > proxy that goes to/from RADIUS as it exists today (e.g. over=20 > UDP) and encapsulates it to/from the new transport, with=20 > minimal (ideally no) changes to the RADIUS packet. >=20 > > What are we trying to gain by including new transports,=20 > especially TCP? > > Is it just crypto agility or are there other goals as well? This=20 > > seems like a lot of work to gain crypto agility, it would=20 > be good to=20 > > understand what else we have to gain? >=20 > The contemplated work includes both DTLS/UDP and TLS/TCP > transports. The arguments for the former relate primarily to > security; the arguments for the later relate to both security > and transport considerations. The benefits in both areas > have been laid out in presentations to the RADEXT WG over the=20 > last year and a half. >=20 > Transport issues were examined in detail in the AAA WG, which=20 > described AAA requirements (including transport) in > RFC 2989. Reliable transport was chosen, as a result of > concerns over accounting reliability as well as experience=20 > with the drawbacks of the undefined transport behavior of=20 > RADIUS (discussed in RFC 5080 Section 2.2.1). >=20 > The behavior of AAA over reliable transport was analyzed in=20 > RFC 3539, which also develops a transport profile and=20 > suggests failover and load balancing algorithms. >=20 > Together, these documents provide a response to RFC 2865=20 > Section 2.4, which lays out four reasons why RADIUS uses UDP: >=20 > 1. If the request to a primary Authentication server fails, a > secondary server must be queried. > 2. The timing requirements of this particular protocol are > significantly different than TCP provides. > 3. The stateless nature of this protocol simplifies the use of UDP. > 4. UDP simplifies the server implementation. >=20 > RFC 3539 provides for failover and load balancing (1 & 2). > Since RADIUS was first standardized in the mid 1990s,=20 > implementations have grown in sophistication and the=20 > underlying hardware has increased by several orders of magnitude > in performance. As a result, considerations 3 and 4 have lessened > in importance. >=20 > > What is the intended status of this work? Experimental? Standards=20 > > track? >=20 > The transport documents are slated for Experimental status=20 > (as stated in the charter). >=20 > > Now that we have a separate item for secure transports=20 > shouldn't this=20 > > explicitly refer to attribute based encryption, message=20 > authentication=20 > > and key transport? >=20 > The detailed requirements are going to be developed in a=20 > separate document. However, as discussed in the HOKEY WG=20 > meeting, the focus of the RADEXT WG will be on providing a=20 > generic security solution, including confidentiality, and=20 > message integrity/authentication. > As discussed in the HOKEY WG meeting, key management=20 > attributes specific to ERX will be developed in HOKEY WG and=20 > will be independent of the specific RADIUS crypto-agility mechanism. >=20 > >> -----Original Message----- > >> From: owner-radiusext@ops.ietf.org > >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > >> Sent: Tuesday, April 01, 2008 12:41 PM > >> To: radiusext@ops.ietf.org > >> Subject: RADEXT WG re-charter > >> > >> As we discussed at IETF 71, the RADEXT WG is looking at a=20 > re-charter. =20 > >> A strawman re-charter proposal is enclosed below. > >> Once comments from WG participants have been incorporated, we will=20 > >> begin a formal WG consensus call on the proposed re-charter by the=20 > >> end of the month. > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> Description of Working Group: > >> The RADIUS Extensions Working Group will focus on=20 > extensions to the=20 > >> RADIUS protocol required to define extensions to the standard=20 > >> attribute space as well as to address cryptographic=20 > algorithm agility=20 > >> and use over new secure transports. In addition, RADEXT=20 > will work on=20 > >> RADIUS Design Guidelines and define new attributes for particular=20 > >> applications of authentication, authorization and=20 > accounting such as=20 > >> NAS management and local area network (LAN) usage. > >> > >> In order to enable interoperation of heterogeneous RADIUS/Diameter=20 > >> deployments, all RADEXT WG work items MUST contain a Diameter=20 > >> compatibility section, outlining how interoperability with=20 > Diameter=20 > >> will be maintained. > >> > >> > >> Furthermore, to ensure backward compatibility with existing RADIUS=20 > >> implementations, as well as compatibility between RADIUS and=20 > >> Diameter, the following restrictions are imposed on extensions=20 > >> considered by the RADEXT WG: > >> > >> > >> - All RADIUS work MUST be backward compatible with existing RADIUS=20 > >> RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,=20 > >> 4675, 5080, 5090 and 5176. > >> > >> > >> - All RADIUS work MUST be compatible with equivalent facilities in=20 > >> Diameter. Where possible, new attributes should be defined so that=20 > >> the same attribute can be used in both RADIUS and Diameter without=20 > >> translation. In other cases a translation considerations section=20 > >> should be included in the specification. > >> > >> > >> Work Items > >> > >> > >> The immediate goals of the RADEXT working group are to address the=20 > >> following issues: > >> > >> > >> - RADIUS design guidelines. This document will provide=20 > guidelines for=20 > >> design of RADIUS attributes. It will specifically consider how=20 > >> complex data types may be introduced in a robust manner,=20 > maintaining=20 > >> backwards compatibility with existing RADIUS RFCs, across all the=20 > >> classes of attributes: Standard, Vendor-Specific and SDO-Specific. > >> In addition, it will review RADIUS data types and associated=20 > >> backwards compatibility issues. > >> > >> - RADIUS Management authorization. This document will=20 > define the use=20 > >> of RADIUS for NAS management over IP. > >> > >> > >> -RADIUS attribute space extension. The standard RADIUS attribute=20 > >> space is currently being depleted. This document will provide=20 > >> additional standard attribute space, while maintaining backward=20 > >> compatibility with existing attributes. > >> > >> > >> -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20 > >> relied on MD5 for both per-packet integrity and authentication as=20 > >> well as attribute confidentiality. Given the increasingly=20 > successful=20 > >> attacks being mounted against MD5, the ability to support=20 > alternative=20 > >> algorithms is required. This work item will include=20 > documentation of=20 > >> RADIUS crypto-agility requirements, as well as development=20 > of one or=20 > >> more Experimental RFCs providing support for negotiation of=20 > >> alternative cryptographic algorithms to protect RADIUS. > >> > >> > >> - IEEE 802 attributes. New attributes have been proposed=20 > to support=20 > >> IEEE 802 standards for wired and wireless LANs. This work=20 > item will=20 > >> support authentication, authorization and accounting attributes=20 > >> needed by IEEE 802 groups including IEEE 802.1, IEEE=20 > 802.11 and IEEE=20 > >> 802.16. > >> > >> > >> - New RADIUS transports. New secure transports for RADIUS will be=20 > >> developed, including TCP/TLS (RADSEC) and UDP/DTLS. > >> > >> - Documentation of Status-Server usage. A document=20 > describing usage=20 > >> of the Status-Server facility will be developed. > >> > >> > >> Goals and Milestones: > >> Jun 2008 RADIUS Design Guidelines submitted as a Best Current=20 > >> Practice RFC Jun 2008 RADIUS Management Authorization I-D=20 > submitted=20 > >> as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility=20 > >> Requirements submitted as an Informational RFC Sep 2008 Extended=20 > >> Attributes I-D submitted as a Proposed Standard RC Dec=20 > 2008 IEEE 802=20 > >> Attributes I-D submitted as a Proposed Standard RFC Mar 2009=20 > >> Status-Server I-D submitted as a Proposed Standard RFC Mar 2009=20 > >> RADSEC draft submitted as an Experimental RFC June 2009=20 > RADIUS over=20 > >> DTLS I-D submitted as an Experimental RFC June 2009 RADIUS=20 > >> Cryptographic Algorithm Agility I-D submitted as an=20 > Experimental RFC > >> > >> > >=20 >=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 Fri Apr 11 16:04: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 D3AF93A6CAD for ; Fri, 11 Apr 2008 16:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-0.376, 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 iLypbeSVL8Vz for ; Fri, 11 Apr 2008 16:04:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEAEB28C186 for ; Fri, 11 Apr 2008 16:04:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkSEp-000LRh-A7 for radiusext-data@psg.com; Fri, 11 Apr 2008 23:00:55 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkSEm-000LRO-Li for radiusext@ops.ietf.org; Fri, 11 Apr 2008 23:00:53 +0000 Received: (qmail 21197 invoked from network); 11 Apr 2008 19:00:51 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 11 Apr 2008 19:00:51 -0400 From: "David B. Nelson" To: "'Joseph Salowey \(jsalowey\)'" , , References: Subject: RE: RADEXT WG re-charter Date: Fri, 11 Apr 2008 18:58:22 -0400 Organization: Elbrys Networks, Inc. Message-ID: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> 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: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnA= In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk Joseph Salowey writes... > With respect to the key transport item, I don't recall this discussion > on the HOKEY list. I might have missed it. In any case I don't think > this is the right approach. Key transport is a general problem that can > be solved with a general solution. The discussion in the HOKEY session at IETF-71, as I recall it, centered around whether HOKEY ought to define a non-protected RADIUS (Diameter) attribute for key transport (I called this a key container attribute) that could utilize various options for protection, one of which might be a generalized Encrypted Attribute format, as described in a RADEXT Crypto-Agility draft. Follow up discussion in the RADEXT WG session included the issue of whether or not the cryptographic requirements for key wrap (key transport) were sufficiently different from the cryptographic requirements for transport of bulk data that a separate protection mechanism needed to be defined. We leaned that special purpose key wrap mechanisms could be "simpler" in some cryptographic sense because one can rely on the property of keys that their content is highly random. The question that I think was never satisfactorily answered is why one would need to deploy special purpose key wrap mechanisms in addition to general propose attribute encryption mechanisms. Having said that, it is true that the RADIUS community has existing "special purpose" key wrap attributes (the MSPPE key attributes) that do not meet the crypto-agility requirements. We need to decide what to do about these. They are widely deployed today, e.g. in 802.11. -- 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 Apr 14 06:25:47 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 D18AC3A6DE7 for ; Mon, 14 Apr 2008 06:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 cDrdAC-rgj2f for ; Mon, 14 Apr 2008 06:25:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 28E0E3A68F2 for ; Mon, 14 Apr 2008 06:25:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlObM-000IcC-QR for radiusext-data@psg.com; Mon, 14 Apr 2008 13:20:04 +0000 Received: from [65.55.175.215] (helo=blu139-omc3-s15.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlObF-000Ib1-6T for radiusext@ops.ietf.org; Mon, 14 Apr 2008 13:19:59 +0000 Received: from BLU137-DS3 ([65.55.162.189]) by blu139-omc3-s15.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 06:19:56 -0700 X-Originating-IP: [24.18.147.115] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 06:19:57 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C89DF7.8F8BB5C0" 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 Apr 2008 13:19:56.0423 (UTC) FILETIME=[3B85B170:01C89E32] Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C89DF7.8F8BB5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a consensus call for acceptance of the RADEXT WG re-charter. = The consensus call will last until April 28, 2008. Please send email to the = list=20 stating whether you are in favor or opposed to the RADEXT WG re-charter proposal:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for=20 particular applications of authentication, authorization and=20 accounting such as NAS management and local area network (LAN) usage.=20 In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. =20 Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. =20 - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP.=20 -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20 relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice = RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed = Standard RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an = Informational RFC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental = RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an = Experimental RFC ------=_NextPart_000_001C_01C89DF7.8F8BB5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a consensus call for acceptance = of the=20 RADEXT WG re-charter.  The
consensus call will last until = April 28,=20 2008.  Please send email to the list
stating whether you are in favor or = opposed to the=20 RADEXT WG re-charter
proposal:
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Description of Working Group:

The RADIUS Extensions Working Group will focus on = extensions=20 to the
RADIUS protocol required to define extensions to the=20 standard
attribute space as well as to address cryptographic=20 algorithm
agility and use over new secure transports. In addition, = RADEXT=20 will
work on RADIUS Design Guidelines and define new attributes for=20
particular applications of authentication, authorization and =
accounting=20 such as NAS management and local area network (LAN) usage.

In = order to=20 enable interoperation of heterogeneous RADIUS/Diameter
deployments, = all=20 RADEXT WG work items MUST contain a Diameter
compatibility section, = outlining=20 how interoperability with
Diameter will be = maintained.

Furthermore, to=20 ensure backward compatibility with existing RADIUS
implementations, = as well=20 as compatibility between RADIUS and Diameter,
the following = restrictions are=20 imposed on extensions considered by the
RADEXT WG:

- All = RADIUS work=20 MUST be backward compatible with existing RADIUS
RFCs, including RFCs = 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and=20 5176.

- All RADIUS work MUST be compatible with equivalent = facilities=20 in
Diameter. Where possible, new attributes should be defined so = that
the=20 same attribute can be used in both RADIUS and Diameter = without
translation.=20 In other cases a translation considerations
section should be = included in the=20 specification.
 

Work Items

The immediate goals of = the=20 RADEXT working group are to address the
following issues:

- = RADIUS=20 design guidelines. This document will provide guidelines for
design = of RADIUS=20 attributes. It will specifically consider how
complex data types may = be=20 introduced in a robust manner, maintaining
backwards compatibility = with=20 existing RADIUS RFCs, across all the
classes of attributes: Standard, = Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS = data=20 types and associated
backwards compatibility issues.
 
- = RADIUS=20 Management authorization. This document will define the
use of RADIUS = for NAS=20 management over IP.

-RADIUS attribute space extension. The = standard=20 RADIUS attribute
space is currently being depleted. This document = will=20 provide
additional standard attribute space, while maintaining=20 backward
compatibility with existing attributes.

-RADIUS = Cryptographic=20 Algorithm Agility. RADIUS has traditionally
relied on MD5 for both=20 per-packet integrity and authentication as well
as attribute = confidentiality.=20 Given the increasingly successful
attacks being mounted against MD5, = the=20 ability to support
alternative algorithms is required. This work item = will
include documentation of RADIUS crypto-agility = requirements,
as well=20 as development of one or more Experimental RFCs providing
support for = negotiation of alternative cryptographic algorithms
to protect=20 RADIUS.

- IEEE 802 attributes. New attributes have been proposed=20 to
support IEEE 802 standards for wired and wireless LANs. = This
work item=20 will support authentication, authorization and
accounting attributes = needed=20 by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE=20 802.16.

- New RADIUS transports. New secure transports for RADIUS = will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

-=20 Documentation of Status-Server usage. A document
describing usage of = the=20 Status-Server facility will be
developed.

Goals and = Milestones:
Jun=20 2008 RADIUS Design Guidelines submitted as a Best Current Practice = RFC
Jun=20 2008 RADIUS Management Authorization I-D submitted as a Proposed = Standard=20 RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an = Informational=20 RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard = RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard = RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard = RFC
Mar=20 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental = RFC
June=20 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 = RADIUS=20 Cryptographic Algorithm Agility I-D submitted as an Experimental=20 RFC
------=_NextPart_000_001C_01C89DF7.8F8BB5C0-- -- 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 Apr 14 06:53: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 1EB5F3A6C1B for ; Mon, 14 Apr 2008 06:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 FXoPE1ny6HKB for ; Mon, 14 Apr 2008 06:53:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E64F3A68F1 for ; Mon, 14 Apr 2008 06:53:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlP3c-000Lvt-Hw for radiusext-data@psg.com; Mon, 14 Apr 2008 13:49:16 +0000 Received: from [76.96.30.80] (helo=QMTA08.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlP3S-000Lu2-O6 for radiusext@ops.ietf.org; Mon, 14 Apr 2008 13:49:12 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id DRLT1Z03x1GXsucA801100; Mon, 14 Apr 2008 13:47:47 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id DRoG1Z005177aMo8T00000; Mon, 14 Apr 2008 13:49:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=No5EcEP4AAAA:8 a=cDoHXRlVh3Im7kisiNYA:9 a=aeIDltdY_Dq8IBhqEyMA:7 a=Lx83c2mY4k1mOFwmJ3pO5n-wq4YA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: "'Joseph Salowey \(jsalowey\)'" , , References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> Subject: RE: RADEXT WG re-charter Date: Mon, 14 Apr 2008 20:48:07 +0700 Message-ID: <001801c89e36$38856cf0$33da787c@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: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Saturday, April 12, 2008 5:58 AM: > Joseph Salowey writes... > >> With respect to the key transport item, I don't recall this >> discussion on the HOKEY list. I might have missed it. In any case I >> don't think this is the right approach. Key transport is a general >> problem that can be solved with a general solution. > > The discussion in the HOKEY session at IETF-71, as I recall > it, centered around whether HOKEY ought to define a > non-protected RADIUS (Diameter) attribute for key transport (I > called this a key container attribute) that could utilize > various options for protection, one of which might be a > generalized Encrypted Attribute format, as described in a RADEXT > Crypto-Agility draft. There was indeed discussion, but mostly in the form of various assertions by the radext Chairs that this would be a good idea; I don't recall anything like consensus around this topic. > > Follow up discussion in the RADEXT WG session included the > issue of whether or not the cryptographic requirements for key > wrap (key transport) were sufficiently different from the > cryptographic requirements for transport of bulk data that a > separate protection mechanism needed to be defined. > > We leaned that special purpose key wrap mechanisms could be > "simpler" in some cryptographic sense because one can rely on > the property of keys that their content is highly random. The > question that I think was never satisfactorily answered is why > one would need to deploy special purpose key wrap mechanisms > in addition to general propose attribute encryption mechanisms. I guess, then, that "gaining FIPS certification" is an unsatisfactory answer, since that was the one I (among others) gave. So what would be a satisfactory answer? > > Having said that, it is true that the RADIUS community has > existing "special purpose" key wrap attributes (the MSPPE key > attributes) that do not meet the crypto-agility requirements. > We need to decide what to do about these. Can you say "deprecate"? :-) > They are widely deployed today, e.g. in 802.11. > > > > -- > 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 Mon Apr 14 07:56: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 466433A67AE for ; Mon, 14 Apr 2008 07:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-0.362, 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 DoqaFJAKDR3p for ; Mon, 14 Apr 2008 07:56:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 989473A6973 for ; Mon, 14 Apr 2008 07:56:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlQ14-0003gg-4A for radiusext-data@psg.com; Mon, 14 Apr 2008 14:50:42 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlQ0y-0003fr-H1 for radiusext@ops.ietf.org; Mon, 14 Apr 2008 14:50:40 +0000 Received: (qmail 12876 invoked from network); 14 Apr 2008 10:50:35 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 14 Apr 2008 10:50:35 -0400 From: "David B. Nelson" To: Cc: "'Joseph Salowey \(jsalowey\)'" , , "'Glen Zorn'" References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> Subject: RE: RADEXT WG re-charter Date: Mon, 14 Apr 2008 10:47:57 -0400 Organization: Elbrys Networks, Inc. Message-ID: <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> 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: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQ In-Reply-To: <001801c89e36$38856cf0$33da787c@arubanetworks.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > There was indeed discussion, but mostly in the form of various > assertions by the radext Chairs that this would be a good idea; That much is largely true. >... I don't recall anything like consensus around this topic. Unless I much mistake the poll questions and results that Charles facilitated during the HOKEY meeting, there was consensus in the room. Of course, that is subject to consensus on the list. I'm also aware that you think this it not a good idea. > I guess, then, that "gaining FIPS certification" is an unsatisfactory > answer, since that was the one I (among others) gave. So what would > be a satisfactory answer? Well, "gaining FIPS certification" for a product release is likely a very fine thing indeed. I guess the question is whether the only way to do that is to use the AES key-wrap as described in draft-zorn-radius-keywrap-13.txt, or whether another NIST-approved algorithm, designed for bulk data encryption might also be used? In the latter case we solve the more general problem, without requiring separate attribute formats for keys and general purpose data. -- 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 Apr 14 09:04:05 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 6B46D3A68D0 for ; Mon, 14 Apr 2008 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 6-eXJHcm1rv7 for ; Mon, 14 Apr 2008 09:04:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F0FD228C2EB for ; Mon, 14 Apr 2008 09:04:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlR3J-000Bmo-Jr for radiusext-data@psg.com; Mon, 14 Apr 2008 15:57:05 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlR3G-000BmW-Pa for radiusext@ops.ietf.org; Mon, 14 Apr 2008 15:57:04 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id DTkH1Z00C1GXsucA403V00; Mon, 14 Apr 2008 15:55:31 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id DTwY1Z006177aMo8T00000; Mon, 14 Apr 2008 15:56:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=1bz1owvqq8MA:10 a=wUjQaic1T1T5I9AIgkAA:9 a=qOHg15RzzP-O5U2w7twA:7 a=tSq2dP-WnD-N9pVIqhlCJqE-otwA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: , References: Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 22:56:26 +0700 Message-ID: <001c01c89e48$1f348a30$33da787c@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: Thread-Index: AcieMwe23/m5rnbXTe6Ve/6y3296vAAFAQBg Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 8:20 PM: > This is a consensus call for acceptance of the RADEXT WG > re-charter. The consensus call will last until April 28, > 2008. Please send email to the list stating whether you are > in favor or opposed to the RADEXT WG re-charter > proposal: Given the Co-Chair's response to the question of the meaning of "backward compatibility", I think that it would show considerably more intellectual honesty to simply remove the first bullet: "compatibility" defined by the feasibility of implementing a protocol gateway is essentially meaningless, since by that measure there are no two protocols that are not "compatible". > > > ======================================================= > Description of Working Group: > > The RADIUS Extensions Working Group will focus on extensions > to the RADIUS protocol required to define extensions to the > standard attribute space as well as to address cryptographic > algorithm agility and use over new secure transports. In > addition, RADEXT will work on RADIUS Design Guidelines and > define new attributes for particular applications of > authentication, authorization and accounting such as NAS > management and local area network (LAN) usage. > > In order to enable interoperation of heterogeneous > RADIUS/Diameter deployments, all RADEXT WG work items MUST > contain a Diameter compatibility section, outlining how > interoperability with Diameter will be maintained. > > Furthermore, to ensure backward compatibility with existing > RADIUS implementations, as well as compatibility between > RADIUS and Diameter, the following restrictions are imposed on > extensions considered by the RADEXT WG: > > - All RADIUS work MUST be backward compatible with existing > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, > 4668-4673, 4675, 5080, 5090 and 5176. > > - All RADIUS work MUST be compatible with equivalent > facilities in Diameter. Where possible, new attributes should > be defined so that the same attribute can be used in both > RADIUS and Diameter without translation. In other cases a > translation considerations section should be included in the > specification. > > > Work Items > > The immediate goals of the RADEXT working group are to address > the following issues: > > - RADIUS design guidelines. This document will provide > guidelines for design of RADIUS attributes. It will > specifically consider how complex data types may be introduced > in a robust manner, maintaining backwards compatibility with > existing RADIUS RFCs, across all the classes of attributes: > Standard, Vendor-Specific and SDO-Specific. > In addition, it will review RADIUS data types and associated > backwards compatibility issues. > > - RADIUS Management authorization. This document will define > the use of RADIUS for NAS management over IP. > > -RADIUS attribute space extension. The standard RADIUS > attribute space is currently being depleted. This document > will provide additional standard attribute space, while > maintaining backward compatibility with existing attributes. > > -RADIUS Cryptographic Algorithm Agility. RADIUS has > traditionally relied on MD5 for both per-packet integrity and > authentication as well as attribute confidentiality. Given the > increasingly successful attacks being mounted against MD5, the > ability to support alternative algorithms is required. This > work item will include documentation of RADIUS crypto-agility > requirements, as well as development of one or more > Experimental RFCs providing support for negotiation of > alternative cryptographic algorithms to protect RADIUS. > > - IEEE 802 attributes. New attributes have been proposed to > support IEEE 802 standards for wired and wireless LANs. This > work item will support authentication, authorization and > accounting attributes needed by IEEE 802 groups including IEEE > 802.1, IEEE 802.11 and IEEE 802.16. > > - New RADIUS transports. New secure transports for RADIUS will > be developed, including TCP/TLS (RADSEC) and UDP/DTLS. > > - Documentation of Status-Server usage. A document describing > usage of the Status-Server facility will be developed. > > Goals and Milestones: > Jun 2008 RADIUS Design Guidelines submitted as a Best Current > Practice RFC Jun 2008 RADIUS Management Authorization I-D > submitted as a Proposed Standard RFC Sep 2008 RADIUS > Crypto-agility Requirements submitted as an Informational RFC > Sep 2008 Extended Attributes I-D submitted as a Proposed > Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a > Proposed Standard RFC Mar 2009 Status-Server I-D submitted as > a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) > draft submitted as an Experimental RFC June 2009 RADIUS over > DTLS I-D submitted as an Experimental RFC June 2009 RADIUS > Cryptographic Algorithm Agility I-D submitted as an Experimental RFC -- 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 Apr 14 09:48: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 8CA5E3A6969 for ; Mon, 14 Apr 2008 09:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 tF16Ke9xksvK for ; Mon, 14 Apr 2008 09:48:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 878EC3A6E3E for ; Mon, 14 Apr 2008 09:48:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlRm4-000Grq-6Z for radiusext-data@psg.com; Mon, 14 Apr 2008 16:43:20 +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 1JlRlt-000Gpx-D8 for radiusext@ops.ietf.org; Mon, 14 Apr 2008 16:43:14 +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 EBCBCA7079; Mon, 14 Apr 2008 09:43:03 -0700 (PDT) Message-ID: <480388AF.7040904@nitros9.org> Date: Mon, 14 Apr 2008 18:39:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Glen Zorn CC: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> In-Reply-To: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn wrote: > Given the Co-Chair's response to the question of the meaning of > "backward compatibility", I think that it would show considerably more > intellectual honesty to simply remove the first bullet: "compatibility" > defined by the feasibility of implementing a protocol gateway is > essentially meaningless, since by that measure there are no two > protocols that are not "compatible". While that's true, a RadSec to RADIUS gateway involves terminating TCP, TLS, and forwarding the contents to RADIUS. If this isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't doing HTTP. Similarly, any IPv4 to IPv6 gateway is evil, because it involves changing the transport layers underneath the application-layer protocol. And finally, SIP allows for both UDP and TCP transports, each with the option (or not) of using TLS. There would seem to be obvious parallels between SIP and RADIUS here. 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 Apr 14 09:51: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 B53643A6A15 for ; Mon, 14 Apr 2008 09:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 eJ2j09CRGGsq for ; Mon, 14 Apr 2008 09:51:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD4333A6E3E for ; Mon, 14 Apr 2008 09:51:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlRq0-000HG9-Sp for radiusext-data@psg.com; Mon, 14 Apr 2008 16:47:24 +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 1JlRpv-000HFX-68 for radiusext@ops.ietf.org; Mon, 14 Apr 2008 16:47:23 +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 6279AA7079 for ; Mon, 14 Apr 2008 09:47:16 -0700 (PDT) Message-ID: <480389AA.40600@nitros9.org> Date: Mon, 14 Apr 2008 18:43:22 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter References: 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@hotmail.com wrote: > This is a consensus call for acceptance of the RADEXT WG re-charter. The > consensus call will last until April 28, 2008. Please send email to the > list > stating whether you are in favor or opposed to the RADEXT WG re-charter > proposal: I am in favor of the proposal. 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 Apr 14 09:53: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 0AEC03A69E6 for ; Mon, 14 Apr 2008 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 IPy7u9e7WX7B for ; Mon, 14 Apr 2008 09:53:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CB013A6E91 for ; Mon, 14 Apr 2008 09:53:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlRrQ-000HQZ-Eo for radiusext-data@psg.com; Mon, 14 Apr 2008 16:48:52 +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 1JlRrJ-000HPV-H1 for radiusext@ops.ietf.org; Mon, 14 Apr 2008 16:48:51 +0000 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id DT2r1Z00G0FhH24A607l00; Mon, 14 Apr 2008 16:47:27 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id DUny1Z00J177aMo8U00000; Mon, 14 Apr 2008 16:48:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=No5EcEP4AAAA:8 a=MBloKb4mMHyY4VONF0AA:9 a=uwOtzR0ocX8Y3c8w-pwA:7 a=8i3kCJpjzyVH6Oe-3XAw4KjB5rIA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'David B. Nelson'" , Cc: "'Joseph Salowey \(jsalowey\)'" , References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> Subject: RE: RADEXT WG re-charter Date: Mon, 14 Apr 2008 23:47:52 +0700 Message-ID: <001d01c89e4f$53bed740$33da787c@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: <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 9:48 PM: > Glen Zorn writes... > >> There was indeed discussion, but mostly in the form of various >> assertions by the radext Chairs that this would be a good idea; > > That much is largely true. > >> ... I don't recall anything like consensus around this topic. > > Unless I much mistake the poll questions and results that > Charles facilitated during the HOKEY meeting, there was > consensus in the room. I really appreciate your judgment of consensus in the hokey WG. Please drop by more often. > Of course, that is subject to > consensus on the list. I'm also aware that you think this it not a > good idea. See below. > >> I guess, then, that "gaining FIPS certification" is an unsatisfactory >> answer, since that was the one I (among others) gave. So what would >> be a satisfactory answer? > > Well, "gaining FIPS certification" for a product release is > likely a very fine thing indeed. I guess the question is > whether the only way to do that is to use the AES key-wrap as > described in draft-zorn-radius-keywrap-13.txt, or whether > another NIST-approved algorithm, designed for bulk data > encryption might also be used? > In the latter case we solve > the more general problem, without requiring separate attribute > formats for keys and general purpose data. 'Frankly, my dear, I don't give a damn.' I do find it quite fascinating to observe this whole thing happening in (very) slow motion. It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt was posted & in that period of time every trick in the book (& I'm sure some that were new additions) has been used to ignore, delay or kill it; furthermore, for at least 3 years there have been at 2 (or more) independent, interoperable implementations that were FIPS-certified. But wait! Let's spend a little (lot) more time conjecturing about another way, a way to solve "the general problem" (AKA "boiling the ocean" if it's a proposal we don't care for). Well, gosh, no thanks, but you guys go ahead & have fun! > > > > -- > 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 Mon Apr 14 10:37:04 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 14A173A69B8 for ; Mon, 14 Apr 2008 10:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 KRT3nnhQMDfa for ; Mon, 14 Apr 2008 10:37:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C2733A69F3 for ; Mon, 14 Apr 2008 10:37:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlSYF-000Nkt-Ok for radiusext-data@psg.com; Mon, 14 Apr 2008 17:33:07 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlSYC-000NT4-Nf for radiusext@ops.ietf.org; Mon, 14 Apr 2008 17:33:06 +0000 Received: (qmail 16546 invoked from network); 14 Apr 2008 13:31:48 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 14 Apr 2008 13:31:48 -0400 From: "David B. Nelson" To: , "'Glen Zorn'" Cc: "'Joseph Salowey \(jsalowey\)'" , References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> Subject: RE: RADEXT WG re-charter Date: Mon, 14 Apr 2008 13:29:10 -0400 Organization: Elbrys Networks, Inc. Message-ID: <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> 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: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFAAAers8A== In-Reply-To: <001d01c89e4f$53bed740$33da787c@arubanetworks.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > 'Frankly, my dear, I don't give a damn.' Cute... > It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt > was posted ... for at least 3 years there have been at 2 (or more) > independent, interoperable implementations that were FIPS-certified. Given that there are implementations of this key-wrap scheme, presumably using VSAs, it might be well to publish an Information RFC, describing the actual implementations, using those VSAs. > But wait! Let's spend a little (lot) more time conjecturing about > another way, a way to solve "the general problem" (AKA "boiling the > ocean" if it's a proposal we don't care for). Well, gosh, no thanks, > but you guys go ahead & have fun! RADEXT has a chartered work item to address crypto-agility. We have requirements for this wok, and we now have an ID capturing those requirements. We don't have a requirement to specifically address key-wrap, as a separate problem. My questions is whether RADEXT really needs to create two drafts to satisfy the crypto-agility work item, one for key-wrap and one for general purpose encrypted attributes. The fact that solutions, and drafts, exist to address key-wrap and encrypted attributes separately is a point in favor of retaining the separation. I'm just questioning whether that's a sufficient basis on which to decide that we need such separation of concerns. If the consensus us of the WG is that we should proceed with separate documents for key-wrap and general crypto-agility, we can propose doing that in our revised charter. It would be nice, however, to have a reason beyond the existence of (4 year old) drafts that are structured that way. -- 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 Apr 14 11:31: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 7096F3A6C9F for ; Mon, 14 Apr 2008 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 omdVUkEWzvrM for ; Mon, 14 Apr 2008 11:31:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64BEF3A6A4A for ; Mon, 14 Apr 2008 11:31:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlTNM-0006UQ-4z for radiusext-data@psg.com; Mon, 14 Apr 2008 18:25:56 +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 1JlTNG-0006Tu-KW for radiusext@ops.ietf.org; Mon, 14 Apr 2008 18:25:51 +0000 Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id DTsg1Z00B0QkzPwA90HU00; Mon, 14 Apr 2008 18:25:49 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id DWRH1Z001177aMo8N00000; Mon, 14 Apr 2008 18:25:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=1bz1owvqq8MA:10 a=No5EcEP4AAAA:8 a=yyVGicQwbSlBecshslUA:9 a=bmb5vLq9nkdldPe2D5MA:7 a=bStnvWriLeOe-o6ifqQwtTJ_VMEA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 11:25:10 -0700 Message-ID: <005b01c89e5c$e9822720$33da787c@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: <480388AF.7040904@nitros9.org> Thread-Index: AcieT2EsgGme3+YNSZ+VU1+AdtaEzAAANuYA Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 11:39 PM: > Glen Zorn wrote: >> Given the Co-Chair's response to the question of the meaning of >> "backward compatibility", I think that it would show considerably >> more intellectual honesty to simply remove the first bullet: >> "compatibility" defined by the feasibility of implementing a >> protocol gateway is essentially meaningless, since by that measure >> there are no two protocols that are not "compatible". > > While that's true, a RadSec to RADIUS gateway involves > terminating TCP, TLS, and forwarding the contents to RADIUS. > If this isn't RADIUS, then by the same standards, any HTTPS to HTTP > proxy isn't doing HTTP. Hmm. By that standard, it would seem that Diameter is RADIUS, too... > > Similarly, any IPv4 to IPv6 gateway is evil, because it > involves changing the transport layers underneath the > application-layer protocol. I don't think that I said anything about good or evil :-), but you make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & that's not a problem. The problem would arise if someone claimed that it was because, 'Well, you can build a gateway'. > > And finally, SIP allows for both UDP and TCP transports, > each with the option (or not) of using TLS. There would seem > to be obvious parallels between SIP and RADIUS here. Certainly, in that RADIUS (the RFC 2865 version, anyway) only allows UDP transport. How could I have missed that? ;-) > > 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: -- 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 Apr 14 12:01: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 0079F3A6ED7 for ; Mon, 14 Apr 2008 12:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 xucgdRyU52QI for ; Mon, 14 Apr 2008 12:01:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 556FC3A6EDC for ; Mon, 14 Apr 2008 12:00:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlTpl-00099h-0z for radiusext-data@psg.com; Mon, 14 Apr 2008 18:55:17 +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 1JlTpi-0008zD-Bp for radiusext@ops.ietf.org; Mon, 14 Apr 2008 18:55: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 1746CA7137; Mon, 14 Apr 2008 11:53:43 -0700 (PDT) Message-ID: <4803A74D.1000708@nitros9.org> Date: Mon, 14 Apr 2008 20:49:49 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Glen Zorn CC: 'radext mailing list' Subject: Re: Consensus Call on RADEXT WG re-charter References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> In-Reply-To: <005b01c89e5c$e9822720$33da787c@arubanetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn wrote: ... >> If this isn't RADIUS, then by the same standards, any HTTPS to HTTP >> proxy isn't doing HTTP. > > Hmm. By that standard, it would seem that Diameter is RADIUS, too... No. I didn't mention an HTTPS to FTP proxy as being HTTP. > I don't think that I said anything about good or evil :-), but you make > my point for me: IPv6 is hardly "backward compatible" w/IPv4 & that's > not a problem. The problem would arise if someone claimed that it was > because, 'Well, you can build a gateway'. The protocols being transported on IPv4 can also be transported on IPv6. Similarly, UDP transport + RADIUS application protocol is... RADIUS. TCP transport + RADIUS application protocol is... RADIUS. The only way to call RadSec something other than RADIUS is if you say that FTP over IPv6 is not FTP. After all, FTP was for IPv4, and IPv6 is a new-fangled transport... so FTP over IPv6 is not FTP... it's "magic". 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 Apr 14 12:23:05 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 93B413A6CB0 for ; Mon, 14 Apr 2008 12:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=-0.337, 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 drAPEdwAMQVu for ; Mon, 14 Apr 2008 12:23:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79ADA3A6CF0 for ; Mon, 14 Apr 2008 12:23:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlUDh-000Bs2-Q2 for radiusext-data@psg.com; Mon, 14 Apr 2008 19:20:01 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlUDc-000Bqe-5K for radiusext@ops.ietf.org; Mon, 14 Apr 2008 19:20:00 +0000 Received: (qmail 19556 invoked from network); 14 Apr 2008 15:19:52 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 14 Apr 2008 15:19:52 -0400 From: "David B. Nelson" To: References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> <4803A74D.1000708@nitros9.org> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 15:17:14 -0400 Organization: Elbrys Networks, Inc. Message-ID: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> 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: AcieYdv/Dve1K2oWRxuAKjN8MK5bawAAC1bQ In-Reply-To: <4803A74D.1000708@nitros9.org> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Alan DeKok writes... > The protocols being transported on IPv4 can also be transported on > IPv6. Similarly, UDP transport + RADIUS application protocol is... > RADIUS. TCP transport + RADIUS application protocol is... RADIUS. I can see both sides of this argument. It's a common and desirable practice that application layer protocols are designed to be transport-agnostic. Some are; some aren't. In the case of RADIUS, the original task was to document RADIUS pretty much "as implemented" by Livingston Enterprises, Merit Networks, and a few others. Use of the UDP transport got "hard-wired" into the RFC. Maybe UDP is "crucial" to RADIUS being RADIUS, maybe it's an artifact. > The only way to call RadSec something other than RADIUS is if you say > that FTP over IPv6 is not FTP. Well, FTP runs over TCP. The similar thing that runs over UDP is called TFTP. Maybe that example doesn't make your point as well you'd have liked. There may be good reasons to "hard-wire" an application layer protocol to a particular transport layer. There are also cases when that "hard-wiring" happens as a matter of default, convenience, or lack of explicit consideration, rather than as a matter of design or architecture. I think we could argue ad infinitum into which category we should slot RFC 2865 RADIUS. :-) However, if the WG decides that RADIUS (the application protocol) can be transport-agnostic, I see no reason to get hung up on "naming rights". -- 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 Apr 14 19:36: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 1ADF13A6B39 for ; Mon, 14 Apr 2008 19:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 PFMTbCFwBYLb for ; Mon, 14 Apr 2008 19:36:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E98783A689F for ; Mon, 14 Apr 2008 19:36:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlaxK-0003rN-WE for radiusext-data@psg.com; Tue, 15 Apr 2008 02:31:35 +0000 Received: from [76.96.62.17] (helo=QMTA10.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlaxI-0003qz-9G for radiusext@ops.ietf.org; Tue, 15 Apr 2008 02:31:33 +0000 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id DUKo1Z0040vyq2s5A0Pb00; Tue, 15 Apr 2008 02:30:25 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA05.westchester.pa.mail.comcast.net with comcast id DeWu1Z009177aMo3R00000; Tue, 15 Apr 2008 02:31:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=1bz1owvqq8MA:10 a=No5EcEP4AAAA:8 a=vS3hKLICfvEp_cHFjy4A:9 a=Mxf0Syly6SRw3Zh-lBgA:7 a=6S_yrWvOAiglLDJnOT7Nqhc7LfsA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'radext mailing list'" References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> <4803A74D.1000708@nitros9.org> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 19:30:45 -0700 Message-ID: <001501c89ea0$bdf89500$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4803A74D.1000708@nitros9.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQ Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 11:50 AM: > Glen Zorn wrote: > ... >>> If this isn't RADIUS, then by the same standards, any HTTPS to HTTP >>> proxy isn't doing HTTP. >> >> Hmm. By that standard, it would seem that Diameter is RADIUS, too... > > No. I didn't mention an HTTPS to FTP proxy as being HTTP. This is what you said: "...a RadSec to RADIUS gateway involves terminating TCP, TLS, and forwarding the contents to RADIUS. If this isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't doing HTTP." A Diameter to RADIUS gateway involves terminating TCP (or SCTP), TLS, and forwarding the contents to RADIUS. If you really think that this is different from your HTTPS->HTTP example, perhaps it's because you are conveniently ignoring the fact that HTTP is only defined over TCP. However, one could just as easily argue that HTTP != HTTPS, given the need for different port numbers... > >> I don't think that I said anything about good or evil :-), but you >> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & >> that's not a problem. The problem would arise if someone claimed >> that it was because, 'Well, you can build a gateway'. > > The protocols being transported on IPv4 can also be > transported on IPv6. I really don't know how that is relevant. Dropping down a layer or 2, the same protocols can be carried by both Ethernet & ATM. Are you going to claim that they are somehow compatible (backward, forward or upside-down)? > Similarly, UDP transport + RADIUS application > protocol is... RADIUS. TCP transport + RADIUS application protocol > is... RADIUS. I know that you have read RFC 2865 (probably more often than I), so you know that there is no such thing as a standard "RADIUS application protocol", defined w/o regard for the underlying transport. > > The only way to call RadSec something other than RADIUS is > if you say that FTP over IPv6 is not FTP. After all, FTP was > for IPv4, I can't find any mention of IPv4 in RFC 959; it does mention TCP, however. Would FTPoUDP also be FTP? How would FTP & FTPoUDP interoperate? These questions seem much more to the point, I think. > and IPv6 is a new-fangled transport... so FTP over > IPv6 is not FTP... it's "magic". One more time: the version of IP being used is transparent & therefore irrelevant to FTP. UDP transport is forever enshrined in RFC 2865, however; maybe that's a bad thing, but it's true nonetheless. > > 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: -- 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 Apr 14 19:51:06 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 F27CB3A6D07 for ; Mon, 14 Apr 2008 19:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 z+qhbHvX0r7H for ; Mon, 14 Apr 2008 19:51:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E12D3A6C5C for ; Mon, 14 Apr 2008 19:51:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlbDK-0005qv-OX for radiusext-data@psg.com; Tue, 15 Apr 2008 02:48:06 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlbDI-0005qX-2r for radiusext@ops.ietf.org; Tue, 15 Apr 2008 02:48:05 +0000 Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Demc1Z00D0Fqzac5100800; Tue, 15 Apr 2008 02:48:03 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA08.westchester.pa.mail.comcast.net with comcast id Denb1Z004177aMo3U00000; Tue, 15 Apr 2008 02:48:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=1bz1owvqq8MA:10 a=No5EcEP4AAAA:8 a=bE8-BP5Cdmgo6Tl0WLIA:9 a=0glkbHYAWztWxf1gpm0A:7 a=dBKeqMsHv_u4NO4IbZXooWlpTYQA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> <4803A74D.1000708@nitros9.org> <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 19:47:27 -0700 Message-ID: <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcieYdv/Dve1K2oWRxuAKjN8MK5bawAAC1bQAA//hYA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 12:17 PM: ... > > However, if the WG decides that RADIUS (the application > protocol) can be transport-agnostic, I see no reason to get hung up > on "naming rights". First, the WG would have to _define_ RADIUS "the application protocol", since it doesn't exist w/o reference to the underlying transport. Maybe you have your own reasons for not wanting to change the name, but I do wish that this charade of claiming "backward compatibility" would come to an end. Even the creators of RADSEC have conceded that it's not RADIUS, why can't 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: -- 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 Apr 14 22:30: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 1544A3A6C75 for ; Mon, 14 Apr 2008 22:30:40 -0700 (PDT) X-Quarantine-ID: <8wNhCf9fgAYA> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 8wNhCf9fgAYA for ; Mon, 14 Apr 2008 22:30:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EAE03A6A7F for ; Mon, 14 Apr 2008 22:30:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jldfs-000K59-Lm for radiusext-data@psg.com; Tue, 15 Apr 2008 05:25:44 +0000 Received: from [65.54.246.210] (helo=BAY0-OMC3-S10.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jldfq-000K4t-81 for radiusext@ops.ietf.org; Tue, 15 Apr 2008 05:25:43 +0000 Received: from hotmail.com ([10.4.31.20]) by BAY0-OMC3-S10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 22:25:41 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Apr 2008 22:25:41 -0700 Message-ID: Received: from 131.107.0.105 by BLU137-DAV10.phx.gbl with DAV; Tue, 15 Apr 2008 05:25:37 +0000 X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'Glen Zorn'" , "'Alan DeKok'" Cc: "'radext mailing list'" References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> <4803A74D.1000708@nitros9.org> <001501c89ea0$bdf89500$33da787c@arubanetworks.com> In-Reply-To: <001501c89ea0$bdf89500$33da787c@arubanetworks.com> Subject: SNMP vs. RADIUS transport mappings Date: Mon, 14 Apr 2008 22:25:30 -0700 Message-ID: <000901c89eb9$1ee14fc0$5ca3ef40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYA= Content-Language: en-us X-OriginalArrivalTime: 15 Apr 2008 05:25:41.0336 (UTC) FILETIME=[2561BD80:01C89EB9] Sender: owner-radiusext@ops.ietf.org Precedence: bulk >UDP transport is forever enshrined in RFC 2865, >however; maybe that's a bad thing, but it's true nonetheless. How is this different from say, SNMP? The original transport mappings for SNMP (RFC 1089, 1906) were all datagram transports. The logic for SNMP over UDP was quite well enshrined. For example, see the following discussion, which has some parallels with RFC 2865 Section 2.4: http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm Yet, RFC 3430 defined SNMP over TCP: http://www.ietf.org/rfc/rfc3430.txt Normative references included the following: Transport Mappings for SNMP: http://www.ietf.org/rfc/rfc3417.txt SNMP applications: http://www.ietf.org/rfc/rfc3413.txt An Architecture for Describing SNMP Management Frameworks: http://www.ietf.org/rfc/rfc3411.txt -- 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 Apr 14 23:03: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 A967E3A6EBA for ; Mon, 14 Apr 2008 23:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=0.929, 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 lrXwvAzYqyms for ; Mon, 14 Apr 2008 23:03:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F98328C383 for ; Mon, 14 Apr 2008 23:03:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JleDz-000OAS-7M for radiusext-data@psg.com; Tue, 15 Apr 2008 06:00:59 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JleDw-000O9y-1u for radiusext@ops.ietf.org; Tue, 15 Apr 2008 06:00:57 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4194776F44; Tue, 15 Apr 2008 08:00:55 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 36AFF76F42; Tue, 15 Apr 2008 08:00:55 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" , radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 08:00:48 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> In-Reply-To: <001601c89ea3$12f2f7b0$33da787c@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 --nextPart2806951.UGRgC5AscT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > First, the WG would have to _define_ RADIUS "the application protocol", > since it doesn't exist w/o reference to the underlying transport. Maybe > you have your own reasons for not wanting to change the name, but I do > wish that this charade of claiming "backward compatibility" would come > to an end. Even the creators of RADSEC have conceded that it's not > RADIUS, why can't you? Well, in case you are referring to me in IETF-71, I admitted that there are= =20 non-trivial operational differences between the two transports, and that th= e=20 characteristics of a stateful transport need to taken into account properly= =2E=20 That makes it *different from RADIUS over UDP*, but not substantially=20 different from RADIUS *at all*. Even you conceded to saying that the=20 innermost PDU still remains as it is, so if nothing else, there is a core o= f=20 RADIUS embedded. And I would be surprised if you don't see yourself that=20 backwards compatibility is considerably easier if this PDU can be repackage= d=20 into a new transport without changing it (except the changes that any RADIU= S=20 apcket undergoes anyway on a RADIUS proxy, re-signing with its own shared=20 secret). In general, I see this discussion "is it different or not?" as rather=20 pointless in the real world. Whatever one's perceived opinion or perceived= =20 outcome is, it doesn't change anything in the protocol itself. 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 --nextPart2806951.UGRgC5AscT 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) iD8DBQBIBESV+jm90f8eFWYRAv1KAJ0Wb+dFkige3SHBWJaG9EpxoBzNDQCfTwnz mHV2Nzdn3LQh+/L8EgEjLJY= =Fqpw -----END PGP SIGNATURE----- --nextPart2806951.UGRgC5AscT-- -- 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 Apr 14 23:10: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 DFB7F3A6A91 for ; Mon, 14 Apr 2008 23:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=0.465, 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 l8L1OxNmWs32 for ; Mon, 14 Apr 2008 23:10:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 364723A67EE for ; Mon, 14 Apr 2008 23:09:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JleJt-000OtT-7k for radiusext-data@psg.com; Tue, 15 Apr 2008 06:07:05 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JleJi-000OsP-AG for radiusext@ops.ietf.org; Tue, 15 Apr 2008 06:06:55 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7E9EB76F44; Tue, 15 Apr 2008 08:06:53 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 73B8976F42; Tue, 15 Apr 2008 08:06:53 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" , radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 08:06:52 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <4803A74D.1000708@nitros9.org> <001501c89ea0$bdf89500$33da787c@arubanetworks.com> In-Reply-To: <001501c89ea0$bdf89500$33da787c@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 --nextPart3044730.cxfaSqzMlr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > This is what you said: "...a RadSec to RADIUS gateway involves > terminating TCP, TLS, and forwarding the contents to RADIUS. If this > isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't > doing HTTP." A Diameter to RADIUS gateway involves terminating TCP (or > SCTP), TLS, and forwarding the contents to RADIUS. With the devil being in the detail: With RadSec to RADIUS, the incoming pac= ket=20 is already a RADIUS packet as soon as it is decoded from the TLS tunnel.=20 There is no translation of the content. With Diameter to RADIUS, non-trivial translations need to be done, some of= =20 which can't even be done at all right now (Accepts >4096 bytes payload, AVP= s=20 with >253 bytes). We have yet to see a Diameter translation agent that can = do=20 bijective translations from one to another and back again (which I personal= ly=20 see as the holy grail of compatibility). I doubt we will ever. With RadSec = to=20 RADIUS, this is a triviality. Greetings, Stefan Winter > If you really think=20 > that this is different from your HTTPS->HTTP example, perhaps it's > because you are conveniently ignoring the fact that HTTP is only defined > over TCP. However, one could just as easily argue that HTTP !=3D HTTPS, > given the need for different port numbers... > > >> I don't think that I said anything about good or evil :-), but you > >> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & > >> that's not a problem. The problem would arise if someone claimed > >> that it was because, 'Well, you can build a gateway'. > > > > The protocols being transported on IPv4 can also be > > transported on IPv6. > > I really don't know how that is relevant. Dropping down a layer or 2, > the same protocols can be carried by both Ethernet & ATM. Are you going > to claim that they are somehow compatible (backward, forward or > upside-down)? > > > Similarly, UDP transport + RADIUS application > > protocol is... RADIUS. TCP transport + RADIUS application protocol > > is... RADIUS. > > I know that you have read RFC 2865 (probably more often than I), so you > know that there is no such thing as a standard "RADIUS application > protocol", defined w/o regard for the underlying transport. > > > The only way to call RadSec something other than RADIUS is > > if you say that FTP over IPv6 is not FTP. After all, FTP was > > for IPv4, > > I can't find any mention of IPv4 in RFC 959; it does mention TCP, > however. Would FTPoUDP also be FTP? How would FTP & FTPoUDP > interoperate? These questions seem much more to the point, I think. > > > and IPv6 is a new-fangled transport... so FTP over > > IPv6 is not FTP... it's "magic". > > One more time: the version of IP being used is transparent & therefore > irrelevant to FTP. UDP transport is forever enshrined in RFC 2865, > however; maybe that's a bad thing, but it's true nonetheless. > > > 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: > > -- > 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: =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 --nextPart3044730.cxfaSqzMlr 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) iD8DBQBIBEX8+jm90f8eFWYRAiRWAJ4tx5u20QrUiX8Gu25TC66V+KP1GQCeOWd8 VE3clo7O85Ce2I4ozl3eaEg= =bxCQ -----END PGP SIGNATURE----- --nextPart3044730.cxfaSqzMlr-- -- 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 Apr 14 23:16: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 8C06A3A6B52 for ; Mon, 14 Apr 2008 23:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.562 X-Spam-Level: X-Spam-Status: No, score=0.562 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_50=0.001, 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 e4Uk55cgKFYF for ; Mon, 14 Apr 2008 23:16:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34E4F3A6DD3 for ; Mon, 14 Apr 2008 23:15:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JleKN-000Ox9-8g for radiusext-data@psg.com; Tue, 15 Apr 2008 06:07:35 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JleKK-000Owi-Du for radiusext@ops.ietf.org; Tue, 15 Apr 2008 06:07:34 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id B1CE076F44; Tue, 15 Apr 2008 08:07:31 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id A4E6876F42; Tue, 15 Apr 2008 08:07:31 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 08:07:30 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) 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 --nextPart3075395.GtWnT0v3Ms Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > This is a consensus call for acceptance of the RADEXT WG re-charter. The > consensus call will last until April 28, 2008. Please send email to the > list stating whether you are in favor or opposed to the RADEXT WG > re-charter proposal: In favour. 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 --nextPart3075395.GtWnT0v3Ms 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) iD8DBQBIBEYj+jm90f8eFWYRApvtAJ9D9nNJgdDTRZ70fcF4slhCEjzJfACggPZn VarwXR4w004UfqChnMWf0f4= =ECFg -----END PGP SIGNATURE----- --nextPart3075395.GtWnT0v3Ms-- -- 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 Apr 15 00:03: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 1D02728C394 for ; Tue, 15 Apr 2008 00:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 tgPrQ9mpJzzz for ; Tue, 15 Apr 2008 00:03:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D038928C0E1 for ; Tue, 15 Apr 2008 00:03:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlf8S-0004FK-PX for radiusext-data@psg.com; Tue, 15 Apr 2008 06:59:20 +0000 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlf8P-0004Eo-Aq for radiusext@ops.ietf.org; Tue, 15 Apr 2008 06:59:19 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA08.westchester.pa.mail.comcast.net with comcast id DinS1Z0071GhbT85800X00; Tue, 15 Apr 2008 06:58:04 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA07.westchester.pa.mail.comcast.net with comcast id Diyl1Z004177aMo3T00000; Tue, 15 Apr 2008 06:59:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=J1q9_UuuAAAA:8 a=48vgC7mUAAAA:8 a=No5EcEP4AAAA:8 a=KNHs4M8eYQH1JUOqiAkA:9 a=QFsijkMNen8HPx6ZeYAA:7 a=occOJH3EJwsv-fJYhN0xFRerP30A:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'radext mailing list'" , "'Alan DeKok'" References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> <4803A74D.1000708@nitros9.org> <001501c89ea0$bdf89500$33da787c@arubanetworks.com> Subject: RE: SNMP vs. RADIUS transport mappings Date: Tue, 15 Apr 2008 13:58:38 +0700 Message-ID: <002001c89ec6$2a0c6df0$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYAAAx2MsA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Tuesday, April 15, 2008 12:26 PM: >> UDP transport is forever enshrined in RFC 2865, however; maybe >> that's a bad thing, but it's true nonetheless. > > How is this different from say, SNMP? Here is the difference: RFC 1067, section 3.2.4 paragraph 2 says "Consistent with the goal of minimizing complexity of the management agent, the exchange of SNMP messages requires only an unreliable datagram service, and every message is entirely and independently represented by a single transport datagram. While this document specifies the exchange of messages via the UDP protocol [8], the mechanisms of the SNMP are generally suitable for use with a wide variety of transport services." It would appear to me that SNMP was designed _from the beginning_ with a variety of transports in mind; the fact that all of the transports defined for the next 14 years or so were connectionless just says that the original choice was a good one. Leaving aside the apologetics in section 2.4 of RFC 2865, contrast the above quotation with section 3, paragraph 1 of that document: "Exactly one RADIUS packet is encapsulated in the UDP Data field [4], where the UDP Destination Port field indicates 1812 (decimal)." Where is the wiggle room, the opening for a flexible transport mapping in that statement? There is none, the statement is flat, inflexible and quite specific. > > The original transport mappings for SNMP (RFC 1089, 1906) were all > datagram transports. > > The logic for SNMP over UDP was quite well enshrined. For > example, see the following discussion, which has some > parallels with RFC 2865 Section 2.4: > http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm > > Yet, RFC 3430 defined SNMP over TCP: > http://www.ietf.org/rfc/rfc3430.txt > > Normative references included the following: > > Transport Mappings for SNMP: > http://www.ietf.org/rfc/rfc3417.txt > SNMP applications: > http://www.ietf.org/rfc/rfc3413.txt > An Architecture for Describing SNMP Management Frameworks: > http://www.ietf.org/rfc/rfc3411.txt > > > > > > > > > > > -- > 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 Tue Apr 15 00:27: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 634723A69F8 for ; Tue, 15 Apr 2008 00:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, 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 eCheGlYe9eO2 for ; Tue, 15 Apr 2008 00:27:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C3E73A6AE9 for ; Tue, 15 Apr 2008 00:27:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlfVm-0006B3-My for radiusext-data@psg.com; Tue, 15 Apr 2008 07:23:26 +0000 Received: from [218.214.125.86] (helo=zulu.open.com.au) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlfVk-0006Ac-2L for radiusext@ops.ietf.org; Tue, 15 Apr 2008 07:23:25 +0000 Received: from localhost (localhost [IPv6:::1]) by zulu.open.com.au (Postfix) with ESMTP id 9E5D19CBC6; Tue, 15 Apr 2008 17:23:20 +1000 (EST) From: Mike McCauley To: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 17:23:19 +1000 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804151723.19576.mikem@open.com.au> Sender: owner-radiusext@ops.ietf.org Precedence: bulk > This is a consensus call for acceptance of the RADEXT WG re-charter. The > consensus call will last until April 28, 2008. Please send email to the > list stating whether you are in favor or opposed to the RADEXT WG > re-charter proposal: In favour. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 -- 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 Apr 15 00:51:20 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 2EB4F3A6AEF for ; Tue, 15 Apr 2008 00:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 Mptjk+ZcFfqr for ; Tue, 15 Apr 2008 00:51:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 10DC33A693E for ; Tue, 15 Apr 2008 00:51:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlfti-0008mx-9Q for radiusext-data@psg.com; Tue, 15 Apr 2008 07:48:10 +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 1Jlftf-0008mc-G6 for radiusext@ops.ietf.org; Tue, 15 Apr 2008 07:48:08 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA09.westchester.pa.mail.comcast.net with comcast id DjhD1Z0070cZkys5900K00; Tue, 15 Apr 2008 07:46:11 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA10.westchester.pa.mail.comcast.net with comcast id DjnY1Z003177aMo3W00000; Tue, 15 Apr 2008 07:48:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=1bz1owvqq8MA:10 a=PX_SiWGEAAAA:8 a=58sNSKpVrOPWFe4v_3sA:9 a=NrNxcO_ERk0azpJP8pQA:7 a=1kJNH-3L6Dfx5yYPdcbTwuz9xPsA:4 a=RkZ5GBXlPyUA:10 a=ufO146cb3fEA:10 From: "Glen Zorn" To: "'Stefan Winter'" , References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 14:47:24 +0700 Message-ID: <003501c89ecc$f9fa5a30$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200804150800.53961.stefan.winter@restena.lu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcievhQ0g2LKyBc2QjOnpd3eYXax3gADiF8w Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter scribbled on Tuesday, April 15, 2008 1:01 PM: > Hi, >=20 >> First, the WG would have to _define_ RADIUS "the application >> protocol", since it doesn't exist w/o reference to the underlying >> transport. Maybe you have your own reasons for not wanting to change >> the name, but I do wish that this charade of claiming "backward >> compatibility" would come to an end. Even the creators of RADSEC >> have conceded that it's not RADIUS, why can't you? >=20 > Well, in case you are referring to me in IETF-71, I admitted > that there are non-trivial operational differences between the > two transports, and that the characteristics of a stateful > transport need to taken into account properly. > That makes it *different from RADIUS over UDP*, but not > substantially different from RADIUS *at all*.=20 OK, one more time: you are making a distinction that doesn't exist.=20 > Even you > conceded to saying that the innermost PDU still remains as it > is, so if nothing else, there is a core of RADIUS embedded. No, there is something that has yet to be defined embedded because RADIUS simply doesn't exist over a non-UDP transport. > And I would be surprised if you don't see yourself that > backwards compatibility is considerably easier if this PDU can > be repackaged into a new transport without changing it (except > the changes that any RADIUS apcket undergoes anyway on a > RADIUS proxy, re-signing with its own shared secret). >=20 > In general, I see this discussion "is it different or not?" as > rather pointless in the real world. Whatever one's perceived > opinion or perceived outcome is, it doesn't change anything in the > protocol itself.=20 >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER >=20 > Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education > Nationale et de la Recherche Ingenieur Forschung & Entwicklung >=20 > 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 422473 -- 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 Apr 15 01:03: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 E8EF03A6B66 for ; Tue, 15 Apr 2008 01:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 aTSqsN8YbTYw for ; Tue, 15 Apr 2008 01:03:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62B9C3A6AE9 for ; Tue, 15 Apr 2008 01:03:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlg46-000A0O-On for radiusext-data@psg.com; Tue, 15 Apr 2008 07:58:54 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlg44-000A04-0n for radiusext@ops.ietf.org; Tue, 15 Apr 2008 07:58:53 +0000 Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Djsx1Z00G0xGWP85100f00; Tue, 15 Apr 2008 07:58:51 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA12.westchester.pa.mail.comcast.net with comcast id DjyN1Z006177aMo3Y00000; Tue, 15 Apr 2008 07:58:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=1bz1owvqq8MA:10 a=No5EcEP4AAAA:8 a=PX_SiWGEAAAA:8 a=pdmunKEM-Mw_CcPY9s8A:9 a=IaLFkmVAAhySJiPnmUIA:7 a=GSvkXltHjbYe3paCZAwIazFeJAUA:4 a=RkZ5GBXlPyUA:10 a=ufO146cb3fEA:10 From: "Glen Zorn" To: "'Stefan Winter'" Cc: References: <4803A74D.1000708@nitros9.org> <001501c89ea0$bdf89500$33da787c@arubanetworks.com> <200804150806.52923.stefan.winter@restena.lu> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 14:58:15 +0700 Message-ID: <003d01c89ece$7e11da90$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200804150806.52923.stefan.winter@restena.lu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acievu7z/CgfZ8eaQwe9nPJgrt0D1wADlDUQ Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter scribbled on Tuesday, April 15, 2008 1:07 PM: > Hi, >=20 >> This is what you said: "...a RadSec to RADIUS gateway involves >> terminating TCP, TLS, and forwarding the contents to RADIUS. If this >> isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy >> isn't doing HTTP." A Diameter to RADIUS gateway involves terminating >> TCP (or SCTP), TLS, and forwarding the contents to RADIUS. >=20 > With the devil being in the detail: With RadSec to RADIUS, the > incoming packet is already a RADIUS packet as soon as it is decoded > from the TLS tunnel. There is no translation of the content. > With Diameter to RADIUS, non-trivial translations need to be > done, some of which can't even be done at all right now > (Accepts >4096 bytes payload, AVPs with >253 bytes). We have > yet to see a Diameter translation agent that can do bijective > translations from one to another and back again (which I > personally see as the holy grail of compatibility). I doubt we > will ever. With RadSec to RADIUS, this is a triviality. I don't know how we got started down this path of arguing about the complexity of building protocol gateways; my point is that if the only way for two protocols to interoperate is through a gateway, those protocols _are not_ compatible except in the most trivial of senses, like ATM & Ethernet or IPv4 & v6 or RADIUS and RadSec. Therefore, stop claiming backward compatibility if for no other reason that it's embarrassing to associated with such a nonsensical claim. >=20 > Greetings, >=20 > Stefan Winter >=20 >> If you really think >> that this is different from your HTTPS->HTTP example, perhaps it's >> because you are conveniently ignoring the fact that HTTP is only >> defined over TCP. However, one could just as easily argue that HTTP >> !=3D HTTPS, given the need for different port numbers... >>=20 >>>> I don't think that I said anything about good or evil :-), but you >>>> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & >>>> that's not a problem. The problem would arise if someone claimed >>>> that it was because, 'Well, you can build a gateway'. >>>=20 >>> The protocols being transported on IPv4 can also be transported on >>> IPv6. >>=20 >> I really don't know how that is relevant. Dropping down a layer or >> 2, the same protocols can be carried by both Ethernet & ATM. Are you >> going to claim that they are somehow compatible (backward, forward >> or upside-down)?=20 >>=20 >>> Similarly, UDP transport + RADIUS application protocol is... RADIUS. >>> TCP transport + RADIUS application protocol is... RADIUS. >>=20 >> I know that you have read RFC 2865 (probably more often than I), so >> you know that there is no such thing as a standard "RADIUS >> application protocol", defined w/o regard for the underlying >> transport.=20 >>=20 >>> The only way to call RadSec something other than RADIUS is if you >>> say that FTP over IPv6 is not FTP. After all, FTP was for IPv4, >>=20 >> I can't find any mention of IPv4 in RFC 959; it does mention TCP, >> however. Would FTPoUDP also be FTP? How would FTP & FTPoUDP >> interoperate? These questions seem much more to the point, I think. >>=20 >>> and IPv6 is a new-fangled transport... so FTP over >>> IPv6 is not FTP... it's "magic". >>=20 >> One more time: the version of IP being used is transparent & >> therefore irrelevant to FTP. UDP transport is forever enshrined in >> RFC 2865, however; maybe that's a bad thing, but it's true >> nonetheless.=20 >>=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: >>=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: >=20 >=20 >=20 > -- > Stefan WINTER >=20 > Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education > Nationale et de la Recherche Ingenieur Forschung & Entwicklung >=20 > 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 422473 -- 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 Apr 15 01:18: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 335FA28C1E2 for ; Tue, 15 Apr 2008 01:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 1etcRUdN-DBd for ; Tue, 15 Apr 2008 01:18:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C04363A6C22 for ; Tue, 15 Apr 2008 01:18:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlgKU-000Bpw-4y for radiusext-data@psg.com; Tue, 15 Apr 2008 08:15:50 +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 1JlgKN-000BpO-VM for radiusext@ops.ietf.org; Tue, 15 Apr 2008 08:15:45 +0000 Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA03.westchester.pa.mail.comcast.net with comcast id Dk8Q1Z0060ldTLk5300P00; Tue, 15 Apr 2008 08:14:07 +0000 Received: from gzornt61 ([124.120.218.51]) by OMTA04.westchester.pa.mail.comcast.net with comcast id DkFD1Z006177aMo3Q00000; Tue, 15 Apr 2008 08:15:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=1bz1owvqq8MA:10 a=O9cG-cTD-0xtG7O3W7kA:9 a=gwSD-g4uEXP6almTFhXWBcdusJgA:4 a=ufO146cb3fEA:10 From: "Glen Zorn" To: "'Stefan Winter'" Cc: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 15:15:06 +0700 Message-ID: <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200804150800.53961.stefan.winter@restena.lu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcievhQ0g2LKyBc2QjOnpd3eYXax3gAEgoJQ Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter scribbled on Tuesday, April 15, 2008 1:01 PM: ... > That makes it *different from RADIUS over UDP*, but not > substantially different from RADIUS *at all*. OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not be the authoritative reference for "RADIUS *at all*". What is? I'd like to read it... ... -- 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 Apr 15 01:47:20 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 30E6B3A69DC for ; Tue, 15 Apr 2008 01:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[AWL=0.557, 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 XwfoBiVAjmD3 for ; Tue, 15 Apr 2008 01:47:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E398F3A6BD5 for ; Tue, 15 Apr 2008 01:47:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlgl5-000Eo8-6n for radiusext-data@psg.com; Tue, 15 Apr 2008 08:43:19 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlgkw-000ElG-26 for radiusext@ops.ietf.org; Tue, 15 Apr 2008 08:43:13 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 71FEA76F44; Tue, 15 Apr 2008 10:43:07 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 65F4776F43; Tue, 15 Apr 2008 10:43:07 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" , radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 10:43:02 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> In-Reply-To: <004001c89ed0$d8b0f100$33da787c@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 --nextPart5508601.2IVmT3lAKA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not be > the authoritative reference for "RADIUS *at all*". What is? I'd like > to read it... Okay, point taken. Since there's no source for RADIUS without entangled UDP= =20 transport, the RadSec I-D should have a section that states which parts of= =20 2865 are irrelevant when using a TCP transport. I.e. the draft should defin= e=20 the subset that matches the fuzzy expression of "RADIUS *at all*". I'll go through 2865 and list the spots. On a side note, 2865 has other hard-wired assumptions that aren't incredibl= y=20 valid today. Are we going to split hairs on every one of them? That would=20 mean making an update to 2865 though. Take for example 2. Operation [...] If the client is valid, the RADIUS server consults a database of user= s=20 to find the user whose name matches the request. The user entry in the=20 database contains a list of requirements which must be met to allow access= =20 for the user. This always includes verification of the password, but can also specify the client(s) or port(s) to which the user is allowed access. Enter EAP-TLS. Where's the database? What password?=20 I somehow wonder why the introduction of EAP-TLS went by silently without a= n=20 outcry that 2865 is too narrowly specified to allow this, by being hardwire= d=20 to a specific set of auth backends. Back then, an RFC updated 2865 for EAP,= =20 and that was it. The fuss argumentation would be and could have been in a=20 similar direction like the one we have here. It's a matter of personal liki= ng=20 or disliking a specific update I guess. 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 --nextPart5508601.2IVmT3lAKA 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) iD8DBQBIBGqa+jm90f8eFWYRArV6AJ9BM7YqTw7gSQbSr0skXVDLYAPI8QCgh64u 6NeQzFhZL/NS34TY0kT8254= =qANE -----END PGP SIGNATURE----- --nextPart5508601.2IVmT3lAKA-- -- 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 Apr 15 01:54: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 4CB393A6AFF for ; Tue, 15 Apr 2008 01:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 Kt+qnINDDA+H for ; Tue, 15 Apr 2008 01:54:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 404103A677E for ; Tue, 15 Apr 2008 01:54:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlgrW-000FXg-9S for radiusext-data@psg.com; Tue, 15 Apr 2008 08:49:58 +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 1JlgrT-000FXD-It for radiusext@ops.ietf.org; Tue, 15 Apr 2008 08:49:56 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 32CCDA7072; Tue, 15 Apr 2008 01:49:45 -0700 (PDT) Message-ID: <48046B45.20008@deployingradius.com> Date: Tue, 15 Apr 2008 10:45:57 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> In-Reply-To: <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> 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 Glen Zorn wrote: > OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not be > the authoritative reference for "RADIUS *at all*". What is? I'd like > to read it... The authoritative reference for RADIUS is this WG. If the consensus is to add bells, whistles, or flying monkeys to RADIUS, then that is our perogative. The alternative is to worship at the holy shrine of the existing RFC's, which were handed down from on high by the holy priests of RADIUS. As mere mortals, we are incapable of changing holy writ, and must confess that the RFC's are perfect. I shall therefore submit a request to the RFC editor admitting that RFC 5080 is blasphemy, as it points out *errors* in the original RFC's. It should therefore be withdrawn immediately, before the holy priests of RADIUS burn me at the stake. 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 Tue Apr 15 03:35: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 666E028C37B for ; Tue, 15 Apr 2008 03:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 HQGMOPQ8GpiR for ; Tue, 15 Apr 2008 03:35:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81A9E3A6E74 for ; Tue, 15 Apr 2008 03:35:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JliQx-0000J2-W2 for radiusext-data@psg.com; Tue, 15 Apr 2008 10:30:39 +0000 Received: from [208.179.69.44] (helo=WV-MAILSRV2.strixsystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JliQp-0000I3-Bb for radiusext@ops.ietf.org; Tue, 15 Apr 2008 10:30:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89EE3.BA9F6E73" Subject: RE: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 03:30:28 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181919@wv-mailsrv2.strixsystems.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMvy5gK3cLxReSdeE79BoIG25qwAryLSQ References: From: "Matt Holdrege" To: , Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C89EE3.BA9F6E73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm in favor of adding improved functionality to RADIUS. What that actually means appears to be of considerable debate. =20 As far as backwards compatibility is concerned, I hope everyone realizes that RADIUS is an extremely well installed *SERVICE* and a completely new *SERVICE* would be a waste of everyone's time. People can scream and yell about having to twiddle bits in their servers and proxies but I don't care. It is the clients that you should really be concerned with. =20 -Matt =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard_Aboba@hotmail.com Sent: Monday, April 14, 2008 3:20 PM To: radiusext@ops.ietf.org Subject: Consensus Call on RADEXT WG re-charter =20 This is a consensus call for acceptance of the RADEXT WG re-charter. The consensus call will last until April 28, 2008. Please send email to the list=20 stating whether you are in favor or opposed to the RADEXT WG re-charter proposal:=20 =20 =20 ------_=_NextPart_001_01C89EE3.BA9F6E73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m in favor of adding improved functionality to = RADIUS. What that actually means appears to be of considerable = debate.

 

As far as backwards compatibility is concerned, I hope = everyone realizes that RADIUS is an extremely well installed *SERVICE* and = a completely new *SERVICE* would be a waste of everyone’s = time. People can scream and yell about having to twiddle bits in their servers = and proxies but I don’t care. It is the clients that you should really = be concerned with.

 

-Matt

 

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On = Behalf Of Bernard_Aboba@hotmail.com
Sent: Monday, April 14, 2008 3:20 PM
To: radiusext@ops.ietf.org
Subject: Consensus Call on RADEXT WG = re-charter

 

This is a consensus call for acceptance of the RADEXT WG = re-charter.  The

consensus call will last until April 28, 2008.  Please send email to the = list

stating whether you are in favor or opposed to the RADEXT WG = re-charter

proposal:

 

 

------_=_NextPart_001_01C89EE3.BA9F6E73-- -- 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 Apr 15 05:59: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 9ABE328C3DD for ; Tue, 15 Apr 2008 05:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[AWL=-0.326, 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 bia32psUvq6Q for ; Tue, 15 Apr 2008 05:59:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9129328C11E for ; Tue, 15 Apr 2008 05:59:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlkg5-000Gy6-Bd for radiusext-data@psg.com; Tue, 15 Apr 2008 12:54:25 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlkg2-000Gxk-La for radiusext@ops.ietf.org; Tue, 15 Apr 2008 12:54:24 +0000 Received: (qmail 6494 invoked from network); 15 Apr 2008 08:54:21 -0400 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.1) by gumby.elbrysnetworks.com with SMTP; 15 Apr 2008 08:54:21 -0400 Message-ID: <4804A580.1060104@elbrysnetworks.com> Date: Tue, 15 Apr 2008 08:54:24 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter References: <400A74A604718E46BC9EE95677BAFF31181919@wv-mailsrv2.strixsystems.com> In-Reply-To: <400A74A604718E46BC9EE95677BAFF31181919@wv-mailsrv2.strixsystems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Matt Holdrege wrote: > As far as backwards compatibility is concerned, I hope everyone realizes > that RADIUS is an extremely well installed **SERVICE** and a completely > new **SERVICE** would be a waste of everyone’s time. People can scream > and yell about having to twiddle bits in their servers and proxies but I > don’t care. It is the clients that you should really be concerned with. Right. While I think the RADSEC folks indicate they have some client implementations, my impression of the work is that its more useful between the first-hop proxy and the home server. For the RADESC folks: Is there any reason that the first-hop proxy couldn't terminate a RADIUS (RADIUS over UDP) session with the NAS and originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream proxies or home server? -- 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 Apr 15 06:10:28 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 5D2033A69E1 for ; Tue, 15 Apr 2008 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=0.446, 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 qIDUVmsTVpG5 for ; Tue, 15 Apr 2008 06:10:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9385328C3F5 for ; Tue, 15 Apr 2008 06:10:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlkrs-000I4n-Or for radiusext-data@psg.com; Tue, 15 Apr 2008 13:06:36 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlkrj-000I3p-S1 for radiusext@ops.ietf.org; Tue, 15 Apr 2008 13:06:32 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 16EEE76F44; Tue, 15 Apr 2008 15:06:27 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 07D2976F43; Tue, 15 Apr 2008 15:06:27 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 15:06:22 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <400A74A604718E46BC9EE95677BAFF31181919@wv-mailsrv2.strixsystems.com> <4804A580.1060104@elbrysnetworks.com> In-Reply-To: <4804A580.1060104@elbrysnetworks.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) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2914078.NQhsPztXlm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804151506.26463.stefan.winter@restena.lu> X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk --nextPart2914078.NQhsPztXlm Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Right. While I think the RADSEC folks indicate they have some client > implementations, my impression of the work is that its more useful > between the first-hop proxy and the home server. > > For the RADESC folks: Is there any reason that the first-hop proxy > couldn't terminate a RADIUS (RADIUS over UDP) session with the NAS and > originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream > proxies or home server? That's perfectly possible. In fact, we had planned to deploy it exactly for= =20 the server-to-server use case.=20 It just happened that the use case of "APs in weird environments" *also*=20 showed up, and there was additional merit in having client gear that speaks= =20 RadSec itself. There is nothing that stops one from having RADIUS client gear and a RadSec= =20 server behind because the conversion is lossless. This is what happens for my own country deployment in the Luxembourg TLD:=20 upstream connection to the European root is via RadSec, while the connected= =20 institutions use plain RADIUS to talk to the TLD server. 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 --nextPart2914078.NQhsPztXlm 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) iD8DBQBIBKhS+jm90f8eFWYRAqDTAJ0UbRW9C7lJhifJrKgNkBTjA5kb0gCfYGia JVz4HAdqLzS5QAacrwQpuFk= =RGMV -----END PGP SIGNATURE----- --nextPart2914078.NQhsPztXlm-- -- 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 Apr 15 10:51:04 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 52CDB3A6913 for ; Tue, 15 Apr 2008 10:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.276 X-Spam-Level: X-Spam-Status: No, score=-5.276 tagged_above=-999 required=5 tests=[AWL=-0.781, 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 tkn3oc721QeF for ; Tue, 15 Apr 2008 10:51:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C84E28C400 for ; Tue, 15 Apr 2008 10:51:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlpDO-0000io-I3 for radiusext-data@psg.com; Tue, 15 Apr 2008 17:45:06 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlpDL-0000iG-MA for radiusext@ops.ietf.org; Tue, 15 Apr 2008 17:45:04 +0000 X-IronPort-AV: E=Sophos;i="4.25,661,1199692800"; d="scan'208";a="11087566" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 15 Apr 2008 10:44:52 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3FHiqkK002187; Tue, 15 Apr 2008 10:44:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3FHinVE029520; Tue, 15 Apr 2008 17:44:49 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 10:44:49 -0700 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: SNMP vs. RADIUS transport mappings Date: Tue, 15 Apr 2008 10:45:39 -0700 Message-ID: In-Reply-To: <000901c89eb9$1ee14fc0$5ca3ef40$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SNMP vs. RADIUS transport mappings Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYAAGg6B8A== References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> <4803A74D.1000708@nitros9.org> <001501c89ea0$bdf89500$33da787c@arubanetworks.com> <000901c89eb9$1ee14fc0$5ca3ef40$@com> From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , "Glen Zorn" , "Alan DeKok" Cc: "radext mailing list" X-OriginalArrivalTime: 15 Apr 2008 17:44:49.0685 (UTC) FILETIME=[670EC450:01C89F20] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1987; t=1208281492; x=1209145492; 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=20SNMP=20vs.=20RADIUS=20transport=20mappi ngs |Sender:=20; bh=52m28GEzc157u4LntfuiVyVb/Y/0j2Ckw8PJYHJFNYo=; b=A5VLVnYDfGTMOwWenOtZ5aDGiBYNyucmYQoNalZNwtZmX5JTIRMSxT9rwc R3a5A6Ipyue9YmAWjNlHrXRNA+6I4eOHy6diTJF9DhXjgaTYUaGDMiTp6D/X n2ToNIQ3IlQkN/VHS7enojOQtKJwApbmytXHeT7VIV+iCoqsIR4ds=; 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 SNMPv3 made the effort to define an architecture that created abstract interfaces between modules such as security and transport as is defined in the architecture documents you cite. This makes it possible to implement new transport and security mechanisms within the SNMPv3 architecture (although the architecture has to be extended somewhat to accommodate a transport security mechanism). RADIUS has no such formal modular architecture. I suppose that one could be retro-fitted, but it hasn't been done yet. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, April 14, 2008 10:26 PM > To: 'Glen Zorn'; 'Alan DeKok' > Cc: 'radext mailing list' > Subject: SNMP vs. RADIUS transport mappings >=20 > >UDP transport is forever enshrined in RFC 2865, however;=20 > maybe that's a=20 > >bad thing, but it's true nonetheless. >=20 > How is this different from say, SNMP?=20 >=20 > The original transport mappings for SNMP (RFC 1089, 1906)=20 > were all datagram transports. >=20 > The logic for SNMP over UDP was quite well enshrined. For=20 > example, see the following discussion, which has some=20 > parallels with RFC 2865 Section 2.4: > http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm >=20 > Yet, RFC 3430 defined SNMP over TCP: > http://www.ietf.org/rfc/rfc3430.txt >=20 > Normative references included the following: >=20 > Transport Mappings for SNMP: > http://www.ietf.org/rfc/rfc3417.txt > SNMP applications: > http://www.ietf.org/rfc/rfc3413.txt > An Architecture for Describing SNMP Management Frameworks: > http://www.ietf.org/rfc/rfc3411.txt >=20 >=20 >=20 >=20 >=20 > =20 >=20 >=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 Tue Apr 15 11:12: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 A59EF3A69CD for ; Tue, 15 Apr 2008 11:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.001, 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 FcG2YE8wvdd3 for ; Tue, 15 Apr 2008 11:12:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 988913A6ABA for ; Tue, 15 Apr 2008 11:12:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlpZK-00040u-16 for radiusext-data@psg.com; Tue, 15 Apr 2008 18:07:46 +0000 Received: from [208.179.69.44] (helo=WV-MAILSRV2.strixsystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlpZE-0003zt-DW for radiusext@ops.ietf.org; Tue, 15 Apr 2008 18:07:44 +0000 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: SNMP vs. RADIUS transport mappings Date: Tue, 15 Apr 2008 11:07:46 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181955@wv-mailsrv2.strixsystems.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SNMP vs. RADIUS transport mappings Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYAAGg6B8AAA9cNQ References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> <4803A74D.1000708@nitros9.org> <001501c89ea0$bdf89500$33da787c@arubanetworks.com> <000901c89eb9$1ee14fc0$5ca3ef40$@com> From: "Matt Holdrege" To: "Joseph Salowey (jsalowey)" , "Bernard Aboba" , "Glen Zorn" , "Alan DeKok" Cc: "radext mailing list" Sender: owner-radiusext@ops.ietf.org Precedence: bulk SNMP had the full support of the IAB and IESG who pushed many years for the full development of the protocol. RADIUS has been denigrated by a long list of IAB and IESG leadership as something that never should have been allowed to happen and should not have a place in any future IETF protocol development. I don't know if it would be possible to get the level of support needed to do what you are suggesting, but it would have been nice to have done that work back in the 90's. But all that is IETF politics and future RADIUS development shouldn't worry too much about past politics. -Matt -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Joseph Salowey (jsalowey) Sent: Tuesday, April 15, 2008 7:46 PM To: Bernard Aboba; Glen Zorn; Alan DeKok Cc: radext mailing list Subject: RE: SNMP vs. RADIUS transport mappings SNMPv3 made the effort to define an architecture that created abstract interfaces between modules such as security and transport as is defined in the architecture documents you cite. This makes it possible to implement new transport and security mechanisms within the SNMPv3 architecture (although the architecture has to be extended somewhat to accommodate a transport security mechanism). RADIUS has no such formal modular architecture. I suppose that one could be retro-fitted, but it hasn't been done yet. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, April 14, 2008 10:26 PM > To: 'Glen Zorn'; 'Alan DeKok' > Cc: 'radext mailing list' > Subject: SNMP vs. RADIUS transport mappings >=20 > >UDP transport is forever enshrined in RFC 2865, however;=20 > maybe that's a=20 > >bad thing, but it's true nonetheless. >=20 > How is this different from say, SNMP?=20 >=20 > The original transport mappings for SNMP (RFC 1089, 1906)=20 > were all datagram transports. >=20 > The logic for SNMP over UDP was quite well enshrined. For=20 > example, see the following discussion, which has some=20 > parallels with RFC 2865 Section 2.4: > http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm >=20 > Yet, RFC 3430 defined SNMP over TCP: > http://www.ietf.org/rfc/rfc3430.txt >=20 > Normative references included the following: >=20 > Transport Mappings for SNMP: > http://www.ietf.org/rfc/rfc3417.txt > SNMP applications: > http://www.ietf.org/rfc/rfc3413.txt > An Architecture for Describing SNMP Management Frameworks: > http://www.ietf.org/rfc/rfc3411.txt >=20 >=20 >=20 >=20 >=20 > =20 >=20 >=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: -- 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 Apr 15 13:13:24 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 A64073A6825 for ; Tue, 15 Apr 2008 13:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.211 X-Spam-Level: X-Spam-Status: No, score=-5.211 tagged_above=-999 required=5 tests=[AWL=-0.716, 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 KzPmUHhfttEX for ; Tue, 15 Apr 2008 13:13:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41EDB3A6A87 for ; Tue, 15 Apr 2008 13:13:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlrQM-000Hbw-SI for radiusext-data@psg.com; Tue, 15 Apr 2008 20:06:38 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlrQJ-000HbP-Na for radiusext@ops.ietf.org; Tue, 15 Apr 2008 20:06:37 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2008 13:06:35 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3FK6Ymv016413; Tue, 15 Apr 2008 13:06:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3FK6YTk008402; Tue, 15 Apr 2008 20:06:34 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 13:06:34 -0700 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: RADEXT WG re-charter Date: Tue, 15 Apr 2008 13:07:24 -0700 Message-ID: In-Reply-To: <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADEXT WG re-charter Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFAAAers8AAWnCbA References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> From: "Joseph Salowey (jsalowey)" To: "David B. Nelson" , , "Glen Zorn" Cc: X-OriginalArrivalTime: 15 Apr 2008 20:06:34.0466 (UTC) FILETIME=[344D5C20:01C89F34] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3504; t=1208289994; x=1209153994; c=relaxed/simple; s=sjdkim4002; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=rnyo5RQGguxc8LihqxMd1hh6c5boYtNtk7MTNty7Vsc=; b=DOVeoyPa1Bp+QmEbclY32V+WyiJGTlG/89J1aR/ro2P0RpseyhfgIz3Gw+ BBH1mCL3z8sgB52Su877D/kt1fYrgHcT0FCbA4QqxI9vE7i2L40/cT2PU7Ju YfZM6iEr09; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-radiusext@ops.ietf.org Precedence: bulk There are a few reasons why you would want to wrap keys separately from other data. As you mentioned, the recommended algorithms for key wrap may not be suitable for encrypting bulk data without special consideration and some bulk data encryption algorithms may not be recommended for key wrap without special consideration. Another reason is that you may want the entity that handles the keys and their context to be different from the entity that handles the rest of the attributes. Neither of these reasons forces you to have encryption tied directly to the key attribute. It is convenient since one is very often interested in encrypting keys, but you can achieve the same thing with a generic encryption attribute if you take care. You need to support multiple pieces of data encrypted with different keys (key IDs, alg IDs, message boundaries, etc.) in the same message and you need to make sure that the various supported encryption algorithms are used correctly (type of cleartext, sufficient randomization, integrity protection, etc.). These things don't necessarily happen automatically or come for free.=20 If you don't consider keys as part of the data you are wrapping for crypto agility, I'm not sure you will end up with a result that is very useful. =20 Joe=20 > -----Original Message----- > From: David B. Nelson [mailto:dnelson@elbrysnetworks.com]=20 > Sent: Monday, April 14, 2008 10:29 AM > To: radiusext@ops.ietf.org; 'Glen Zorn' > Cc: Joseph Salowey (jsalowey); Bernard_Aboba@hotmail.com > Subject: RE: RADEXT WG re-charter >=20 > Glen Zorn writes... >=20 > > 'Frankly, my dear, I don't give a damn.'=20 >=20 > Cute... >=20 > > It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt=20 > > was posted ... for at least 3 years there have been at 2 (or more)=20 > > independent, interoperable implementations that were FIPS-certified. >=20 > Given that there are implementations of this key-wrap scheme,=20 > presumably using VSAs, it might be well to publish an=20 > Information RFC, describing the actual implementations, using=20 > those VSAs. >=20 > > But wait! Let's spend a little (lot) more time conjecturing about=20 > > another way, a way to solve "the general problem" (AKA "boiling the=20 > > ocean" if it's a proposal we don't care for). Well, gosh,=20 > no thanks,=20 > > but you guys go ahead & have fun! >=20 > RADEXT has a chartered work item to address crypto-agility. =20 > We have requirements for this wok, and we now have an ID=20 > capturing those requirements. We don't have a requirement to=20 > specifically address key-wrap, as a separate problem. My=20 > questions is whether RADEXT really needs to create two drafts=20 > to satisfy the crypto-agility work item, one for key-wrap and=20 > one for general purpose encrypted attributes. The fact that=20 > solutions, and drafts, exist to address key-wrap and=20 > encrypted attributes separately is a point in favor of=20 > retaining the separation. I'm just questioning whether=20 > that's a sufficient basis on which to decide that we need=20 > such separation of concerns. >=20 > If the consensus us of the WG is that we should proceed with=20 > separate documents for key-wrap and general crypto-agility,=20 > we can propose doing that in our revised charter. It would=20 > be nice, however, to have a reason beyond the existence of (4=20 > year old) drafts that are structured that way. >=20 >=20 >=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 Tue Apr 15 14:02: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 A6C233A6F36 for ; Tue, 15 Apr 2008 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, 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 YL-rwpXS4ZfX for ; Tue, 15 Apr 2008 14:02:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 569943A6C5A for ; Tue, 15 Apr 2008 14:02:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlsEj-000OS7-TP for radiusext-data@psg.com; Tue, 15 Apr 2008 20:58:41 +0000 Received: from [218.214.125.86] (helo=zulu.open.com.au) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlsEg-000ORj-V1 for radiusext@ops.ietf.org; Tue, 15 Apr 2008 20:58:40 +0000 Received: from localhost (localhost [IPv6:::1]) by zulu.open.com.au (Postfix) with ESMTP id 7AD9A9AB68; Wed, 16 Apr 2008 06:58:34 +1000 (EST) From: Mike McCauley To: "David B. Nelson" Subject: Re: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 06:58:33 +1000 User-Agent: KMail/1.8.2 Cc: radiusext@ops.ietf.org References: <400A74A604718E46BC9EE95677BAFF31181919@wv-mailsrv2.strixsystems.com> <4804A580.1060104@elbrysnetworks.com> In-Reply-To: <4804A580.1060104@elbrysnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200804160658.34248.mikem@open.com.au> Sender: owner-radiusext@ops.ietf.org Precedence: bulk On Tuesday 15 April 2008 22:54, David B. Nelson wrote: > Matt Holdrege wrote: > > As far as backwards compatibility is concerned, I hope everyone realizes > > that RADIUS is an extremely well installed **SERVICE** and a completely > > new **SERVICE** would be a waste of everyone=92s time. People can scream > > and yell about having to twiddle bits in their servers and proxies but I > > don=92t care. It is the clients that you should really be concerned wit= h. > > Right. While I think the RADSEC folks indicate they have some client > implementations, my impression of the work is that its more useful > between the first-hop proxy and the home server. > > For the RADESC folks: Is there any reason that the first-hop proxy > couldn't terminate a RADIUS (RADIUS over UDP) session with the NAS and > originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream > proxies or home server? Thats a very common model which is permitted by the spec and supported by o= ur=20 implementation (at least), with the view of protecting the traffic while it= =20 traverses the internet but without requiring RadSec capable clients. Cheers. > > > > -- > 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: =2D-=20 Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server=20 anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,=20 Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,=20 TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- 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 Apr 15 14:56: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 9D7143A695D for ; Tue, 15 Apr 2008 14:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 W4vxvLjnmM4f for ; Tue, 15 Apr 2008 14:56:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 548143A67A3 for ; Tue, 15 Apr 2008 14:56:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jlt4h-0003si-0G for radiusext-data@psg.com; Tue, 15 Apr 2008 21:52:23 +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 1Jlt4e-0003sI-Bn for radiusext@ops.ietf.org; Tue, 15 Apr 2008 21:52:21 +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 CEF12A7137; Tue, 15 Apr 2008 14:52:12 -0700 (PDT) Message-ID: <480522A5.2080208@nitros9.org> Date: Tue, 15 Apr 2008 23:48:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" CC: radiusext@ops.ietf.org Subject: Re: RADEXT WG re-charter References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Joseph Salowey (jsalowey) wrote: > There are a few reasons why you would want to wrap keys separately from > other data. As you mentioned, the recommended algorithms for key wrap > may not be suitable for encrypting bulk data without special > consideration and some bulk data encryption algorithms may not be > recommended for key wrap without special consideration. Another reason > is that you may want the entity that handles the keys and their context > to be different from the entity that handles the rest of the attributes. i.e. distributing wireless keys to a NAS. For reasons outlined in RFC 3538, RadSec is likely not a good idea for NAS -> local AAA communications. DTLS is better for transport, but still may be difficult for some to implement. Encrypting only the keys is likely sufficient. 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 Tue Apr 15 18:27:12 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 2984528C107 for ; Tue, 15 Apr 2008 18:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.494 X-Spam-Level: X-Spam-Status: No, score=-101.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 3MtiHA37Bi-j for ; Tue, 15 Apr 2008 18:27:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FB163A6F28 for ; Tue, 15 Apr 2008 18:27:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlwMF-000MYX-HV for radiusext-data@psg.com; Wed, 16 Apr 2008 01:22:43 +0000 Received: from [15.201.24.18] (helo=g4t0015.houston.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlwMC-000MXT-0Y for radiusext@ops.ietf.org; Wed, 16 Apr 2008 01:22:41 +0000 Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTP id 44946884A; Wed, 16 Apr 2008 01:22:38 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.1.263.0; Wed, 16 Apr 2008 01:21:46 +0000 Received: from G6W0269.americas.hpqcorp.net ([16.230.32.78]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Wed, 16 Apr 2008 01:21:46 +0000 From: "Sanchez, Mauricio (ProCurve)" To: "Bernard_Aboba@hotmail.com" , "radiusext@ops.ietf.org" Date: Wed, 16 Apr 2008 01:21:45 +0000 Subject: RE: Consensus Call on RADEXT WG re-charter Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMok4qsMVgbLISSqLMqEx2GjNuAA4JRHw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013B_01C89ED8.776DFAC0" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk ------=_NextPart_000_013B_01C89ED8.776DFAC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_013C_01C89ED8.776DFAC0" ------=_NextPart_001_013C_01C89ED8.776DFAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am in favor of this proposal. MS From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard_Aboba@hotmail.com Sent: Monday, April 14, 2008 6:20 AM To: radiusext@ops.ietf.org Subject: Consensus Call on RADEXT WG re-charter This is a consensus call for acceptance of the RADEXT WG re-charter. The consensus call will last until April 28, 2008. Please send email to the list stating whether you are in favor or opposed to the RADEXT WG re-charter proposal: ======================================================= Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC ------=_NextPart_001_013C_01C89ED8.776DFAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in favor of this proposal.

 

MS

 

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On = Behalf Of Bernard_Aboba@hotmail.com
Sent: Monday, April 14, 2008 6:20 AM
To: radiusext@ops.ietf.org
Subject: Consensus Call on RADEXT WG = re-charter

 

This is a consensus call for acceptance of the RADEXT WG = re-charter.  The

consensus call will last until April 28, 2008.  Please send email to the = list

stating whether you are in favor or opposed to the RADEXT WG = re-charter

proposal:

 

 

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Description of Working = Group:


The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage. =

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and = Diameter,
the following restrictions are imposed on extensions considered by = the
RADEXT WG:

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
 

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines = for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as = well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice = RFC
Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed = Standard RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an = Informational RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard = RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard = RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental = RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

------=_NextPart_001_013C_01C89ED8.776DFAC0-- ------=_NextPart_000_013B_01C89ED8.776DFAC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhB3lLeh2K9TSN0bRHs7 wmmDMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0xMTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAIC20 InJbjxHbFARQiJa3lZPqTCrVfV5vngYprhEGanLYRa9c6bf2tbkHdxBelAHWJaLSzZW6NF4K3fkq NjtRHaR16iUovo4pRS6hJvUywmKS38AK5V6iAMcYf1n57MF3WcG2ZVeI97IUd9cYB0G8dY+vGp77 WZNqiQC9vwkPTzwwggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDQxNTE2MDk1M1owIwYJ KoZIhvcNAQkEMRYEFG3VhAPSp1k57+nysszIE9cev5ptMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgOSKERT9u8rhMT0HtkIbDPqnQlsS4FPjbFWNwtHW0j319kpLQZMDFg4pMm0paVRk gP39/keUXrW/0t+aYvzoLNUZaN6ME/Jl8eeJamrXI+hBNzU/2k5DNMcTJPpziUVtWBjkHWVgSW0Z ualjKPRXGaLZusKHwSI20kCh6v2Ynk1FAAAAAAAA ------=_NextPart_000_013B_01C89ED8.776DFAC0-- -- 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 Apr 15 22:46: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 23A1D3A688E for ; Tue, 15 Apr 2008 22:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.363 X-Spam-Level: X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.074, 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 et1dBbLrIV2F for ; Tue, 15 Apr 2008 22:46:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A3483A6B60 for ; Tue, 15 Apr 2008 22:46:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm0Ol-000HJn-LZ for radiusext-data@psg.com; Wed, 16 Apr 2008 05:41:35 +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 1Jm0Oi-000HJN-UG for radiusext@ops.ietf.org; Wed, 16 Apr 2008 05:41:34 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA06.westchester.pa.mail.comcast.net with comcast id E2Yh1Z0010QuhwU5608V00; Wed, 16 Apr 2008 05:40:04 +0000 Received: from gzornt61 ([124.120.224.153]) by OMTA02.westchester.pa.mail.comcast.net with comcast id E5gm1Z0023KBy2c3N00000; Wed, 16 Apr 2008 05:41:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=6rgHKmtPPGc6WzdhRDAA:9 a=vSO5UperinKuQeIEC94A:7 a=LABIgXoli9YjXHrFIJVHWERBr3IA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'Matt Holdrege'" , "'Joseph Salowey \(jsalowey\)'" , "'Bernard Aboba'" , "'Alan DeKok'" Cc: "'radext mailing list'" References: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> <480388AF.7040904@nitros9.org> <005b01c89e5c$e9822720$33da787c@arubanetworks.com> <4803A74D.1000708@nitros9.org> <001501c89ea0$bdf89500$33da787c@arubanetworks.com> <000901c89eb9$1ee14fc0$5ca3ef40$@com> <400A74A604718E46BC9EE95677BAFF31181955@wv-mailsrv2.strixsystems.com> Subject: RE: SNMP vs. RADIUS transport mappings Date: Wed, 16 Apr 2008 12:40:36 +0700 Message-ID: <006301c89f84$73c7c2f0$99e0787c@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: <400A74A604718E46BC9EE95677BAFF31181955@wv-mailsrv2.strixsystems.com> thread-index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYAAGg6B8AAA9cNQABhWwpA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Wednesday, April 16, 2008 1:08 AM: > SNMP had the full support of the IAB and IESG who pushed many > years for the full development of the protocol. RADIUS has > been denigrated by a long list of IAB and IESG leadership as > something that never should have been allowed to happen and > should not have a place in any future IETF protocol > development. I don't know if it would be possible to get the > level of support needed to do what you are suggesting, but it > would have been nice to have done that work back in the 90's. > > But all that is IETF politics and future RADIUS development > shouldn't worry too much about past politics. In a perfect world that would be true; unfortunately, 'the song goes on'... ... -- 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 Apr 15 23:43:28 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 BAD503A6BAC for ; Tue, 15 Apr 2008 23:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.068, 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 uJcTT1csj203 for ; Tue, 15 Apr 2008 23:43:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50FEB3A681F for ; Tue, 15 Apr 2008 23:43:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm1HK-000LWd-2a for radiusext-data@psg.com; Wed, 16 Apr 2008 06:37:58 +0000 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm1HH-000LWB-D1 for radiusext@ops.ietf.org; Wed, 16 Apr 2008 06:37:56 +0000 Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA08.westchester.pa.mail.comcast.net with comcast id E5be1Z0030xGWP85803Y00; Wed, 16 Apr 2008 06:36:40 +0000 Received: from gzornt61 ([124.120.224.153]) by OMTA12.westchester.pa.mail.comcast.net with comcast id E6dT1Z0043KBy2c3Y00000; Wed, 16 Apr 2008 06:37:51 +0000 X-Authority-Analysis: v=1.0 c=1 a=bsqZyp1wauQA:10 a=gb58eDyHnUgA:10 a=48vgC7mUAAAA:8 a=wzvrUK3bhZz0DCaJeCUA:9 a=ZpGnmNeqp50obpYtankA:7 a=uwTL-OncPQyed9MUgHWdkKlkoQYA:4 a=r5QHxzKXScQA:10 a=v47ZLdibA2YA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> Subject: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 13:37:17 +0700 Message-ID: <007501c89f8c$57c0f380$99e0787c@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: <48046B45.20008@deployingradius.com> thread-index: Acie1bYTHYV+lGqeRfSK7nUmuV4hmQAs0GFQ Sender: owner-radiusext@ops.ietf.org Precedence: bulk Alan DeKok scribbled on Tuesday, April 15, 2008 3:46 PM: > Glen Zorn wrote: >> OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not >> be the authoritative reference for "RADIUS *at all*". What is? I'd >> like to read it... > > The authoritative reference for RADIUS is this WG. If the > consensus is to add bells, whistles, or flying monkeys to > RADIUS, then that is our perogative. > > The alternative is to worship at the holy shrine of the > existing RFC's, which were handed down from on high by the > holy priests of RADIUS. As mere mortals, we are incapable of > changing holy writ, and must confess that the RFC's are perfect. > > I shall therefore submit a request to the RFC editor > admitting that RFC 5080 is blasphemy, as it points out > *errors* in the original RFC's. > It should therefore be withdrawn immediately, before the holy > priests of RADIUS burn me at the stake. Could we just try to stay on topic, please? My assertion was that to claim "backward compatibility" between 2 protocols which can only communicate through a translating gateway is essentially meaningless. That has nothing to do with "priests" or "holy writ", even less with the ludicrous claim that this WG is some kind of global help desk for RADIUS developers. Back to the subject at hand, you managed to define "backward compatibility" in a slightly different context a couple of months ago (see https://ops.ietf.org/lists/radiusext/2008/msg00000.html for the complete message): "Everyone accepts that implementations have to be updated to handle new standards. One of the major efforts in RADIUS has been to maintain backwards compatibility with existing deployments. i.e. if a product doesn't implement the new standard, it can still communicate with products that do implement that standard." A RadSec implementation doesn't also listen on UDP 1812 pretty obviously flunks that test (not that I think it's a particularly good one, but it's yours). If there is to be _any_ interoperability between RADIUS and RadSec, then the definition of the protocol gateway behavior is at least as, if not more, important than the standardization of RadSec. Unfortunately, this doesn't seem to be reflected in the charter that everyone seems in such a hurry to rubberstamp; maybe because RadSec is by definition "backward compatible"? > > 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 Tue Apr 15 23:49:06 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 0D50C28C35C for ; Tue, 15 Apr 2008 23:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-0.875, 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 U1SukXmcyqEN for ; Tue, 15 Apr 2008 23:49:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E57728C1F7 for ; Tue, 15 Apr 2008 23:49:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm1PZ-000MFk-9S for radiusext-data@psg.com; Wed, 16 Apr 2008 06:46:29 +0000 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm1PW-000MFN-9M for radiusext@ops.ietf.org; Wed, 16 Apr 2008 06:46:27 +0000 X-IronPort-AV: E=Sophos;i="4.25,663,1199682000"; d="scan'208";a="102598963" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Apr 2008 02:46:22 -0400 X-IronPort-AV: E=Sophos;i="4.25,663,1199682000"; d="scan'208";a="182529878" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Apr 2008 02:46:21 -0400 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: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 08:46:19 +0200 Message-ID: In-Reply-To: <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Thread-Index: Acie1bYTHYV+lGqeRfSK7nUmuV4hmQAs0GFQAAEPh0A= References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "Alan DeKok" Cc: Sender: owner-radiusext@ops.ietf.org Precedence: bulk Can you guys try to agree on a paragraph which explains what 'backward compatibility' means in the context of this charter?=20 It seems to me that this is the principal item of disagreement in this debate.=20 Dan =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn > Sent: Wednesday, April 16, 2008 9:37 AM > To: 'Alan DeKok' > Cc: radiusext@ops.ietf.org > Subject: Meaning of "backward compatible" WAS RE: Consensus=20 > Call on RADEXT WG re-charter >=20 > Alan DeKok scribbled on=20 > Tuesday, April 15, 2008 3:46 PM: >=20 > > Glen Zorn wrote: > >> OK, since RFC 2865 only defines RADIUS in terms of UDP, it=20 > must not=20 > >> be the authoritative reference for "RADIUS *at all*". =20 > What is? I'd=20 > >> like to read it... > >=20 > > The authoritative reference for RADIUS is this WG. If the=20 > consensus=20 > > is to add bells, whistles, or flying monkeys to RADIUS,=20 > then that is=20 > > our perogative. > >=20 > > The alternative is to worship at the holy shrine of the existing=20 > > RFC's, which were handed down from on high by the holy priests of=20 > > RADIUS. As mere mortals, we are incapable of changing holy=20 > writ, and=20 > > must confess that the RFC's are perfect. > >=20 > > I shall therefore submit a request to the RFC editor=20 > admitting that=20 > > RFC 5080 is blasphemy, as it points out > > *errors* in the original RFC's. > > It should therefore be withdrawn immediately, before the=20 > holy priests=20 > > of RADIUS burn me at the stake. >=20 > Could we just try to stay on topic, please? My assertion was=20 > that to claim "backward compatibility" between 2 protocols=20 > which can only communicate through a translating gateway is=20 > essentially meaningless. > That has nothing to do with "priests" or "holy writ", even=20 > less with the ludicrous claim that this WG is some kind of=20 > global help desk for RADIUS developers. Back to the subject=20 > at hand, you managed to define "backward compatibility" in a=20 > slightly different context a couple of months ago (see=20 > https://ops.ietf.org/lists/radiusext/2008/msg00000.html > for the complete message): "Everyone accepts that=20 > implementations have to be updated to handle new standards. =20 > One of the major efforts in RADIUS has been to maintain=20 > backwards compatibility with existing deployments. i.e. if a=20 > product doesn't implement the new standard, it can still=20 > communicate with products that do implement that standard." =20 > A RadSec implementation doesn't also listen on UDP 1812=20 > pretty obviously flunks that test (not that I think it's a=20 > particularly good one, but it's yours). If there is to be=20 > _any_ interoperability between RADIUS and RadSec, then the=20 > definition of the protocol gateway behavior is at least as,=20 > if not more, important than the standardization of RadSec. > Unfortunately, this doesn't seem to be reflected in the=20 > charter that everyone seems in such a hurry to rubberstamp;=20 > maybe because RadSec is by definition "backward compatible"? =20 >=20 > >=20 > > Alan DeKok. >=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 Wed Apr 16 00:19: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 4F9F83A6921 for ; Wed, 16 Apr 2008 00:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.423 X-Spam-Level: X-Spam-Status: No, score=-0.423 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 1U+JweL+gJAx for ; Wed, 16 Apr 2008 00:19:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B23E3A6DBE for ; Wed, 16 Apr 2008 00:19:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm1ro-000OoJ-7t for radiusext-data@psg.com; Wed, 16 Apr 2008 07:15:40 +0000 Received: from [65.55.175.165] (helo=blu139-omc1-s25.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm1rm-000Oo2-10 for radiusext@ops.ietf.org; Wed, 16 Apr 2008 07:15:39 +0000 Received: from BLU137-W3 ([65.55.162.182]) by blu139-omc1-s25.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 00:15:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_73941c2c-b0c9-42e7-b3e8-eb54b26d419b_" X-Originating-IP: [24.18.147.115] From: Bernard Aboba To: "Romascanu, Dan (Dan)" , Glen Zorn , Alan DeKok CC: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 00:15:37 -0700 Importance: Normal In-Reply-To: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2008 07:15:37.0295 (UTC) FILETIME=[AB4AF5F0:01C89F91] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_73941c2c-b0c9-42e7-b3e8-eb54b26d419b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For transport items this basically means "uses RADIUS packet formats define= d in RFC 2865, 2866 and 5176" (although the ports can be different). --_73941c2c-b0c9-42e7-b3e8-eb54b26d419b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For transport items this basically means "uses RADIUS packet formats define= d in RFC 2865, 2866 and 5176" (although the ports can be different).
= --_73941c2c-b0c9-42e7-b3e8-eb54b26d419b_-- -- 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 Apr 16 01: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 2890328C3EA for ; Wed, 16 Apr 2008 01:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 OlXBB+KtzwgL for ; Wed, 16 Apr 2008 01:14:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B9CFC28C3FE for ; Wed, 16 Apr 2008 01:14:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm2jk-0003Xk-Dc for radiusext-data@psg.com; Wed, 16 Apr 2008 08:11:24 +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 1Jm2jf-0003X7-0e for radiusext@ops.ietf.org; Wed, 16 Apr 2008 08:11:23 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 9FC7DA7138; Wed, 16 Apr 2008 01:11:10 -0700 (PDT) Message-ID: <4805B3B6.9060108@nitros9.org> Date: Wed, 16 Apr 2008 10:07:18 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Bernard Aboba CC: "Romascanu, Dan (Dan)" , Glen Zorn , radiusext@ops.ietf.org Subject: Re: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.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: > For transport items this basically means "uses RADIUS packet formats > defined in RFC 2865, 2866 and 5176" (although the ports can be different). Yes. 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 Apr 16 01:18: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 B796928C40D for ; Wed, 16 Apr 2008 01:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.062, 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 Rp0txLvTyXOd for ; Wed, 16 Apr 2008 01:18:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DB6D28C3EA for ; Wed, 16 Apr 2008 01:18:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm2oX-0003wk-CJ for radiusext-data@psg.com; Wed, 16 Apr 2008 08:16:21 +0000 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm2oU-0003wN-JW for radiusext@ops.ietf.org; Wed, 16 Apr 2008 08:16:19 +0000 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA08.westchester.pa.mail.comcast.net with comcast id E8Eo1Z0060vyq2s5800400; Wed, 16 Apr 2008 08:15:05 +0000 Received: from gzornt61 ([124.120.224.153]) by OMTA05.westchester.pa.mail.comcast.net with comcast id E8Fc1Z0013KBy2c3R00000; Wed, 16 Apr 2008 08:16:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=yUeBna1na-sA:10 a=cLKmM4UG21vnXtZyMm0A:9 a=GNYv9zscuvRKJTA5m83VUwEdPUkA:4 a=4dyfk4FV-b8A:10 a=Dqp-bWOt5EsA:10 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" , "'Alan DeKok'" Cc: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 15:15:26 +0700 Message-ID: <007c01c89f9a$15d575f0$99e0787c@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: thread-index: Acie1bYTHYV+lGqeRfSK7nUmuV4hmQAs0GFQAAEPh0AAAQFYwA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk Romascanu, Dan (Dan) scribbled on Wednesday, April 16, 2008 1:46 PM: > Can you guys try to agree on a paragraph which explains what > 'backward compatibility' means in the context of this charter? The term is meaningless in the context of this charter & should be removed or at the very least _highly_ qualified. Saying (as the currently proposed charter does) that "All RADIUS work MUST be backward compatible with existing RADIUS RFCs" is just absurd. That said, the following paragraph would work, Think: - All documents produced MUST specify means of interoperation with legacy RADIUS implementations and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. > > It seems to me that this is the principal item of disagreement in > this debate. > > Dan > ... -- 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 Apr 16 01: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 95F0128C3BF for ; Wed, 16 Apr 2008 01:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, 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 hmb2IvXSeD86 for ; Wed, 16 Apr 2008 01:23:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0ECE828C2FE for ; Wed, 16 Apr 2008 01:23:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm2sm-0004LH-2c for radiusext-data@psg.com; Wed, 16 Apr 2008 08:20:44 +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 1Jm2sg-0004Ka-Mp for radiusext@ops.ietf.org; Wed, 16 Apr 2008 08:20:42 +0000 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA09.westchester.pa.mail.comcast.net with comcast id E8FS1Z0011HzFnQ5900900; Wed, 16 Apr 2008 08:18:40 +0000 Received: from gzornt61 ([124.120.224.153]) by OMTA14.westchester.pa.mail.comcast.net with comcast id E8Kz1Z0013KBy2c3a00000; Wed, 16 Apr 2008 08:20:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=yUeBna1na-sA:10 a=wIVIj5zXdSwrtdlkPncA:9 a=EAi03iE6zCVearQ8cCWDl0Y5VVoA:4 a=EfJqPEOeqlMA:10 a=zoKOyUDlhksA:10 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Romascanu, Dan \(Dan\)'" , "'Alan DeKok'" Cc: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 15:19:49 +0700 Message-ID: <007d01c89f9a$adb6d6c0$99e0787c@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: thread-index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3w Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba scribbled on Wednesday, April 16, 2008 2:16 PM: > For transport items this basically means "uses RADIUS packet > formats defined in RFC 2865, 2866 and 5176" (although the > ports can be different). So what you're saying is that two nodes can be unable to communicate & still be "backward compatible"? -- 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 Apr 16 05:57: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 2B7173A6864 for ; Wed, 16 Apr 2008 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-0.487, 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 3OjGpSylwJIr for ; Wed, 16 Apr 2008 05:57:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAE1E3A69FD for ; Wed, 16 Apr 2008 05:57:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jm77J-00044V-9q for radiusext-data@psg.com; Wed, 16 Apr 2008 12:52:01 +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 1Jm77G-000449-Im for radiusext@ops.ietf.org; Wed, 16 Apr 2008 12:51:59 +0000 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id EC2m1Z0051HzFnQ5302m00; Wed, 16 Apr 2008 12:50:20 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA14.westchester.pa.mail.comcast.net with comcast id ECrx1Z00124Kx1C3a00000; Wed, 16 Apr 2008 12:51:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=rqB-lymJrVdMz3bLluQA:9 a=RppYdsYUai3jq3eA5fkA:7 a=hgZNoE-hJ__Oalyg_CjtnlHzFycA:4 a=zUBsD6tbDSsA:10 From: "David B. Nelson" To: References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> Subject: RE: RADEXT WG re-charter Date: Wed, 16 Apr 2008 08:52:02 -0400 Message-ID: <00a201c89fc0$aadb86f0$6401a8c0@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: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFAAAers8AAWnCbAAEQZ+DA= In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk Joseph Salowey writes... > There are a few reasons why you would want to wrap keys separately from > other data. As you mentioned, the recommended algorithms for key wrap > may not be suitable for encrypting bulk data without special > consideration ... Yes, because in those cases you are *relying* on the randomness of the key material. > ... and some bulk data encryption algorithms may not be > recommended for key wrap without special consideration. That's the part I still don't understand. The only "consideration" I've heard so far is that "NIST hasn't blessed it", which is political and not technical. Of course, if you think that a critical goal of RADIUS Crypto-Agility is to facilitate creating FIPS certifiable products, then maybe this should be listed in the RADIUS Crypto-Agility Requirements draft. > Another reason is that you may want the entity that handles the keys > and their context to be different from the entity that handles the rest > of the attributes. Perhaps. You could provide that enforced "separation of concerns" by using a separate KEK for the keys and a DEK for the data. The algorithm and mode need not be different to provide the isolation. Since the key management and distribution, e.g. automated key management, is currently out of scope for RADIUS Crypto-Agility, that shouldn't present an impediment. > Neither of these reasons forces you to have encryption tied directly to > the key attribute. It is convenient since one is very often interested > in encrypting keys, but you can achieve the same thing with a generic > encryption attribute if you take care. OK. What care do we need to take? > You need to support multiple pieces of data encrypted with different > keys (key IDs, alg IDs, message boundaries, etc.) in the same message > and you need to make sure that the various supported encryption > algorithms are used correctly (type of cleartext, sufficient > randomization, integrity protection, etc.). If we determine that the algorithm and mode that do not depend upon a random payload, but are still strong when the payload happens to be random, what's the issue? > If you don't consider keys as part of the data you are wrapping for > crypto agility, I'm not sure you will end up with a result that is very > useful. Sure. We need to have a method that works for keys, too. I'm trying to figure out if there is a "one size fits all" algorithm and method (assuming a separate KEK), and if not, why not. So far the only impediment that I see remaining is the "it's not blessed by NIST" for that particular application, e.g. key wrap. BTW, thank you very much for a *technical* discussion of the issue. It's quite refreshing. :-) -- 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 Apr 16 09:25:35 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 B4CBB3A6C65 for ; Wed, 16 Apr 2008 09:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=-3.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 avAcRjLqWQKe for ; Wed, 16 Apr 2008 09:25:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D3453A6F8C for ; Wed, 16 Apr 2008 09:25:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmAMc-0004M9-BA for radiusext-data@psg.com; Wed, 16 Apr 2008 16:20:02 +0000 Received: from [66.46.199.134] (helo=webmail.bridgewatersystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmAMU-0004K1-I8 for radiusext@ops.ietf.org; Wed, 16 Apr 2008 16:19:56 +0000 Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Wed, 16 Apr 2008 12:19:51 -0400 From: Avi Lior To: "Bernard_Aboba@hotmail.com" , "radiusext@ops.ietf.org" Date: Wed, 16 Apr 2008 12:19:50 -0400 Subject: RE: Consensus Call on RADEXT WG re-charter Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMpXIFccirmMPQOO1YeKWg6NdLABN4KQg Message-ID: <8A8CFE8F89C38B41A749C19328C76D63038852B0B6@exchange02.bridgewatersys.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8A8CFE8F89C38B41A749C19328C76D63038852B0B6exchange02bri_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_000_8A8CFE8F89C38B41A749C19328C76D63038852B0B6exchange02bri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a very interesting thing happening here with the notion of adding = a new transport to RADIUS: specifically TCP/TLS transport to RADIUS. In recent experiences in other SDOs people were concerned about the scalabi= lity of Diameter. Specifically, in the hot arena of Femto Cells and Diamet= er, people were wondering how a diameter server would maintain 100,000 plus= connections with the femtos. This without using multiple servers. So here we are thinking about perhaps introducing a UDP transport or someth= ing equivalent for the Diameter server -- at least for that first hop betwe= en the femto cell in your home and the operator's site. Perhaps the right approach for these protocols is to allow them to utilize = the correct transport for the job at hand. Having no choice is seemingly p= roblematic. Avi ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Bernard_Aboba@hotmail.com Sent: Monday, April 14, 2008 9:20 AM To: radiusext@ops.ietf.org Subject: Consensus Call on RADEXT WG re-charter This is a consensus call for acceptance of the RADEXT WG re-charter. The consensus call will last until April 28, 2008. Please send email to the li= st stating whether you are in favor or opposed to the RADEXT WG re-charter proposal: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RF= C June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC --_000_8A8CFE8F89C38B41A749C19328C76D63038852B0B6exchange02bri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There is a very interesting thing happening here with the notion o= f=20 adding a new transport to RADIUS: specifically TCP/TLS transport to=20 RADIUS. 
 
In=20 recent experiences in other SDOs people were concerned about the scalabilit= y of=20 Diameter.  Specifically, in the hot arena of Femto Cells and Diameter,= =20 people were wondering how a diameter server would maintain 100,000 plu= s=20 connections with the femtos.  This without using multiple=20 servers.
 
So=20 here we are thinking about perhaps introducing a UDP transport or something= =20 equivalent for the Diameter server -- at least for that first hop betw= een=20 the femto cell in your home and the operator's site.
 
Perhaps the right approach for these protocols is to allow th= em to=20 utilize the correct transport for the job at hand.  Having no choice i= s=20 seemingly problematic.
 
 Avi

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of=20 Bernard_Aboba@hotmail.com
Sent: Monday, April 14, 2008 9:20= =20 AM
To: radiusext@ops.ietf.org
Subject: Consensus Call= on=20 RADEXT WG re-charter

This is a consensus call for acceptance= =20 of the RADEXT WG re-charter.  The
consensus call will last until April&nbs= p;28,=20 2008.  Please send email to the list
stating whether you are in favor or oppo= sed to=20 the RADEXT WG re-charter
proposal:
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Description of Working Group:

The RADIUS Extensions Working Group will focus on ext= ensions=20 to the
RADIUS protocol required to define extensions to the=20 standard
attribute space as well as to address cryptographic=20 algorithm
agility and use over new secure transports. In addition, RAD= EXT=20 will
work on RADIUS Design Guidelines and define new attributes for=20
particular applications of authentication, authorization and=20
accounting such as NAS management and local area network (LAN) usage.= =20

In order to enable interoperation of heterogeneous=20 RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a=20 Diameter
compatibility section, outlining how interoperability=20 with
Diameter will be maintained.

Furthermore, to ensure backwa= rd=20 compatibility with existing RADIUS
implementations, as well as=20 compatibility between RADIUS and Diameter,
the following restrictions = are=20 imposed on extensions considered by the
RADEXT WG:

- All RADIUS= work=20 MUST be backward compatible with existing RADIUS
RFCs, including RFCs= =20 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and=20 5176.

- All RADIUS work MUST be compatible with equivalent facilit= ies=20 in
Diameter. Where possible, new attributes should be defined so=20 that
the same attribute can be used in both RADIUS and Diameter=20 without
translation. In other cases a translation considerations
se= ction=20 should be included in the specification.
 

Work=20 Items

The immediate goals of the RADEXT working group are to addre= ss=20 the
following issues:

- RADIUS design guidelines. This document= will=20 provide guidelines for
design of RADIUS attributes. It will specifical= ly=20 consider how
complex data types may be introduced in a robust manner,= =20 maintaining
backwards compatibility with existing RADIUS RFCs, across = all=20 the
classes of attributes: Standard, Vendor-Specific and=20 SDO-Specific.
In addition, it will review RADIUS data types and=20 associated
backwards compatibility issues.
 
- RADIUS Manag= ement=20 authorization. This document will define the
use of RADIUS for NAS=20 management over IP.

-RADIUS attribute space extension. The standa= rd=20 RADIUS attribute
space is currently being depleted. This document will= =20 provide
additional standard attribute space, while maintaining=20 backward
compatibility with existing attributes.

-RADIUS=20 Cryptographic Algorithm Agility. RADIUS has traditionally
relied on M= D5=20 for both per-packet integrity and authentication as well
as attribute= =20 confidentiality. Given the increasingly successful
attacks being mount= ed=20 against MD5, the ability to support
alternative algorithms is required= .=20 This work item will
include documentation of RADIUS crypto-agility=20 requirements,
as well as development of one or more Experimental RFCs= =20 providing
support for negotiation of alternative cryptographic=20 algorithms
to protect RADIUS.

- IEEE 802 attributes. New attrib= utes=20 have been proposed to
support IEEE 802 standards for wired and wireles= s=20 LANs. This
work item will support authentication, authorization=20 and
accounting attributes needed by IEEE 802 groups including
IEEE= =20 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. New s= ecure=20 transports for RADIUS will
be developed, including TCP/TLS (RADSEC) an= d=20 UDP/DTLS.

- Documentation of Status-Server usage. A=20 document
describing usage of the Status-Server facility will=20 be
developed.

Goals and Milestones:
Jun 2008 RADIUS Design=20 Guidelines submitted as a Best Current Practice RFC
Jun 2008 RADIUS=20 Management Authorization I-D submitted as a Proposed Standard RFC
Sep = 2008=20 RADIUS Crypto-agility Requirements submitted as an Informational RFC
S= ep=20 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec = 2008=20 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009= =20 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC= =20 (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
June 2009= =20 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS= =20 Cryptographic Algorithm Agility I-D submitted as an Experimental=20 RFC
--_000_8A8CFE8F89C38B41A749C19328C76D63038852B0B6exchange02bri_-- -- 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 Apr 16 09:33:14 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 E1EC33A6F9E for ; Wed, 16 Apr 2008 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.494 X-Spam-Level: X-Spam-Status: No, score=-8.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 VmckMoZ5ixq5 for ; Wed, 16 Apr 2008 09:33:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C74C03A7045 for ; Wed, 16 Apr 2008 09:32:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmAU8-0005Cf-4Z for radiusext-data@psg.com; Wed, 16 Apr 2008 16:27:48 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmAU4-0005CB-SO for radiusext@ops.ietf.org; Wed, 16 Apr 2008 16:27:46 +0000 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.54.46.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 16 Apr 2008 09:27:44 -0700 Received: from NA-EXMSG-C114.redmond.corp.microsoft.com ([157.54.62.167]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.54.46.186]) with mapi; Wed, 16 Apr 2008 09:27:44 -0700 From: Mudit Goel To: "Bernard_Aboba@hotmail.com" , "radiusext@ops.ietf.org" Date: Wed, 16 Apr 2008 09:27:36 -0700 Subject: RE: Consensus Call on RADEXT WG re-charter Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMuM1ypKFHVrRSFWbhLct/k3bKABq9K8w Message-ID: <456A5146F9319946A179B523B9FC91D60D9EE7109E@NA-EXMSG-C114.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_456A5146F9319946A179B523B9FC91D60D9EE7109ENAEXMSGC114re_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_000_456A5146F9319946A179B523B9FC91D60D9EE7109ENAEXMSGC114re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in favor of this proposal. Mudit Goel From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Bernard_Aboba@hotmail.com Sent: Monday, April 14, 2008 6:20 AM To: radiusext@ops.ietf.org Subject: Consensus Call on RADEXT WG re-charter This is a consensus call for acceptance of the RADEXT WG re-charter. The consensus call will last until April 28, 2008. Please send email to the li= st stating whether you are in favor or opposed to the RADEXT WG re-charter proposal: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RF= C June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC --_000_456A5146F9319946A179B523B9FC91D60D9EE7109ENAEXMSGC114re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in favor of this proposal.

 

Mudit Goel

 

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Be= half Of Bernard_Aboba@hotmail.com
Sent: Monday, April 14, 2008 6:20 AM
To: radiusext@ops.ietf.org
Subject: Consensus Call on RADEXT WG re-charter

 

This is a consensus call for acceptance of the RADEXT WG re-charter.  = The

consensus call will last until April 28, 2008.  Please send email to the li= st

stating whether you are in favor or opposed to the RADEXT WG re-charter=

proposal:

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Description of Working Group:


The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage.

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
 

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC<= br> Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RF= C
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

--_000_456A5146F9319946A179B523B9FC91D60D9EE7109ENAEXMSGC114re_-- -- 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 Apr 16 10:09:38 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 66AB928C38C for ; Wed, 16 Apr 2008 10:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=-0.315, 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 x44OVpAKd3wy for ; Wed, 16 Apr 2008 10:09:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23D0E28C3E9 for ; Wed, 16 Apr 2008 10:09:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmB4N-000Af9-5i for radiusext-data@psg.com; Wed, 16 Apr 2008 17:05:15 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmB4K-000AeX-9x for radiusext@ops.ietf.org; Wed, 16 Apr 2008 17:05:13 +0000 Received: (qmail 6837 invoked from network); 16 Apr 2008 13:05:11 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 16 Apr 2008 13:05:11 -0400 From: "David B. Nelson" To: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 13:02:26 -0400 Organization: Elbrys Networks, Inc. Message-ID: <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> 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: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaA= In-Reply-To: <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > > For transport items this basically means "uses RADIUS packet > > formats defined in RFC 2865, 2866 and 5176" (although the > > ports can be different). > > So what you're saying is that two nodes can be unable to > communicate & still be "backward compatible"? I don't think that's what was meant. I think understand your position: -- The use of UDP is mandated in RFC 2865. -- Packets sent by clients over UDP to Port 1812, won't be received by a server listening on TCP Port . An alternate point of view is that a RADIUS client or server implementation doesn't need to change very much if the sockets that it opens are stream sockets as opposed to datagram sockets. The data flow, above the socket layer, (i.e. the application PDU stream) is the same. In that regard, the RADIUS protocol specification relies upon, but does not include the socket layer and all the layers below. -- 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 Apr 16 10:24:37 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 0A58128C490 for ; Wed, 16 Apr 2008 10:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4Nskf-lsxaYc for ; Wed, 16 Apr 2008 10:24:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 194F828C4A2 for ; Wed, 16 Apr 2008 10:24:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmBJk-000CQT-Bj for radiusext-data@psg.com; Wed, 16 Apr 2008 17:21:08 +0000 Received: from [208.179.69.44] (helo=WV-MAILSRV2.strixsystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmBJh-000CPv-7T for radiusext@ops.ietf.org; Wed, 16 Apr 2008 17:21:07 +0000 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: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 10:21:02 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> In-Reply-To: <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkA== References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> From: "Matt Holdrege" To: "David B. Nelson" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson An alternate point of view is that a RADIUS client or server implementation doesn't need to change very much if the sockets that it opens are stream sockets as opposed to datagram sockets. The data flow, above the socket layer, (i.e. the application PDU stream) is the same. In that regard, the RADIUS protocol specification relies upon, but does not include the socket layer and all the layers below. ------------------------------------------------------------------------ ----------------- The above would be a heck of an assumption to make for all RADIUS clients out in the field. The real world is rarely as simple as a high level protocol architecture document. RADIUS has always used UDP and perhaps a lot of developers have counted on that and never developed their products to be socket layer neutral. Not to mention that a firmware change of clients is not really an option in most cases. However as I said before, it's nothing much to cry about on the server side. -- 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 Apr 16 10:56: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 213A63A6F9F for ; Wed, 16 Apr 2008 10:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-0.305, 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 ylElatFDUWzL for ; Wed, 16 Apr 2008 10:56:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E7903A6AFA for ; Wed, 16 Apr 2008 10:56:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmBp2-000H74-JM for radiusext-data@psg.com; Wed, 16 Apr 2008 17:53:28 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmBot-000H5s-O3 for radiusext@ops.ietf.org; Wed, 16 Apr 2008 17:53:24 +0000 Received: (qmail 8019 invoked from network); 16 Apr 2008 13:53:18 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 16 Apr 2008 13:53:18 -0400 From: "David B. Nelson" To: Cc: "'Matt Holdrege'" References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 13:50:34 -0400 Organization: Elbrys Networks, Inc. Message-ID: <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> 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: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/w In-Reply-To: <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Matt Holdrege writes... > RADIUS has always used UDP and perhaps a lot of developers have > counted on that and never developed their products to be socket > layer neutral. This is quite possible. > Not to mention that a firmware change of clients is not really > an option in most cases. My personal (individual WG member) opinion is that the RADSEC work is interesting for proxy-to-proxy and proxy-to-home-server usages. I think that it would be fairly rare to see it in NAS-to-server or NAS-to-proxy cases. That takes most of the "sting" out of the "wedded-to-UDP" issues with NAS-based client implementations. I think of proxies as being a server and client glued together, BTW. -- 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 Apr 16 11:03:05 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 30CF53A6A1F for ; Wed, 16 Apr 2008 11:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kbAyyQfKEgJZ for ; Wed, 16 Apr 2008 11:03:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41C3F3A6AFA for ; Wed, 16 Apr 2008 11:03:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmBvY-000Jbw-Ti for radiusext-data@psg.com; Wed, 16 Apr 2008 18:00:12 +0000 Received: from [208.179.69.44] (helo=WV-MAILSRV2.strixsystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmBvW-000JbQ-Do for radiusext@ops.ietf.org; Wed, 16 Apr 2008 18:00:11 +0000 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: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 11:00:08 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> In-Reply-To: <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9A= References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> From: "Matt Holdrege" To: "David B. Nelson" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk -----Original Message----- From: David B. Nelson [mailto:dnelson@elbrysnetworks.com]=20 Sent: Wednesday, April 16, 2008 7:51 PM Matt Holdrege writes... > RADIUS has always used UDP and perhaps a lot of developers have=20 > counted on that and never developed their products to be socket > layer neutral. This is quite possible. > Not to mention that a firmware change of clients is not really=20 > an option in most cases. My personal (individual WG member) opinion is that the RADSEC work is interesting for proxy-to-proxy and proxy-to-home-server usages. I think that it would be fairly rare to see it in NAS-to-server or NAS-to-proxy cases. That takes most of the "sting" out of the "wedded-to-UDP" issues with NAS-based client implementations. I think of proxies as being a server and client glued together, BTW. -------------------------------------------------------------- OK, that's fine, but then if *real* RADIUS clients aren't really a part of this effort, then why is it in this WG? I assume you have some reason for not using IETF recommended IPsec to secure proxy-to-proxy data? If so, why don't you create another proxy-server to proxy-server encryption protocol? Sorry, I expect this has been discussed before already. If so, disregard my question. -Matt -- 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 Apr 16 11:17: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 245443A6BEB for ; Wed, 16 Apr 2008 11:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[AWL=-0.296, 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 UUfcY3o-BDCJ for ; Wed, 16 Apr 2008 11:17:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17F193A67E5 for ; Wed, 16 Apr 2008 11:17:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmC5I-000KjA-T9 for radiusext-data@psg.com; Wed, 16 Apr 2008 18:10:16 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmC5C-000KiK-UA for radiusext@ops.ietf.org; Wed, 16 Apr 2008 18:10:15 +0000 Received: (qmail 8503 invoked from network); 16 Apr 2008 14:10:10 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 16 Apr 2008 14:10:10 -0400 From: "David B. Nelson" To: Cc: "'Matt Holdrege'" References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 14:07:26 -0400 Organization: Elbrys Networks, Inc. Message-ID: <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> 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: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MA== In-Reply-To: <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Matt Holdrege writes... > OK, that's fine, but then if *real* RADIUS clients aren't really > a part of this effort, then why is it in this WG? Hmmm. Because the WG isn't limited to considering only RADIUS extensions that [primarily] impact the NAS? > I assume you have some reason for not using IETF recommended IPsec > to secure proxy-to-proxy data? That issue has been discussed. There are implementations and deployments of RADIUS over IPsec. The thing that some folks don't like about IPsec is that it's a Layer 3 protocol and isn't visible to applications at Layer 4 (e.g. at the socket interface) the way TLS is. > If so, why don't you create another proxy-server to proxy-server > encryption protocol? One could claim that RADSEC neatly fills that bill. -- 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 Apr 16 15:38: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 6B6603A6A1F for ; Wed, 16 Apr 2008 15:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.184 X-Spam-Level: X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[AWL=-0.688, 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 EzlWx8aOVXCS for ; Wed, 16 Apr 2008 15:38:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0425E3A6F76 for ; Wed, 16 Apr 2008 15:38:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmG6l-0000e6-B3 for radiusext-data@psg.com; Wed, 16 Apr 2008 22:28:03 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmG6i-0000dh-GX for radiusext@ops.ietf.org; Wed, 16 Apr 2008 22:28:01 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2008 15:28:00 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3GMRxKl030335; Wed, 16 Apr 2008 15:27:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3GMRx75022145; Wed, 16 Apr 2008 22:27:59 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 15:27:59 -0700 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: RADEXT WG re-charter Date: Wed, 16 Apr 2008 15:28:49 -0700 Message-ID: In-Reply-To: <00a201c89fc0$aadb86f0$6401a8c0@NEWTON603> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADEXT WG re-charter Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFAAAers8AAWnCbAAEQZ+DAAE3icMA== References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> <00a201c89fc0$aadb86f0$6401a8c0@NEWTON603> From: "Joseph Salowey (jsalowey)" To: "David B. Nelson" , X-OriginalArrivalTime: 16 Apr 2008 22:27:59.0374 (UTC) FILETIME=[201D52E0:01C8A011] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5647; t=1208384879; x=1209248879; c=relaxed/simple; s=sjdkim2002; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=w37jCLzqUvB26Dckum0qwX1znadW2a5GjO5wciDIHgA=; b=Io2SebrFXlhnAv4A2/pzLbg/I5LleBwCpFDDL64jiDMThM1JoDRg1D/2WV f60aNfIgkBd6hCu1UWSky6nh0kh9vcnjDvH/GMF/XbY+9StgtaoGh1ADoDaI eghouR90NG; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-radiusext@ops.ietf.org Precedence: bulk =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: Wednesday, April 16, 2008 5:52 AM > To: radiusext@ops.ietf.org > Subject: RE: RADEXT WG re-charter >=20 > Joseph Salowey writes... > =20 > > There are a few reasons why you would want to wrap keys separately=20 > > from other data. As you mentioned, the recommended=20 > algorithms for key=20 > > wrap may not be suitable for encrypting bulk data without special=20 > > consideration ... >=20 > Yes, because in those cases you are *relying* on the=20 > randomness of the key material. >=20 [Joe] That's at least part of the problem, but in general these algorithms were not designed for bulk data encryption so there may be other issues that I don't know about.=20 > > ... and some bulk data encryption algorithms may not be recommended=20 > > for key wrap without special consideration. >=20 > That's the part I still don't understand. The only=20 > "consideration" I've heard so far is that "NIST hasn't=20 > blessed it", which is political and not technical. Of=20 > course, if you think that a critical goal of RADIUS=20 > Crypto-Agility is to facilitate creating FIPS certifiable=20 > products, then maybe this should be listed in the RADIUS=20 > Crypto-Agility Requirements draft. >=20 [Joe] I wouldn't say this is just political. NIST has designed an algorithm for the purpose of wrapping keys. While this may not be everybody's favorite solution it seems silly to design a crypto-agility solution that cannot accommodate it. I would say the requirement is to support key wrapping.=20 > > Another reason is that you may want the entity that handles=20 > the keys=20 > > and their context to be different from the entity that handles the=20 > > rest of the attributes. >=20 > Perhaps. You could provide that enforced "separation of=20 > concerns" by using a separate KEK for the keys and a DEK for=20 > the data. The algorithm and mode need not be different to=20 > provide the isolation. Since the key management and=20 > distribution, e.g. automated key management, is currently out=20 > of scope for RADIUS Crypto-Agility, that shouldn't present an=20 > impediment. >=20 [Joe] Yes, at the very least the keys must be different, but for the reasons discussed above you may want to vary the algorithms as well. I would think if you can figure out how to have different keys you can also figure out how to support different algorithms.=20 > > Neither of these reasons forces you to have encryption tied=20 > directly=20 > > to the key attribute. It is convenient since one is very often=20 > > interested in encrypting keys, but you can achieve the same=20 > thing with=20 > > a generic encryption attribute if you take care. >=20 > OK. What care do we need to take? >=20 [Joe] That's what I scribbled about on parenthesis below.=20 > > You need to support multiple pieces of data encrypted with=20 > different=20 > > keys (key IDs, alg IDs, message boundaries, etc.) in the=20 > same message=20 > > and you need to make sure that the various supported encryption=20 > > algorithms are used correctly (type of cleartext, sufficient=20 > > randomization, integrity protection, etc.). >=20 > If we determine that the algorithm and mode that do not=20 > depend upon a random payload, but are still strong when the=20 > payload happens to be random, what's the issue? >=20 [Joe] As stated above the issues are using the algorithms for what they are designed for and support separation between keys and their context from other attributes. There can be multiple ways we can design this which would work out fine by pushing some of the inconvenient bits to different places.=20 > > If you don't consider keys as part of the data you are wrapping for=20 > > crypto agility, I'm not sure you will end up with a result that is=20 > > very useful. >=20 > Sure. We need to have a method that works for keys, too. =20 > I'm trying to figure out if there is a "one size fits all"=20 > algorithm and method (assuming a separate KEK), and if not,=20 > why not. So far the only impediment that I see remaining is=20 > the "it's not blessed by NIST" for that particular=20 > application, e.g. key wrap. >=20 [Joe] NIST as defined a key wrapping algorithm, it may not be the best thing for all purposes, but it is good enough for key wrapping and it has been implemented for this purpose in various solutions. Designing a crypto-agility solution that cannot support this seems short-sighted since NIST validation is an important part of many customer's requirements. This is especially true since one of the main pieces of data people are concerned about protecting in today's deployments are keys. While I favor a specific attribute for key wrap solution, I do not think it is necessary to design it this way. If we support different encrypted payloads in the same message with different keys and different algorithms you have effectively the same thing (you just wouldn't know that it was a key and its context that was wrapped). We should limit the usage of key-wrap specific algorithms to the purpose they were designed for. =20 > BTW, thank you very much for a *technical* discussion of the=20 > issue. It's quite refreshing. :-) >=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 Wed Apr 16 17:30: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 ACBEA3A6ADF for ; Wed, 16 Apr 2008 17:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 9cnwokihlsZN for ; Wed, 16 Apr 2008 17:30:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 66DAE28C417 for ; Wed, 16 Apr 2008 17:30:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmHwv-000C8x-6Z for radiusext-data@psg.com; Thu, 17 Apr 2008 00:26:01 +0000 Received: from [65.55.175.208] (helo=blu139-omc3-s8.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmHws-000C8R-Nv for radiusext@ops.ietf.org; Thu, 17 Apr 2008 00:25:59 +0000 Received: from BLU137-DS1 ([65.55.162.188]) by blu139-omc3-s8.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 17:25:57 -0700 X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" In-Reply-To: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> <00a201c89fc0$aadb86f0$6401a8c0@NEWTON603> To: "David B. Nelson" , References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> <00a201c89fc0$aadb86f0$6401a8c0@NEWTON603> Subject: Re: RADEXT WG re-charter X-Unsent: 1 Date: Wed, 16 Apr 2008 17:25:57 -0700 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: 17 Apr 2008 00:25:57.0530 (UTC) FILETIME=[9B0637A0:01C8A021] Sender: owner-radiusext@ops.ietf.org Precedence: bulk > That's the part I still don't understand. The only "consideration" I've > heard so far is that "NIST hasn't blessed it", which is political and not > technical. At IETF 71, the technical discussion brought up the following points: a. The integrity protection for keywrap is considerably *weaker* (e.g. 64 bits) than for standard MIC algorithms. b. Encryption algorithms for keywrap cannot be securely used to do bulk encryption of data, but algorithms that can do bulk encryption can securely be used to encrypt keys. c. Existing IETF standards (such as Diameter EAP, RFC 4702) use TLS to protect keys. There are no known security issues relating to this. As far as the "politics" goes, at various points during this discussion, assertions have been made with respect to NIST's position. However, when NIST was contacted to verify those assertions, they indicated that the assertions either did not represent the official position of NIST, or that NIST had not yet taken a position. Given this, I would suggest that assertions made about NIST positions should be ruled out of scope, unless they come directly from representatives of NIST. -- 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 Apr 16 22:06: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 ECE643A6938 for ; Wed, 16 Apr 2008 22:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=0.053, 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 F1yJhuLRXzKT for ; Wed, 16 Apr 2008 22:06:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 244D43A67A9 for ; Wed, 16 Apr 2008 22:06:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmMHE-000JOe-9E for radiusext-data@psg.com; Thu, 17 Apr 2008 05:03:16 +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 1JmMHB-000JO4-8B for radiusext@ops.ietf.org; Thu, 17 Apr 2008 05:03:15 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA05.westchester.pa.mail.comcast.net with comcast id EUWB1Z0070EZKEL5501U00; Thu, 17 Apr 2008 05:01:22 +0000 Received: from gzornt61 ([124.120.228.154]) by OMTA01.westchester.pa.mail.comcast.net with comcast id EV2f1Z0053LWrBw3M00000; Thu, 17 Apr 2008 05:03:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=yUeBna1na-sA:10 a=u55p6IVpkS-LTkeUjnwA:9 a=nwwBmTqQZsWh6-g9NYrTva2WNkYA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'David B. Nelson'" , Cc: "'Matt Holdrege'" References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Thu, 17 Apr 2008 12:02:28 +0700 Message-ID: <000001c8a048$450e3e70$9ae4787c@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: <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Thursday, April 17, 2008 1:07 AM: > Matt Holdrege writes... > >> OK, that's fine, but then if *real* RADIUS clients aren't really a >> part of this effort, then why is it in this WG? > > Hmmm. Because the WG isn't limited to considering only RADIUS > extensions that [primarily] impact the NAS? Hmmm. Since _everything_ has to change, how can you say that? > >> I assume you have some reason for not using IETF recommended IPsec to >> secure proxy-to-proxy data? > > That issue has been discussed. There are implementations and > deployments of RADIUS over IPsec. The thing that some folks > don't like about IPsec is that it's a Layer 3 protocol and > isn't visible to applications at Layer 4 (e.g. > at the socket interface) the way TLS is. > >> If so, why don't you create another proxy-server to proxy-server >> encryption protocol? > > One could claim that RADSEC neatly fills that bill. Conceptually, yes; it's nowhere near fully baked from a standards POV IMHO, but it (or something very similar) has been working in very large commercial roaming networks for a very long time. BTW (since it doesn't seem to have gotten through to some people) let me say it again: I am not & never have been opposed to the standardization of RadSec. I think that it's a mistake to undertake the task in this WG (not least of all because of an obvious antagonism to innovation on the part of some members) but since the tide of opinion seems to be to do that it's fine. I AM REALLY OPPOSED TO BS, however & I don't really understand this manic grasping at straws to claim RadSec's "backward compatibility", to the point that now we have 'if you used this interface when you wrote your code (as opposed to the easy, obvious one)' then it's really almost the same but not quite'. Please. ... -- 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 Apr 16 22:41:11 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 BDD503A68A6 for ; Wed, 16 Apr 2008 22:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, 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 CNLS-d92oACl for ; Wed, 16 Apr 2008 22:41:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83B2A28C252 for ; Wed, 16 Apr 2008 22:41:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmMmd-000Mip-H0 for radiusext-data@psg.com; Thu, 17 Apr 2008 05:35:43 +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 1JmMma-000Mi5-3e for radiusext@ops.ietf.org; Thu, 17 Apr 2008 05:35:42 +0000 Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA07.westchester.pa.mail.comcast.net with comcast id EVXK1Z0080SCNGk5700D00; Thu, 17 Apr 2008 05:34:09 +0000 Received: from gzornt61 ([124.120.228.154]) by OMTA09.westchester.pa.mail.comcast.net with comcast id EVb71Z0063LWrBw3V00000; Thu, 17 Apr 2008 05:35:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=1bz1owvqq8MA:10 a=HXLIHGxoemX3Yu5Vjc4A:9 a=2_ZOYmsxT1fcyznKvazHeRm8I7cA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'Avi Lior'" Cc: , References: <8A8CFE8F89C38B41A749C19328C76D63038852B0B6@exchange02.bridgewatersys.com> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Thu, 17 Apr 2008 12:34:57 +0700 Message-ID: <000f01c8a04c$ce894380$9ae4787c@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: <8A8CFE8F89C38B41A749C19328C76D63038852B0B6@exchange02.bridgewatersys.com> Thread-Index: AcieMpXIFccirmMPQOO1YeKWg6NdLABN4KQgADiQZSA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Wednesday, April 16, 2008 11:20 PM: > There is a very interesting thing happening here with the > notion of adding a new transport to RADIUS: specifically > TCP/TLS transport to RADIUS. > > In recent experiences in other SDOs people were concerned > about the scalability of Diameter. Specifically, in the hot > arena of Femto Cells and Diameter, people were wondering how a > diameter server would maintain 100,000 plus connections with > the femtos. This without using multiple servers. > > So here we are thinking about perhaps introducing a UDP > transport or something equivalent for the Diameter server -- > at least for that first hop between the femto cell in your > home and the operator's site. > > Perhaps the right approach for these protocols is to allow > them to utilize the correct transport for the job at hand. > Having no choice is seemingly problematic. Good point. On that note, it seems that RadSec (as currently specified) creates one new option but eliminates another. Would it be worthwhile defining RADIUS over TCP, & then how to use TLS to protect it? ... -- 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 Apr 17 10:22: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 61F3628C575 for ; Thu, 17 Apr 2008 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-1.525, 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 yLZMcLJn1Fgq for ; Thu, 17 Apr 2008 10:22:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26D0728C5CD for ; Thu, 17 Apr 2008 10:22:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmXjT-000N1K-Tf for radiusext-data@psg.com; Thu, 17 Apr 2008 17:17:11 +0000 Received: from [66.46.199.134] (helo=webmail.bridgewatersystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmXjR-000N0E-40 for radiusext@ops.ietf.org; Thu, 17 Apr 2008 17:17:10 +0000 Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 17 Apr 2008 13:17:07 -0400 From: Avi Lior To: Glen Zorn CC: "Bernard_Aboba@hotmail.com" , "radiusext@ops.ietf.org" Date: Thu, 17 Apr 2008 13:17:07 -0400 Subject: RE: Consensus Call on RADEXT WG re-charter Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMpXIFccirmMPQOO1YeKWg6NdLABN4KQgADiQZSAAGJ3IYA== Message-ID: <8A8CFE8F89C38B41A749C19328C76D63038852B100@exchange02.bridgewatersys.com> References: <8A8CFE8F89C38B41A749C19328C76D63038852B0B6@exchange02.bridgewatersys.com> <000f01c8a04c$ce894380$9ae4787c@arubanetworks.com> In-Reply-To: <000f01c8a04c$ce894380$9ae4787c@arubanetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@comcast.net] > Sent: Thursday, April 17, 2008 1:35 AM > To: Avi Lior > Cc: Bernard_Aboba@hotmail.com; radiusext@ops.ietf.org > Subject: RE: Consensus Call on RADEXT WG re-charter > > owner-radiusext@ops.ietf.org <> scribbled on Wednesday, April > 16, 2008 11:20 PM: > > > There is a very interesting thing happening here with the notion of > > adding a new transport to RADIUS: specifically TCP/TLS transport to > > RADIUS. > > > > In recent experiences in other SDOs people were concerned about the > > scalability of Diameter. Specifically, in the hot arena of Femto > > Cells and Diameter, people were wondering how a diameter > server would > > maintain 100,000 plus connections with the femtos. This > without using > > multiple servers. > > > > So here we are thinking about perhaps introducing a UDP > transport or > > something equivalent for the Diameter server -- at least for that > > first hop between the femto cell in your home and the > operator's site. > > > > Perhaps the right approach for these protocols is to allow them to > > utilize the correct transport for the job at hand. > > Having no choice is seemingly problematic. > > Good point. On that note, it seems that RadSec (as currently > specified) creates one new option but eliminates another. > Would it be worthwhile defining RADIUS over TCP, & then how > to use TLS to protect it? Yes. -- 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 Apr 17 13:19: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 4CC053A67C1 for ; Thu, 17 Apr 2008 13:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.223 X-Spam-Level: X-Spam-Status: No, score=-5.223 tagged_above=-999 required=5 tests=[AWL=-0.775, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 ZrTUnSlFKgOs for ; Thu, 17 Apr 2008 13:19:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61D483A6AAD for ; Thu, 17 Apr 2008 13:19:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmaWc-0000i8-TW for radiusext-data@psg.com; Thu, 17 Apr 2008 20:16:06 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmaWa-0000hg-3p for radiusext@ops.ietf.org; Thu, 17 Apr 2008 20:16:05 +0000 Received: from mesico.nist.gov (csme13.ncsl.nist.gov [129.6.54.47]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m3HKFsFp019360; Thu, 17 Apr 2008 16:15:54 -0400 Message-Id: <7.0.1.0.2.20080417160616.02403730@nist.gov> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 17 Apr 2008 16:15:54 -0400 To: ietf@ietf.org, dime@ietf.org, radiusext@ops.ietf.org From: Katrin Hoeper Subject: Invitation to join IETF proxy mailing list Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_22428828==.ALT" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: katrin.hoeper@nist.gov Sender: owner-radiusext@ops.ietf.org Precedence: bulk --=====================_22428828==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts. For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a result of our meeting, a proxy email list was created to further investigate the proxy problems. We decided to use AAA proxies as a starting point for our discussion on the list. The long-term (and ideal) goal could be to extend the results of the AAA proxy discussion in order to address proxy-related security issues in general. However, for now we will focus on AAA proxies. This email serves as an invitation for anybody interested to join our discussions on the list. Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies Best regards, Katrin Hoeper ---------- Katrin Hoeper Computer Security Division National Institute of Standards and Technology (NIST) 100 Bureau Dr. Mail stop: 8930 Gaithersburg, MD 20878 (301) 975 - 4024 --=====================_22428828==.ALT Content-Type: text/html; charset="us-ascii" Hi,

Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts.

For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a
result of our meeting, a proxy email list was created to further investigate the proxy problems.

We decided to use AAA proxies as a starting point for our discussion on the list. The long-term (and ideal) goal could be to extend the results of the AAA proxy discussion in order to address proxy-related security issues in general. However, for now we will focus on AAA proxies.

This email serves as an invitation for anybody interested to join our discussions on the list.
Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies

Best regards,
Katrin Hoeper

Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 4024
 --=====================_22428828==.ALT-- -- 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 Apr 17 15:10: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 A5C783A6FE2 for ; Thu, 17 Apr 2008 15:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.104 X-Spam-Level: ** X-Spam-Status: No, score=2.104 tagged_above=-999 required=5 tests=[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 P5A5XpLzZz3W for ; Thu, 17 Apr 2008 15:10:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 21A9B3A6A1A for ; Thu, 17 Apr 2008 15:10:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmcEP-000EIc-GX for radiusext-data@psg.com; Thu, 17 Apr 2008 22:05:25 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmcEM-000EI8-Vu for radiusext@ops.ietf.org; Thu, 17 Apr 2008 22:05:24 +0000 Received: (qmail 9206 invoked from network); 17 Apr 2008 18:05:21 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 17 Apr 2008 18:05:21 -0400 From: "David B. Nelson" To: References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> <00a201c89fc0$aadb86f0$6401a8c0@NEWTON603> Subject: RE: RADEXT WG re-charter Date: Thu, 17 Apr 2008 18:02:34 -0400 Organization: Elbrys Networks, Inc. Message-ID: <034901c8a0d6$bd89cf70$1f0a0a0a@xpsuperdvd2> 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: AcigIibHOklDiy1GQ3WOXzFohAm2igAs3ZOQ In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard Aboba writes... > At IETF 71, the technical discussion brought up the following points: > > a. The integrity protection for keywrap is considerably *weaker* > (e.g. 64 bits) than for standard MIC algorithms. > b. Encryption algorithms for keywrap cannot be securely used to do > bulk encryption of data, but algorithms that can do bulk encryption > can securely be used to encrypt keys. Are there specific recommendations (e.g. an "SP" series document) from NIST that cover the use of bulk encryption algorithms to encrypt keys? > c. Existing IETF standards (such as Diameter EAP, RFC 4702) use TLS to > protect keys. > Given this, I would suggest that assertions made about NIST positions > should be ruled out of scope, unless they come directly from > representatives of NIST. Or presumably from existing NIST publications... I tend to think (individual opinion) that facilitating FIPS "certifiable" implementations might be a reasonable requirement to be added into the RADIUS Crypto-Agility Requirements draft, assuming the reference is to an existing NIST publication. I understand that these publications would discuss algorithms and modes only, and not cover how to encapsulate a key in a RADIUS attribute. -- 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 Apr 17 15:21:35 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 2CBF728C149 for ; Thu, 17 Apr 2008 15:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.104 X-Spam-Level: ** X-Spam-Status: No, score=2.104 tagged_above=-999 required=5 tests=[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 nTLpWpFqjt9o for ; Thu, 17 Apr 2008 15:21:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5069728C28C for ; Thu, 17 Apr 2008 15:21:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmcPu-000Fit-2E for radiusext-data@psg.com; Thu, 17 Apr 2008 22:17:18 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmcPr-000FiM-6q for radiusext@ops.ietf.org; Thu, 17 Apr 2008 22:17:16 +0000 Received: (qmail 9443 invoked from network); 17 Apr 2008 18:17:14 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 17 Apr 2008 18:17:14 -0400 From: "David B. Nelson" To: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Thu, 17 Apr 2008 18:14:27 -0400 Organization: Elbrys Networks, Inc. Message-ID: <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> 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: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlA= In-Reply-To: <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > I AM REALLY OPPOSED TO BS, however ... If I thought that slam was targeted at me, I might be offended. :-) > ... I don't really understand this manic grasping at straws to > claim RadSec's "backward compatibility", to the point that now we > have 'if you used this interface when you wrote your code (as opposed > to the easy, obvious one)' then it's really almost the same but not > quite'. We need a reasonable definition of "backward compatible" to scope this work. It needs to be unambiguous, so that we can tell when it has or has not been met. It has to be simple enough that we can understand it. Whether or not you agree that RADIUS *has* an application layer specification that can be divorced from a specific transport binding, it is important that the RADSEC specification (or any other alternate transport specifications for RADIUS) make it clear that all we want to tinker with in this work item is the *transport* layer. We want the RADIUS PDUs to remain otherwise unchanged. What's wrong with that? -- 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 Apr 17 16:09:00 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 E5CD63A6A45 for ; Thu, 17 Apr 2008 16:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.415 X-Spam-Level: * X-Spam-Status: No, score=1.415 tagged_above=-999 required=5 tests=[AWL=-1.081, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, 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 CcfmNWLCI2TL for ; Thu, 17 Apr 2008 16:08:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 721C03A6CF4 for ; Thu, 17 Apr 2008 16:08:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmd9a-000LPr-Ie for radiusext-data@psg.com; Thu, 17 Apr 2008 23:04:30 +0000 Received: from [69.55.226.174] (helo=colo.trepanning.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmd9X-000LPR-Gb for radiusext@ops.ietf.org; Thu, 17 Apr 2008 23:04:29 +0000 Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D4542A8882BA; Thu, 17 Apr 2008 16:04:26 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 17 Apr 2008 16:04:26 -0700 (PDT) Message-ID: <1b0ef15e32c8840021ae4d76299649c7.squirrel@www.trepanning.net> In-Reply-To: References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> <00a201c89fc0$aadb86f0$6401a8c0@NEWTON603> Date: Thu, 17 Apr 2008 16:04:26 -0700 (PDT) Subject: RE: RADEXT WG re-charter From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" Cc: "David B. Nelson" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-radiusext@ops.ietf.org Precedence: bulk A very intersting discussion.... Yes, bulk data protection with the current key wrapping scheme (RFC3394) is problematic. It requires things to be 64-bit aligned, it doesn't allow "associated data" (AD) which is authenticated but not encrypted, and while it is probably secure it does not have a formal proof of security behind it. All of these problems can be addressed by the SIV mode of AES. SIV can provide deterministic "key wrapping" when a component of the plaintext is random, and it can provide nonce-based bulk data encryption. In both variants it allows AD. It also provides security even in the presence of nonce reuse. This last issue is especially critical when one does not have a dynamic key exchange but, instead, uses statically provisioned keys on the client and server. If one side crashes and loses state (like a counter value or knowledge of previously used nonces) the security of the system must not suffer, nor is it realistic to require each side to checkpoint state in some non-volatile storage. Secure key wrapping with AD plus bulk data encryption with AD that is resistant to nonce reuse, all in one cipher mode. That sounds useful.... Dan. On Wed, April 16, 2008 3:28 pm, Joseph Salowey (jsalowey) wrote: > > >> -----Original Message----- >> From: owner-radiusext@ops.ietf.org >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson >> Sent: Wednesday, April 16, 2008 5:52 AM >> To: radiusext@ops.ietf.org >> Subject: RE: RADEXT WG re-charter >> >> Joseph Salowey writes... >> >> > There are a few reasons why you would want to wrap keys separately >> > from other data. As you mentioned, the recommended >> algorithms for key >> > wrap may not be suitable for encrypting bulk data without special >> > consideration ... >> >> Yes, because in those cases you are *relying* on the >> randomness of the key material. >> > [Joe] That's at least part of the problem, but in general these > algorithms were not designed for bulk data encryption so there may be > other issues that I don't know about. > >> > ... and some bulk data encryption algorithms may not be recommended >> > for key wrap without special consideration. >> >> That's the part I still don't understand. The only >> "consideration" I've heard so far is that "NIST hasn't >> blessed it", which is political and not technical. Of >> course, if you think that a critical goal of RADIUS >> Crypto-Agility is to facilitate creating FIPS certifiable >> products, then maybe this should be listed in the RADIUS >> Crypto-Agility Requirements draft. >> > [Joe] I wouldn't say this is just political. NIST has designed an > algorithm for the purpose of wrapping keys. While this may not be > everybody's favorite solution it seems silly to design a crypto-agility > solution that cannot accommodate it. I would say the requirement is to > support key wrapping. > >> > Another reason is that you may want the entity that handles >> the keys >> > and their context to be different from the entity that handles the >> > rest of the attributes. >> >> Perhaps. You could provide that enforced "separation of >> concerns" by using a separate KEK for the keys and a DEK for >> the data. The algorithm and mode need not be different to >> provide the isolation. Since the key management and >> distribution, e.g. automated key management, is currently out >> of scope for RADIUS Crypto-Agility, that shouldn't present an >> impediment. >> > [Joe] Yes, at the very least the keys must be different, but for the > reasons discussed above you may want to vary the algorithms as well. I > would think if you can figure out how to have different keys you can > also figure out how to support different algorithms. > > >> > Neither of these reasons forces you to have encryption tied >> directly >> > to the key attribute. It is convenient since one is very often >> > interested in encrypting keys, but you can achieve the same >> thing with >> > a generic encryption attribute if you take care. >> >> OK. What care do we need to take? >> > [Joe] That's what I scribbled about on parenthesis below. > >> > You need to support multiple pieces of data encrypted with >> different >> > keys (key IDs, alg IDs, message boundaries, etc.) in the >> same message >> > and you need to make sure that the various supported encryption >> > algorithms are used correctly (type of cleartext, sufficient >> > randomization, integrity protection, etc.). >> >> If we determine that the algorithm and mode that do not >> depend upon a random payload, but are still strong when the >> payload happens to be random, what's the issue? >> > [Joe] As stated above the issues are using the algorithms for what they > are designed for and support separation between keys and their context > from other attributes. There can be multiple ways we can design this > which would work out fine by pushing some of the inconvenient bits to > different places. > >> > If you don't consider keys as part of the data you are wrapping for >> > crypto agility, I'm not sure you will end up with a result that is >> > very useful. >> >> Sure. We need to have a method that works for keys, too. >> I'm trying to figure out if there is a "one size fits all" >> algorithm and method (assuming a separate KEK), and if not, >> why not. So far the only impediment that I see remaining is >> the "it's not blessed by NIST" for that particular >> application, e.g. key wrap. >> > [Joe] NIST as defined a key wrapping algorithm, it may not be the best > thing for all purposes, but it is good enough for key wrapping and it > has been implemented for this purpose in various solutions. Designing a > crypto-agility solution that cannot support this seems short-sighted > since NIST validation is an important part of many customer's > requirements. This is especially true since one of the main pieces of > data people are concerned about protecting in today's deployments are > keys. While I favor a specific attribute for key wrap solution, I do > not think it is necessary to design it this way. If we support > different encrypted payloads in the same message with different keys and > different algorithms you have effectively the same thing (you just > wouldn't know that it was a key and its context that was wrapped). We > should limit the usage of key-wrap specific algorithms to the purpose > they were designed for. > >> BTW, thank you very much for a *technical* discussion of the >> issue. It's quite refreshing. :-) >> >> >> >> -- >> 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: > -- 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 Apr 17 21:34:31 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 7B8B928C17F for ; Thu, 17 Apr 2008 21:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Kc5yMT9CnU3y for ; Thu, 17 Apr 2008 21:34:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68A6D28C101 for ; Thu, 17 Apr 2008 21:34:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmiDV-0005gm-NY for radiusext-data@psg.com; Fri, 18 Apr 2008 04:28:53 +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 1JmiDS-0005fg-PD for radiusext@ops.ietf.org; Fri, 18 Apr 2008 04:28:52 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA02.westchester.pa.mail.comcast.net with comcast id Eldn1Z00D16LCl0520Q800; Fri, 18 Apr 2008 04:28:40 +0000 Received: from gzornt61 ([124.120.226.108]) by OMTA06.westchester.pa.mail.comcast.net with comcast id EsUL1Z0022LxKF83S00000; Fri, 18 Apr 2008 04:28:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=yUeBna1na-sA:10 a=NKTJsf0hEM7xd-52beAA:9 a=j2KVnKsyYv-eziKzxmDBNieKKdgA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 11:28:18 +0700 Message-ID: <006601c8a10c$aa26ad00$6ce2787c@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 Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugA== In-Reply-To: <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Friday, April 18, 2008 5:14 AM: ... >> ... I don't really understand this manic grasping at straws to claim >> RadSec's "backward compatibility", to the point that now we have 'if >> you used this interface when you wrote your code (as opposed to the >> easy, obvious one)' then it's really almost the same but not quite'. > > We need a reasonable definition of "backward compatible" to > scope this work. > It needs to be unambiguous, so that we can tell when it has or > has not been met. It has to be simple enough that we can understand > it. I agree completely. What is amazing is that, given the fact that "backward compatibility" has been in the charter since the WG was formed (& has been used as a stick to beat to death several useful proposals), this definition doesn't already exist. In fact, its utility as an ad hoc bludgeon is such that I doubt that such a clear, unambiguous definition will be forthcoming (let alone written into the charter). I sincerely hope that I'm proven wrong... > > Whether or not you agree that RADIUS *has* an application > layer specification that can be divorced from a specific > transport binding, it is important that the RADSEC > specification (or any other alternate transport specifications > for RADIUS) make it clear that all we want to tinker with in > this work item is the *transport* layer. We want the RADIUS > PDUs to remain otherwise unchanged. > > What's wrong with that? One thing that's wrong is that it ignores the limitations on the RADIUS PDU that exist primarily (or solely) because of the UDP transport. One example: the maximum length of 4096 octets for a Radius packet was chosen (IIRC) based upon the maximum size of a _UDP_ frame that could be reliably transmitted w/o fragmentation _in the access networks of the day_. It doesn't seem to be very smart to go to all the trouble of defining RADIUSoTCP while leaving this kind of unnecessary, UDP-specific limitation in place. ... -- 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 Apr 18 00:25: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 879153A6988 for ; Fri, 18 Apr 2008 00:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 ugQIeRxnolGv for ; Fri, 18 Apr 2008 00:25:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 879D13A68E8 for ; Fri, 18 Apr 2008 00:25:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmkug-0002eR-1J for radiusext-data@psg.com; Fri, 18 Apr 2008 07:21:38 +0000 Received: from [208.179.69.44] (helo=WV-MAILSRV2.strixsystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmkud-0002dz-Jz for radiusext@ops.ietf.org; Fri, 18 Apr 2008 07:21:36 +0000 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: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 00:21:33 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181BF6@wv-mailsrv2.strixsystems.com> In-Reply-To: <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAAExpsUA== References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> From: "Matt Holdrege" To: "David B. Nelson" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson Sent: Friday, April 18, 2008 12:14 AM Glen Zorn writes... > I AM REALLY OPPOSED TO BS, however ... If I thought that slam was targeted at me, I might be offended. :-) > ... I don't really understand this manic grasping at straws to=20 > claim RadSec's "backward compatibility", to the point that now we > have 'if you used this interface when you wrote your code (as opposed > to the easy, obvious one)' then it's really almost the same but not > quite'. We need a reasonable definition of "backward compatible" to scope this work. It needs to be unambiguous, so that we can tell when it has or has not been met. It has to be simple enough that we can understand it. Whether or not you agree that RADIUS *has* an application layer specification that can be divorced from a specific transport binding, it is important that the RADSEC specification (or any other alternate transport specifications for RADIUS) make it clear that all we want to tinker with in this work item is the *transport* layer. We want the RADIUS PDUs to remain otherwise unchanged. What's wrong with that? ---------------------------------------------------------------- If you go by the assumption, as reality pretty much dictates, that RADIUS is not divorced from specific transport binding, then you should be very cautious to avoid creating a heck of a lot of confusion downstream from where we sit. For the last umpteen years RADIUS has been RADIUS. True we have caused all sorts of havoc with attributes, but that hasn't killed basic interoperability between RADIUS clients and servers. This new effort would kill that basic interoperability. Therefore you need to make very clear that the result of this work will NOT be interoperable with the massive world-wide deployment of RADIUS clients. -Matt -- 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 Apr 18 01:05: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 C66823A68EF for ; Fri, 18 Apr 2008 01:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=0.524, 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 5QU7uxWLnOZg for ; Fri, 18 Apr 2008 01:05:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55D1E3A6A12 for ; Fri, 18 Apr 2008 01:05:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmlXP-0007Go-9o for radiusext-data@psg.com; Fri, 18 Apr 2008 08:01:39 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmlXM-0007GD-Ex for radiusext@ops.ietf.org; Fri, 18 Apr 2008 08:01:37 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 848D876F44; Fri, 18 Apr 2008 10:01:35 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 751C376F42; Fri, 18 Apr 2008 10:01:35 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: "Matt Holdrege" Subject: Re: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 10:01:30 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181BF6@wv-mailsrv2.strixsystems.com> In-Reply-To: <400A74A604718E46BC9EE95677BAFF31181BF6@wv-mailsrv2.strixsystems.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 --nextPart1346050.FOUIHeYVxR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > If you go by the assumption, as reality pretty much dictates, that > RADIUS is not divorced from specific transport binding, then you should > be very cautious to avoid creating a heck of a lot of confusion > downstream from where we sit. For the last umpteen years RADIUS has been > RADIUS. True we have caused all sorts of havoc with attributes, but that > hasn't killed basic interoperability between RADIUS clients and servers. > This new effort would kill that basic interoperability. Therefore you > need to make very clear that the result of this work will NOT be > interoperable with the massive world-wide deployment of RADIUS clients. Well, if an implementation would do RadSec exclusively, and NOT listen on=20 UDP/1812 as well, then yes, RADIUS clients would not be able to communicate= =20 with that implementation. Reality however is that all the implementations so far can do both, UDP/181= 2=20 and RadSec on TCP/2083, and are able to translate between both. Such=20 implementations *are* interoperable with existing RADIUS clients. Since this is a (sane) behaviour by all implementations so far, it might be= =20 wise to add an according note to the RadSec I-D that: if interoperability=20 with standard RADIUS clients is required, the implementation also has to=20 listen on UDP/1812 (I used to think that goes without saying, but it=20 certainly doesn't hurt to put that sentence in there). I wouldn't want to=20 mandate this for all implementations as a MUST though, since I can easily=20 imagine proxy interconnections in a backend that have no business with NASe= s,=20 and for such deployments it would just be an unnecessary burden to mandate= =20 listening in UDP/1812. 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 --nextPart1346050.FOUIHeYVxR 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) iD8DBQBICFVe+jm90f8eFWYRArEzAJ4jt7YNVhA9QQN5DMPN8cwCr7vmjwCfceOD bxz9BLCGnK1wGgSxSepHdR4= =ia6H -----END PGP SIGNATURE----- --nextPart1346050.FOUIHeYVxR-- -- 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 Apr 18 08:01: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 7FDB73A68B2 for ; Fri, 18 Apr 2008 08:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.011 X-Spam-Level: ** X-Spam-Status: No, score=2.011 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 zypjNuMDy-16 for ; Fri, 18 Apr 2008 08:01:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C1D73A68F2 for ; Fri, 18 Apr 2008 08:01:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmrzY-000BEP-Pl for radiusext-data@psg.com; Fri, 18 Apr 2008 14:55:08 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmrzS-000BDX-Ux for radiusext@ops.ietf.org; Fri, 18 Apr 2008 14:55:04 +0000 Received: (qmail 6007 invoked from network); 18 Apr 2008 10:55:01 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 18 Apr 2008 10:55:01 -0400 From: "David B. Nelson" To: References: <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181BF6@wv-mailsrv2.strixsystems.com> <200804181001.34810.stefan.winter@restena.lu> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 10:52:12 -0400 Organization: Elbrys Networks, Inc. Message-ID: <039501c8a163$c8f60620$1f0a0a0a@xpsuperdvd2> 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: AcihKuHbMfFVkL5IT1ybt9emDl20ngAOEbyA In-Reply-To: <200804181001.34810.stefan.winter@restena.lu> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter writes... > Well, if an implementation would do RadSec exclusively, and NOT > listen on UDP/1812 as well, then yes, RADIUS clients would not be > able to communicate with that implementation. > > Reality however is that all the implementations so far can do > both, UDP/1812 and RadSec on TCP/2083, and are able to translate > between both. Such implementations *are* interoperable with existing > RADIUS clients. So one of the elements of our backwards compatibility definition might be that any implementation (server or proxy) of RADIUS over a non-UDP transport that will be used to directly service a NAS MUST additionally implement a "RADIUS Classic" UDP/1812 listener. -- 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 Apr 18 08:09: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 438423A6A91 for ; Fri, 18 Apr 2008 08:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.774 X-Spam-Level: X-Spam-Status: No, score=0.774 tagged_above=-999 required=5 tests=[AWL=1.269, 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 O4Om+9GiZtak for ; Fri, 18 Apr 2008 08:09:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 450E63A6B22 for ; Fri, 18 Apr 2008 08:09:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jms80-000ChZ-CS for radiusext-data@psg.com; Fri, 18 Apr 2008 15:03:52 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jms7n-000CXa-Sr for radiusext@ops.ietf.org; Fri, 18 Apr 2008 15:03:43 +0000 Received: (qmail 6249 invoked from network); 18 Apr 2008 11:03:39 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 18 Apr 2008 11:03:39 -0400 From: "David B. Nelson" To: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 11:00:49 -0400 Organization: Elbrys Networks, Inc. Message-ID: <039601c8a164$fd337a70$1f0a0a0a@xpsuperdvd2> 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: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtg In-Reply-To: <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > One example: the maximum length of 4096 octets for a Radius packet > was chosen (IIRC) based upon the maximum size of a _UDP_ frame that > could be reliably transmitted w/o fragmentation _in the access > networks of the day_. I've forgotten that discussion. Isn't 4096 the maximum size *any* UDP frame, IP fragmentation and reassembly notwithstanding? > It doesn't seem to be very smart to go to all the trouble of > defining RADIUSoTCP while leaving this kind of unnecessary, > UDP-specific limitation in place. I recall that you have many times advocated the need for longer RADIUS packets and/or more/longer RADIUS attributes. It is true that any RADSEC to RADIUS gateway needs to address what is to be done about larger than UDP-size RADSEC messages in translating them to RADIUS messages. I need to see if that issue is covered in the "AAA Transports" RFC... I believe that addressing this issue ought to be another element of our definition of backwards compatibility for RADIUS over non-UDP transports. -- 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 Apr 18 10:44: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 043DD3A6A74 for ; Fri, 18 Apr 2008 10:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.683 X-Spam-Level: * X-Spam-Status: No, score=1.683 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, 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 GOlHpfmcyqIV for ; Fri, 18 Apr 2008 10:44:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 222CE3A6C58 for ; Fri, 18 Apr 2008 10:44:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmuYH-000HRc-JJ for radiusext-data@psg.com; Fri, 18 Apr 2008 17:39:09 +0000 Received: from [69.55.226.174] (helo=colo.trepanning.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmuY6-000HPe-Hd for radiusext@ops.ietf.org; Fri, 18 Apr 2008 17:39:04 +0000 Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 26ACC10224074; Fri, 18 Apr 2008 10:38:58 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 18 Apr 2008 10:38:58 -0700 (PDT) Message-ID: In-Reply-To: References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> Date: Fri, 18 Apr 2008 10:38:58 -0700 (PDT) Subject: RE: RADEXT WG re-charter From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" Cc: "David B. Nelson" , radiusext@ops.ietf.org, "Glen Zorn" , bernard_aboba@hotmail.com User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-radiusext@ops.ietf.org Precedence: bulk Hi Joe, Pardon me for leaping so far back in this thread. Is it a requirement to support multiple pieces of data encrypted with different keys in the same message? If it is then apparently both DTLS and IPsec are out-of-the-running since both those options secure the entire payload with one set of keys. Is this your view? regards, Dan. On Tue, April 15, 2008 1:07 pm, Joseph Salowey (jsalowey) wrote: > There are a few reasons why you would want to wrap keys separately from > other data. As you mentioned, the recommended algorithms for key wrap > may not be suitable for encrypting bulk data without special > consideration and some bulk data encryption algorithms may not be > recommended for key wrap without special consideration. Another reason > is that you may want the entity that handles the keys and their context > to be different from the entity that handles the rest of the attributes. > > > Neither of these reasons forces you to have encryption tied directly to > the key attribute. It is convenient since one is very often interested > in encrypting keys, but you can achieve the same thing with a generic > encryption attribute if you take care. You need to support multiple > pieces of data encrypted with different keys (key IDs, alg IDs, message > boundaries, etc.) in the same message and you need to make sure that the > various supported encryption algorithms are used correctly (type of > cleartext, sufficient randomization, integrity protection, etc.). These > things don't necessarily happen automatically or come for free. > > If you don't consider keys as part of the data you are wrapping for > crypto agility, I'm not sure you will end up with a result that is very > useful. > > Joe >> -----Original Message----- >> From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] >> Sent: Monday, April 14, 2008 10:29 AM >> To: radiusext@ops.ietf.org; 'Glen Zorn' >> Cc: Joseph Salowey (jsalowey); Bernard_Aboba@hotmail.com >> Subject: RE: RADEXT WG re-charter >> >> Glen Zorn writes... >> >> > 'Frankly, my dear, I don't give a damn.' >> >> Cute... >> >> > It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt >> > was posted ... for at least 3 years there have been at 2 (or more) >> > independent, interoperable implementations that were FIPS-certified. >> >> Given that there are implementations of this key-wrap scheme, >> presumably using VSAs, it might be well to publish an >> Information RFC, describing the actual implementations, using >> those VSAs. >> >> > But wait! Let's spend a little (lot) more time conjecturing about >> > another way, a way to solve "the general problem" (AKA "boiling the >> > ocean" if it's a proposal we don't care for). Well, gosh, >> no thanks, >> > but you guys go ahead & have fun! >> >> RADEXT has a chartered work item to address crypto-agility. >> We have requirements for this wok, and we now have an ID >> capturing those requirements. We don't have a requirement to >> specifically address key-wrap, as a separate problem. My >> questions is whether RADEXT really needs to create two drafts >> to satisfy the crypto-agility work item, one for key-wrap and >> one for general purpose encrypted attributes. The fact that >> solutions, and drafts, exist to address key-wrap and >> encrypted attributes separately is a point in favor of >> retaining the separation. I'm just questioning whether >> that's a sufficient basis on which to decide that we need >> such separation of concerns. >> >> If the consensus us of the WG is that we should proceed with >> separate documents for key-wrap and general crypto-agility, >> we can propose doing that in our revised charter. It would >> be nice, however, to have a reason beyond the existence of (4 >> year old) drafts that are structured that way. >> >> >> > > -- > 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 Fri Apr 18 11:20: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 855AE3A6943 for ; Fri, 18 Apr 2008 11:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 QxgeI65uOzVs for ; Fri, 18 Apr 2008 11:20:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB8273A6E99 for ; Fri, 18 Apr 2008 11:20:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmv7s-000NR0-Oe for radiusext-data@psg.com; Fri, 18 Apr 2008 18:15:56 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmv7p-000NQQ-9Z for radiusext@ops.ietf.org; Fri, 18 Apr 2008 18:15:55 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 18 Apr 2008 11:15:50 -0700 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 m3IIFof1002992; Fri, 18 Apr 2008 11:15:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3IIFouH016183; Fri, 18 Apr 2008 18:15:50 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 11:15:49 -0700 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: RADEXT WG re-charter Date: Fri, 18 Apr 2008 11:16:39 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADEXT WG re-charter Thread-Index: Acihexs9wuQMFAPzQfeXaNdQk2jAsQAAxCgw References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> From: "Joseph Salowey (jsalowey)" To: "Dan Harkins" Cc: "David B. Nelson" , , "Glen Zorn" , X-OriginalArrivalTime: 18 Apr 2008 18:15:49.0994 (UTC) FILETIME=[3B20A4A0:01C8A180] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5317; t=1208542550; x=1209406550; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=7MB1kGtGzLUWAYTuqkbIeFQVlVNZl8dJO9bZ0jCs3yQ=; b=teRlrz/Ibgt2L4yeAA/Wb/KiDP3dUzxx5K6VjgQH8sLVwB0PQX1tTFHbWZ 4y35UxnpqiI7zLS2TCqmWqhXULwOSegKBDacT2C0biZSe7mrLj6RywYbrOzQ vpqwvuioD4oxDGjftLGdTQmpuTbM1FYY2GzXZMS3U7abuOeJ1mLRU=; 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 This is not a requirement for all deployments. If it is a requirement then transport security presents a challenge, but it seems you could encrypt the attributes that need to be separated, such as keys, with an appropriate algorithm, such as SIV or the ever unpopular AES keywrap, and then encapsulate the whole message including the encrypted attributes with DTLS, IPSEC, etc. to protect additional attributes in transit. =20 So, I don't view these mechanisms as mutually exclusive.=20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org]=20 > Sent: Friday, April 18, 2008 10:39 AM > To: Joseph Salowey (jsalowey) > Cc: David B. Nelson; radiusext@ops.ietf.org; Glen Zorn;=20 > bernard_aboba@hotmail.com > Subject: RE: RADEXT WG re-charter >=20 >=20 > Hi Joe, >=20 > Pardon me for leaping so far back in this thread. >=20 > Is it a requirement to support multiple pieces of data=20 > encrypted with different keys in the same message? If it is=20 > then apparently both DTLS and IPsec are out-of-the-running=20 > since both those options secure the entire payload with one=20 > set of keys. Is this your view? >=20 > regards, >=20 > Dan. >=20 > On Tue, April 15, 2008 1:07 pm, Joseph Salowey (jsalowey) wrote: > > There are a few reasons why you would want to wrap keys separately=20 > > from other data. As you mentioned, the recommended=20 > algorithms for key=20 > > wrap may not be suitable for encrypting bulk data without special=20 > > consideration and some bulk data encryption algorithms may not be=20 > > recommended for key wrap without special consideration. Another=20 > > reason is that you may want the entity that handles the=20 > keys and their=20 > > context to be different from the entity that handles the=20 > rest of the attributes. > > > > > > Neither of these reasons forces you to have encryption tied=20 > directly=20 > > to the key attribute. It is convenient since one is very often=20 > > interested in encrypting keys, but you can achieve the same=20 > thing with=20 > > a generic encryption attribute if you take care. You need=20 > to support=20 > > multiple pieces of data encrypted with different keys (key IDs, alg=20 > > IDs, message boundaries, etc.) in the same message and you need to=20 > > make sure that the various supported encryption algorithms are used=20 > > correctly (type of cleartext, sufficient randomization, integrity=20 > > protection, etc.). These things don't necessarily happen=20 > automatically or come for free. > > > > If you don't consider keys as part of the data you are wrapping for=20 > > crypto agility, I'm not sure you will end up with a result that is=20 > > very useful. > > > > Joe > >> -----Original Message----- > >> From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] > >> Sent: Monday, April 14, 2008 10:29 AM > >> To: radiusext@ops.ietf.org; 'Glen Zorn' > >> Cc: Joseph Salowey (jsalowey); Bernard_Aboba@hotmail.com > >> Subject: RE: RADEXT WG re-charter > >> > >> Glen Zorn writes... > >> > >> > 'Frankly, my dear, I don't give a damn.' > >> > >> Cute... > >> > >> > It's been nearly 4 years (!) since=20 > draft-zorn-radius-keywrap-00.txt=20 > >> > was posted ... for at least 3 years there have been at 2=20 > (or more)=20 > >> > independent, interoperable implementations that were=20 > FIPS-certified. > >> > >> Given that there are implementations of this key-wrap scheme,=20 > >> presumably using VSAs, it might be well to publish an Information=20 > >> RFC, describing the actual implementations, using those VSAs. > >> > >> > But wait! Let's spend a little (lot) more time=20 > conjecturing about=20 > >> > another way, a way to solve "the general problem" (AKA=20 > "boiling the=20 > >> > ocean" if it's a proposal we don't care for). Well, gosh, > >> no thanks, > >> > but you guys go ahead & have fun! > >> > >> RADEXT has a chartered work item to address crypto-agility. > >> We have requirements for this wok, and we now have an ID capturing=20 > >> those requirements. We don't have a requirement to specifically=20 > >> address key-wrap, as a separate problem. My questions is whether=20 > >> RADEXT really needs to create two drafts to satisfy the=20 > >> crypto-agility work item, one for key-wrap and one for general=20 > >> purpose encrypted attributes. The fact that solutions,=20 > and drafts,=20 > >> exist to address key-wrap and encrypted attributes separately is a=20 > >> point in favor of retaining the separation. I'm just questioning=20 > >> whether that's a sufficient basis on which to decide that we need=20 > >> such separation of concerns. > >> > >> If the consensus us of the WG is that we should proceed=20 > with separate=20 > >> documents for key-wrap and general crypto-agility, we can propose=20 > >> doing that in our revised charter. It would be nice, however, to=20 > >> have a reason beyond the existence of (4 year old) drafts that are=20 > >> structured that way. > >> > >> > >> > > > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > >=20 >=20 >=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 Fri Apr 18 11:26:35 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 9FADA3A6E8D for ; Fri, 18 Apr 2008 11:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.457 X-Spam-Level: X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[AWL=0.952, 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 o7U1Uov84woU for ; Fri, 18 Apr 2008 11:26:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7B853A6E94 for ; Fri, 18 Apr 2008 11:25:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmvDD-000OMK-0Z for radiusext-data@psg.com; Fri, 18 Apr 2008 18:21:27 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmvD9-000OLF-UW for radiusext@ops.ietf.org; Fri, 18 Apr 2008 18:21:25 +0000 Received: (qmail 10796 invoked from network); 18 Apr 2008 14:21:22 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 18 Apr 2008 14:21:22 -0400 From: "David B. Nelson" To: References: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> <001801c89e36$38856cf0$33da787c@arubanetworks.com> <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> <001d01c89e4f$53bed740$33da787c@arubanetworks.com> <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> Subject: RE: RADEXT WG re-charter Date: Fri, 18 Apr 2008 14:18:32 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000701c8a180$9c199ff0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acihexs9wuQMFAPzQfeXaNdQk2jAsQAAxCgwAAB5miA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk Joseph Salowey writes... > ...you could encrypt the attributes that need to be separated, such > as keys, with an appropriate algorithm, such as SIV or the ever > unpopular AES keywrap, and then encapsulate the whole message > including the encrypted attributes with DTLS, IPSEC, etc. to > protect additional attributes in transit. > > So, I don't view these mechanisms as mutually exclusive. In point of fact, based on the notion that NASes may be required to continue using the legacy UDP-based RADIUS, these approaches may be complementary. There may be cases where encrypted attributes are preferable to encrypted transport. The converse may also be true. -- 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 Apr 19 00:21: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 7DD913A6A59 for ; Sat, 19 Apr 2008 00:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[AWL=1.300, 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 9jxM-+qZ2kzQ for ; Sat, 19 Apr 2008 00:21:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12DA83A680F for ; Sat, 19 Apr 2008 00:21:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jn7JX-000O3F-2x for radiusext-data@psg.com; Sat, 19 Apr 2008 07:16:47 +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 1Jn7JU-000O2T-L5 for radiusext@ops.ietf.org; Sat, 19 Apr 2008 07:16:45 +0000 Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id FKFh1Z0010EPchoA600F00; Sat, 19 Apr 2008 07:16:43 +0000 Received: from gzornt61 ([124.120.228.101]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id FKGE1Z0042BuDHo8M00000; Sat, 19 Apr 2008 07:16:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=B7Tq8ZV_dRgA:10 a=No5EcEP4AAAA:8 a=WCR_hvl8ErubTBzRa9AA:9 a=JKa1yXl7Wn8pLpJvkj8A:7 a=pBsRDvJNcwcekRxgySUIYprKUvQA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> <039601c8a164$fd337a70$1f0a0a0a@xpsuperdvd2> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Sat, 19 Apr 2008 14:16:12 +0700 Message-ID: <006601c8a1ed$48962660$65e4787c@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: <039601c8a164$fd337a70$1f0a0a0a@xpsuperdvd2> Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Friday, April 18, 2008 10:01 PM: > Glen Zorn writes... > >> One example: the maximum length of 4096 octets for a Radius packet >> was chosen (IIRC) based upon the maximum size of a _UDP_ frame that >> could be reliably transmitted w/o fragmentation _in the access >> networks of the day_. > > I've forgotten that discussion. Isn't 4096 the maximum size > *any* UDP frame, IP fragmentation and reassembly notwithstanding? No. The Length field in the UDP header is 16 bits long; RFC 768 notes that the minimum length is 8 octets but doesn't mention any maximum. > >> It doesn't seem to be very smart to go to all the trouble of defining >> RADIUSoTCP while leaving this kind of unnecessary, UDP-specific >> limitation in place. > > I recall that you have many times advocated the need for > longer RADIUS packets and/or more/longer RADIUS attributes. This isn't my personal opinion: I have just been echoing customer requests. > > It is true that any RADSEC to RADIUS gateway needs to address > what is to be done about larger than UDP-size RADSEC messages > in translating them to RADIUS messages. > > I need to see if that issue is covered in the "AAA Transports" RFC... > > I believe that addressing this issue ought to be another > element of our definition of backwards compatibility for > RADIUS over non-UDP transports. The first thing to be addressed is the (bogus) usage of the term "backward compatibility" in the proposed charter. PLEASE replace it with "interoperable" or a synonym thereof. > > > > -- > 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 Sat Apr 19 05:53: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 7BA233A6A0C for ; Sat, 19 Apr 2008 05:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 8LrkdakJ0Kek for ; Sat, 19 Apr 2008 05:53:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99DB23A6DF1 for ; Sat, 19 Apr 2008 05:52:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JnCSu-000Fyt-3m for radiusext-data@psg.com; Sat, 19 Apr 2008 12:46:48 +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 1JnCSr-000FyS-R9 for radiusext@ops.ietf.org; Sat, 19 Apr 2008 12:46:46 +0000 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id FNpi1Z00H17UAYkA50BA00; Sat, 19 Apr 2008 12:44:23 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id FQmj1Z00424Kx1C8Z00000; Sat, 19 Apr 2008 12:46:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=B7Tq8ZV_dRgA:10 a=0dKG2OhYFp_XLDJ7HsIA:9 a=VNV_WQWYr_NusQGn0z8h6iVSqWAA:4 a=tqucuuI3bnEA:10 From: "David B. Nelson" To: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> <039601c8a164$fd337a70$1f0a0a0a@xpsuperdvd2> <006601c8a1ed$4896 2660$65e4787c@aruban etworks.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Sat, 19 Apr 2008 08:46:43 -0400 Message-ID: <00f901c8a21b$6cf79240$6401a8c0@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: <006601c8a1ed$48962660$65e4787c@arubanetworks.com> Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuAAC+dgoA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > The first thing to be addressed is the (bogus) usage of the term > "backward compatibility" in the proposed charter. PLEASE replace it > with "interoperable" or a synonym thereof. With all due respect, this seems to me like another "name game" issue. Let's worry more about what we want the properties to be, and less about what we call it -- 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 Apr 19 13:26: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 AA1C73A6DC0 for ; Sat, 19 Apr 2008 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=0.650, 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 ZsuoE2BISRID for ; Sat, 19 Apr 2008 13:26:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0389128C2F5 for ; Sat, 19 Apr 2008 13:26:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JnJYB-0005Xh-Ar for radiusext-data@psg.com; Sat, 19 Apr 2008 20:20:43 +0000 Received: from [76.96.30.64] (helo=QMTA07.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JnJY8-0005WM-V9 for radiusext@ops.ietf.org; Sat, 19 Apr 2008 20:20:42 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id FSZ61Z0020cQ2SLA70LL00; Sat, 19 Apr 2008 20:19:05 +0000 Received: from gzornt61 ([124.120.228.101]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id FYLA1Z0042BuDHo8W00000; Sat, 19 Apr 2008 20:20:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=B7Tq8ZV_dRgA:10 a=No5EcEP4AAAA:8 a=9n8QjLggnuIPydUvhzYA:9 a=TxbOHxc2PL_qwn4GeDoA:7 a=h_rO-5PcItvpuEZ3wKP4BsB8b7AA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> <039601c8a164$fd337a70$1f0a0a0a@xpsuperdvd2> <006601c8a1ed$4896 2660$65e4787c@aruban etworks.com> <00f901c8a21b$6cf79240$6401a8c0@NEWTON603> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Sun, 20 Apr 2008 03:20:07 +0700 Message-ID: <00a501c8a25a$cb4e1eb0$65e4787c@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: <00f901c8a21b$6cf79240$6401a8c0@NEWTON603> Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuAAC+dgoAAPzBRA Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Saturday, April 19, 2008 7:47 PM: > Glen Zorn writes... > >> The first thing to be addressed is the (bogus) usage of the term >> "backward compatibility" in the proposed charter. PLEASE replace it >> with "interoperable" or a synonym thereof. > > With all due respect, this seems to me like another "name game" issue. > Let's worry more about what we want the properties to be, and > less about what we call it A wonderful attitude, except that the only thing the IETF produces is words; therefore, it behooves us to make sure that those words are correct. It's not a game (or if it is, it's the only one in (our) town). > > > > -- > 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 Sun Apr 20 16:02:20 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 57CAB3A6DDF for ; Sun, 20 Apr 2008 16:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.943 X-Spam-Level: X-Spam-Status: No, score=0.943 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 IpgT4cwVUdeT for ; Sun, 20 Apr 2008 16:02:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13CF828C3D9 for ; Sun, 20 Apr 2008 16:01:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JniRQ-000CwD-7q for radiusext-data@psg.com; Sun, 20 Apr 2008 22:55:24 +0000 Received: from [65.55.175.208] (helo=blu139-omc3-s8.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JniRN-000Cvv-Oe for radiusext@ops.ietf.org; Sun, 20 Apr 2008 22:55:23 +0000 Received: from BLU137-DS3 ([65.55.162.188]) by blu139-omc3-s8.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Apr 2008 15:55:21 -0700 X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item Date: Sun, 20 Apr 2008 15:55:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C8A2FE.EF9E48E0" 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 Apr 2008 22:55:21.0098 (UTC) FILETIME=[9C4F86A0:01C8A339] Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C8A2FE.EF9E48E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 71, we discussed adopting the document "Crypto-Agility = Requirements for Remote Dial-In User Service (RADIUS)"=20 as a RADEXT WG work item. In the room, the vote was 11-0 in favor of = this.=20 We are now following up with a mailing list consensus call. The = document is available for inspection here: http://www.ietf.org/internet-drafts/draft-nelson-radext-crypto-agility-re= quirements-00.txt Please post to the mailing list providing your opinion on whether this = document should be adopted as a working group work item.=20 The Consensus call will last until May 6, 2008. ------=_NextPart_000_0013_01C8A2FE.EF9E48E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 71, we discussed adopting the = document=20 "Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)"=20
as a RADEXT WG work item.  In the = room, the vote was 11-0 in favor of this. =
 
We are now following up with a mailing = list=20 consensus call.  The document is available for inspection=20 here:
http://www.ietf.org/internet-drafts/draft-nels= on-radext-crypto-agility-requirements-00.txt
 
Please post to the mailing list = providing your=20 opinion on whether this document = should be=20 adopted as a working group work item. 
 
The Consensus call will = last until May 6,=20 2008.
------=_NextPart_000_0013_01C8A2FE.EF9E48E0-- -- 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 Apr 20 18:19: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 00A513A6F00 for ; Sun, 20 Apr 2008 18:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 yJuRATQnLmbD for ; Sun, 20 Apr 2008 18:19:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 327A93A6F3F for ; Sun, 20 Apr 2008 18:18:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jnkb7-000PQy-7f for radiusext-data@psg.com; Mon, 21 Apr 2008 01:13:33 +0000 Received: from [65.55.175.218] (helo=blu139-omc3-s18.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jnkb4-000PQZ-Gf for radiusext@ops.ietf.org; Mon, 21 Apr 2008 01:13:32 +0000 Received: from BLU137-DS3 ([65.55.162.188]) by blu139-omc3-s18.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Apr 2008 18:13:29 -0700 X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: Preliminary minutes of IETF 71 Date: Sun, 20 Apr 2008 18:13:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01C8A312.3C2EAD90" 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: 21 Apr 2008 01:13:29.0898 (UTC) FILETIME=[E8D208A0:01C8A34C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0132_01C8A312.3C2EAD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable are available here: http://www.drizzle.com/~aboba/RADEXT/IETF71_RADEXT_MINUTES.txt ------=_NextPart_000_0132_01C8A312.3C2EAD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
are available here:
htt= p://www.drizzle.com/~aboba/RADEXT/IETF71_RADEXT_MINUTES.txt
------=_NextPart_000_0132_01C8A312.3C2EAD90-- -- 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 Apr 21 07:15:44 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 C593F3A6A8F for ; Mon, 21 Apr 2008 07:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.196 X-Spam-Level: * X-Spam-Status: No, score=1.196 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_20=-0.74, 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 jLhSYbwiQlM9 for ; Mon, 21 Apr 2008 07:15:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E5DE73A6C08 for ; Mon, 21 Apr 2008 07:15:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JnwbR-0006oV-Hd for radiusext-data@psg.com; Mon, 21 Apr 2008 14:02:41 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JnwbH-0006mH-Hb for radiusext@ops.ietf.org; Mon, 21 Apr 2008 14:02:36 +0000 Received: (qmail 8419 invoked from network); 21 Apr 2008 10:02:29 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 21 Apr 2008 10:02:29 -0400 From: "David B. Nelson" To: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> <039601c8a164$fd337a70$1f0a0a0a@xpsuperdvd2> <006601c8a1ed$4896 2660$65e4787c@aruban etworks.com> <00f901c8a21b$6cf79240$6401a8c0@NEWTON603> <00a501c8a25a$cb4e1eb0$65e4787c@arubanetworks.com> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Mon, 21 Apr 2008 09:59:31 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00fe01c8a3b7$ec35a360$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuAAC+dgoAAPzBRAAFdDMYA= In-Reply-To: <00a501c8a25a$cb4e1eb0$65e4787c@arubanetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > A wonderful attitude, except that the only thing the IETF produces > is words; therefore, it behooves us to make sure that those words > are correct. Yes, and I think that what is correct in this case will not be accurately described by a well-used phrase such as "backwards compatible" or "interoperable". I think we need spell out exactly what we expect, in a couple of sentences. -- 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 Apr 21 22:17: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 98ECD28C435 for ; Mon, 21 Apr 2008 22:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 7XBzlUmVQkhu for ; Mon, 21 Apr 2008 22:17:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F104E28C473 for ; Mon, 21 Apr 2008 22:16:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JoAmX-000IkS-Mv for radiusext-data@psg.com; Tue, 22 Apr 2008 05:11:05 +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 1JoAmV-000Ik6-6X for radiusext@ops.ietf.org; Tue, 22 Apr 2008 05:11:04 +0000 Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id GL5W1Z00t0vp7WLA60mZ00; Tue, 22 Apr 2008 05:10:57 +0000 Received: from gzornt61 ([124.121.211.99]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id GVA61Z00729DjD08R00000; Tue, 22 Apr 2008 05:10:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=B7Tq8ZV_dRgA:10 a=Jf6yTnVVUYeA7JXLULMA:9 a=zEQggUQJiWJIzv2CrY10kx7G7QUA:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> <200804150800.53961.stefan.winter@restena.lu> <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> <48046B45.20008@deployingradius.com> <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> <039601c8a164$fd337a70$1f0a0a0a@xpsuperdvd2> <006601c8a1ed$4896 2660$65e4787c@aruban etworks.com> <00f901c8a21b$6cf79240$6401a8c0@NEWTON603> <00a501c8a25a$cb4e1eb0$65e4787c@arubanetworks.com> <00fe01c8a3b7$ec35a360$1f0a0a0a@xpsuperdvd2> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Tue, 22 Apr 2008 12:10:01 +0700 Message-ID: <006701c8a437$2fe73fe0$63d3797c@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: <00fe01c8a3b7$ec35a360$1f0a0a0a@xpsuperdvd2> Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuAAC+dgoAAPzBRAAFdDMYAAH+3/gA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Monday, April 21, 2008 9:00 PM: > Glen Zorn writes... > >> A wonderful attitude, except that the only thing the IETF produces is >> words; therefore, it behooves us to make sure that those words are >> correct. > > Yes, and I think that what is correct in this case will not be > accurately described by a well-used phrase such as "backwards > compatible" or "interoperable". I think we need spell out > exactly what we expect, in a couple of sentences. Good idea. ... -- 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 Apr 25 05:26: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 92A7B3A6DE6 for ; Fri, 25 Apr 2008 05:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 N39XAtVSJqi2 for ; Fri, 25 Apr 2008 05:26:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EF263A6C2B for ; Fri, 25 Apr 2008 05:25:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpMur-000KS7-Th for radiusext-data@psg.com; Fri, 25 Apr 2008 12:20:37 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpMug-000KQv-NX for radiusext@ops.ietf.org; Fri, 25 Apr 2008 12:20:28 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 41E4276F47; Fri, 25 Apr 2008 14:20:25 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id 31B3B76F42; Fri, 25 Apr 2008 14:20:25 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 25 Apr 2008 14:20:18 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: "'David B. Nelson'" , radiusext@ops.ietf.org References: <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> In-Reply-To: <006601c8a10c$aa26ad00$6ce2787c@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 --nextPart20173584.xWeD92MYle Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > One thing that's wrong is that it ignores the limitations on the RADIUS > PDU that exist primarily (or solely) because of the UDP transport. One > example: the maximum length of 4096 octets for a Radius packet was > chosen (IIRC) based upon the maximum size of a _UDP_ frame that could be > reliably transmitted w/o fragmentation _in the access networks of the > day_. It doesn't seem to be very smart to go to all the trouble of > defining RADIUSoTCP while leaving this kind of unnecessary, UDP-specific > limitation in place. You are perfectly right in condemning the number 4096. It was a limitation= =20 which was pretty much arbitrary. When using TCP, one wouldn't be forced to= =20 keep it if using the TCP transport _only_, from end to end. But giving up on this limitation would completely ruin translation back to= =20 RADIUS-as-in-2865. Which is a common use for existing RADIUS deployments=20 where the NAS speaks RADIUS only. And from what I gathered in this discussi= on=20 so far it is seen as being of paramount importance that this translation=20 works. I think I remember a discussion a while back about what to do with Diameter= =20 Accepts above 4096 Bytes, and how to build a translation agent that is able= =20 to turn this into RADIUS. IIRC, the outcome was that it isn't possible at=20 all, and that an Accept which is too large has to be translated into a=20 Reject. (the discussion took place when talking about NAS-Filter-Rule and t= he=20 issue "Diameter-RADIUS gateway behavior not completely specified" in genera= l) I definitely want to steer clear of this. Unfortunately, the only way of do= ing=20 so is to stay with 4096. Maybe an option would be: if a deployment scenario= =20 can be *sure* to be free of plain RADIUS elements everywhere, it MAY use=20 larger payloads. But honestly, I'd prefer to keep it as simple and error-proof (as in:=20 configuration errors) as possible and forbid larger payloads outright.=20 Greetings, Stefan Winter P.S.: 4096 was the max "_in the access networks of the day_"? Anyone have a= =20 clue what that network was? Token Ring? =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 --nextPart20173584.xWeD92MYle 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) iD8DBQBIEcyI+jm90f8eFWYRAvSaAJ0WAaB9nmQLg55+Twph4BXmxZyjrwCfbtv8 Se85ymEYy8YXcp74C+3OeLU= =VaPK -----END PGP SIGNATURE----- --nextPart20173584.xWeD92MYle-- -- 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 Apr 25 05:42: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 C003A28C329 for ; Fri, 25 Apr 2008 05:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 U8mwo7t6xETu for ; Fri, 25 Apr 2008 05:42:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1857028C2FA for ; Fri, 25 Apr 2008 05:40:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpN9r-000M7D-85 for radiusext-data@psg.com; Fri, 25 Apr 2008 12:36:07 +0000 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpN9j-000M6J-LF for radiusext@ops.ietf.org; Fri, 25 Apr 2008 12:36:05 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D7BBE76F47; Fri, 25 Apr 2008 14:35:58 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id CD6AA76F43; Fri, 25 Apr 2008 14:35:58 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: Consensus Call on RADEXT WG re-charter Date: Fri, 25 Apr 2008 14:35:54 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <8A8CFE8F89C38B41A749C19328C76D63038852B0B6@exchange02.bridgewatersys.com> <000f01c8a04c$ce894380$9ae4787c@arubanetworks.com> In-Reply-To: <000f01c8a04c$ce894380$9ae4787c@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 --nextPart2535261.zC9x1YdXcC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Good point. On that note, it seems that RadSec (as currently specified) > creates one new option but eliminates another. Would it be worthwhile > defining RADIUS over TCP, & then how to use TLS to protect it? That sounds good to me. In some earlier offline discussions I also heard of= =20 people wanting to do RADIUS-over-SSH-TCP-port-forwarding. Not my personal=20 favourite, but still. The idea would then be to have one document about: =2D identifying parts of 2865 that are of relevance for UDP only =2D how to replace those UDP transport specifics with TCP and another document about =2D using (D)TLS to secure the payload (where I would hope that DTLS and TLS have enough similarities to warrant=20 being put into one document. Not sure about that though.) RadSec would then be the application of both in conjunction. Does that sound acceptable? 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 --nextPart2535261.zC9x1YdXcC 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) iD8DBQBIEdAu+jm90f8eFWYRAoBuAJ9LGQ01kVDFcaUBVmPk28wMc/7eIACfe88F OUTtSkXHWTirBdVkHRXTwnY= =MwTd -----END PGP SIGNATURE----- --nextPart2535261.zC9x1YdXcC-- -- 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 Apr 25 10:54:24 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 C24173A6BEB for ; Fri, 25 Apr 2008 10:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=0.433, 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 wxx765EsJwkd for ; Fri, 25 Apr 2008 10:54:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEE8E3A69AE for ; Fri, 25 Apr 2008 10:54:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpS2j-0006tV-Az for radiusext-data@psg.com; Fri, 25 Apr 2008 17:49:05 +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 1JpS2g-0006su-GW for radiusext@ops.ietf.org; Fri, 25 Apr 2008 17:49:03 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA03.westchester.pa.mail.comcast.net with comcast id HmUP1Z0010EZKEL530c100; Fri, 25 Apr 2008 17:47:13 +0000 Received: from gzornt61 ([124.120.229.73]) by OMTA01.westchester.pa.mail.comcast.net with comcast id HtoS1Z0081bfi2c3M00000; Fri, 25 Apr 2008 17:48:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=SihC2Z0xfZYA:10 a=B7Tq8ZV_dRgA:10 a=2z21JQq0E1AdZ4ZqbCwA:9 a=Z7p-pidyvKJFTOc6z_CMvOAtbw0A:4 a=ufO146cb3fEA:10 From: "Glen Zorn" To: "'Stefan Winter'" Cc: "'David B. Nelson'" , References: <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> <200804251420.24075.stefan.winter@restena.lu> Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Sat, 26 Apr 2008 00:48:22 +0700 Message-ID: <009f01c8a6fc$9965bc90$2a01f00a@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: <200804251420.24075.stefan.winter@restena.lu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acimzr8ewPkv1Qq0TsCzOebm1svMlQALCDRg Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter scribbled on Friday, April 25, 2008 7:20 PM: > Hi, > >> One thing that's wrong is that it ignores the limitations on the >> RADIUS PDU that exist primarily (or solely) because of the UDP >> transport. One example: the maximum length of 4096 octets for a >> Radius packet was chosen (IIRC) based upon the maximum size of a >> _UDP_ frame that could be reliably transmitted w/o fragmentation _in >> the access networks of the day_. It doesn't seem to be very smart >> to go to all the trouble of defining RADIUSoTCP while leaving this >> kind of unnecessary, UDP-specific limitation in place. > > You are perfectly right in condemning the number 4096. It was > a limitation which was pretty much arbitrary. When using TCP, > one wouldn't be forced to keep it if using the TCP transport _only_, > from end to end. > > But giving up on this limitation would completely ruin > translation back to RADIUS-as-in-2865. Which is a common use > for existing RADIUS deployments where the NAS speaks RADIUS > only. And from what I gathered in this discussion so far it is > seen as being of paramount importance that this translation works. > > I think I remember a discussion a while back about what to do > with Diameter Accepts above 4096 Bytes, and how to build a > translation agent that is able to turn this into RADIUS. IIRC, > the outcome was that it isn't possible at all, and that an > Accept which is too large has to be translated into a Reject. "Impossible" is such an interesting word, especially when applied to software ;-). It's certainly _technically_ possible to do this with a slight modification of the RADIUS protocol; what seems to be _politically_ impossible is making the slight change. > (the discussion took place when talking about NAS-Filter-Rule > and the issue "Diameter-RADIUS gateway behavior not completely > specified" in general) > > I definitely want to steer clear of this. Unfortunately, the > only way of doing so is to stay with 4096. Maybe an option > would be: if a deployment scenario can be *sure* to be free of > plain RADIUS elements everywhere, it MAY use larger payloads. That seems a bit Draconian: al that is necessary (without the minor change mentioned above) is that RadSec gateways never forward an illegal RADIUS packet to a RADIUS client or server (it's really very useful to treat the two as distinct protocols). ... -- 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 Apr 25 10:54: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 6A0293A6B27 for ; Fri, 25 Apr 2008 10:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[AWL=0.325, 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 YVXVlIzjc487 for ; Fri, 25 Apr 2008 10:54:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95DC43A69AE for ; Fri, 25 Apr 2008 10:54:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpS4Z-00079e-U0 for radiusext-data@psg.com; Fri, 25 Apr 2008 17:50:59 +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 1JpS4X-00079B-Dn for radiusext@ops.ietf.org; Fri, 25 Apr 2008 17:50:58 +0000 Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Ht801Z00Q0ldTLk5701Z00; Fri, 25 Apr 2008 17:50:54 +0000 Received: from gzornt61 ([124.120.229.73]) by OMTA04.westchester.pa.mail.comcast.net with comcast id HtqU1Z0031bfi2c3Q00000; Fri, 25 Apr 2008 17:50:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=592eJo9uy_oA:10 a=onaaZ8aZxgsnFX6hUe4A:9 a=ZpZWqTsfj4DAZ3HZ2Zx_PahH2HwA:4 a=ufO146cb3fEA:10 From: "Glen Zorn" To: "'Stefan Winter'" Cc: References: <8A8CFE8F89C38B41A749C19328C76D63038852B0B6@exchange02.bridgewatersys.com> <000f01c8a04c$ce894380$9ae4787c@arubanetworks.com> <200804251435.58191.stefan.winter@restena.lu> Subject: RE: Consensus Call on RADEXT WG re-charter Date: Sat, 26 Apr 2008 00:50:27 +0700 Message-ID: <00a001c8a6fc$e0c3d900$2a01f00a@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: <200804251435.58191.stefan.winter@restena.lu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acim0Os7jmA7hU+3SvOKhzYI3TSXxAAK8HIA Sender: owner-radiusext@ops.ietf.org Precedence: bulk Stefan Winter scribbled on Friday, April 25, 2008 7:36 PM: ... > > - using (D)TLS to secure the payload > > (where I would hope that DTLS and TLS have enough similarities > to warrant being put into one document. Not sure about that though.) Personally, I'd much prefer keeping these things neatly separated. ... -- 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 Apr 28 10:08: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 7847B28C1CD for ; Mon, 28 Apr 2008 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 EA0ixsiC8uyB for ; Mon, 28 Apr 2008 10:08:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D395F3A6E20 for ; Mon, 28 Apr 2008 10:08:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqWjm-000Haz-7e for radiusext-data@psg.com; Mon, 28 Apr 2008 17:01:58 +0000 Received: from [65.55.175.166] (helo=blu139-omc1-s26.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqWje-000HaB-PH for radiusext@ops.ietf.org; Mon, 28 Apr 2008 17:01:52 +0000 Received: from BLU137-W50 ([65.55.162.182]) by blu139-omc1-s26.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 10:01:50 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d48458f5-4d82-421c-b77e-a9e6d2d8287b_" X-Originating-IP: [65.197.179.22] From: Bernard Aboba To: Glen Zorn , CC: Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr Date: Mon, 28 Apr 2008 10:01:50 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 28 Apr 2008 17:01:50.0057 (UTC) FILETIME=[8CD98590:01C8A951] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_d48458f5-4d82-421c-b77e-a9e6d2d8287b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Last but not least, this draft fairly universally violates several of > the guidelines given in > http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, in > particular those regarding the use of tags to associate different > attributes (called "Index" in this document) and the creation of > "complex" attributes. =20 The issue of "complex attributes" was extensively discussed on=20 the RADEXT WG mailing list, and the Design Guidelines are=20 based on the WG consensus that was derived from the review=20 of this document. =20 In particular, Section 2.1.3 of the Design Guidelines document specifically calls out the distinction between complex attributes which are interpreted by RADIUS, as opposed to "opaque data" which is treated as a string by RADIUS, and interpreted out of band: The only other exception to the recommendation against complex types is for types that can be treated as opaque data by the RADIUS server. For example, the EAP-Message attribute, defined in [RFC3579] Section 3.1 contains a complex data type that is an EAP packet. Since these complex types do not need to be parsed by the RADIUS server, the issues arising from policy language limitations do not arise. Similarly, since attributes of these complex types can be configured on the server using a data type of String, dictionary limitations are also not encountered. Section A.1 below includes a series of checklists that may be used to analyze a design for RECOMMENDED and NOT RECOMMENDED behavior in relation to complex types. If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque, and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque, and it SHOULD be separated into individual RADIUS attributes. > I realize that the RADIUS design guidelines > document is just an Internet-Draft, but it is a radext WG document & has > been under construction for some period of time. =20 The Design Guidelines document text was specifically crafted based on this = particular draft, based on extensive discussion within the RADEXT WG.=20 > More important than > the standardization status of the document is the question of whether > the guidelines make sense;=20 The Design Guidelines document has completed RADEXT WG last call with only = minor comments outstanding. If you had any concerns about whether the document "= makes sense" you should have raised them long ago -- but you did not.=20 > if so, then it may not be such a good idea to so completely ignore them;= =20 Far from ignoring the Design Guidelines, this document has actually been on= e of the primary motivations for creating them -- and the text in Design Guidelines = has been specifically crafted to deal with this particular case.=20 >If not, then maybe radext should rethink this > work item (especially since a co-chair of that WG is also a co-author of > the document under review). Given the extensive discussion on the RADEXT WG list relating to this docum= ent and Design Guidelines, I have personally spent quite a bit of time with Hannes,= Avi and others working on improving the compatibility of this document with the Design Gui= delines. =20 I did not ask to be named as an author -- the other authors suggested this = to me.=20 Given that, I have no particular interest in this document, other than ensu= ring that it does as little violence to the RADIUS protocol as possible. =20 So if you have particular concerns relating to the handling of this documen= t, or can provide specific instances in which this document violates "Design Guidelin= es" (applying the tests in Appendix A, for example), please put them on the table.=20 =20 --_d48458f5-4d82-421c-b77e-a9e6d2d8287b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Last but not least, this draft fairly universally violates several of<= br>> the guidelines given in
> http://www.ietf.org/internet-drafts= /draft-ietf-radext-design-02.txt, in
> particular those regarding the= use of tags to associate different
> attributes (called "Index" in t= his document) and the creation of
> "complex" attributes.

Th= e issue of "complex attributes" was extensively discussed on
the RADEXT= WG mailing list,  and the Design Guidelines are
based on the WG c= onsensus that was derived from the review
of this document.  =

In particular, Section 2.1.3 of the Design Guidelines document spe= cifically
calls out the distinction between complex attributes which are= interpreted
by RADIUS, as opposed to "opaque data" which is treated as = a string
by RADIUS, and interpreted out of band:

   The only=
 other exception to the recommendation against complex types
   is for t=
ypes that can be treated as opaque data by the RADIUS server.
   For exa=
mple, the EAP-Message attribute, defined in [RFC3579] Section
   3.1 con=
tains a complex data type that is an EAP packet.  Since these
   complex=
 types do not need to be parsed by the RADIUS server, the
   issues aris=
ing from policy language limitations do not arise.
   Similarly, since a=
ttributes of these complex types can be configured
   on the server usin=
g a data type of String, dictionary limitations are
   also not encounte=
red.  Section A.1 below includes a series of
   checklists that may be u=
sed to analyze a design for RECOMMENDED and
   NOT RECOMMENDED behavior =
in relation to complex types.

   If the RADIUS Server simply passes =
the contents of an attribute to
   some non-RADIUS portion of the networ=
k, then the data is opaque, and
   SHOULD be defined to be of type Strin=
g.  A concrete way of judging
   this requirement is whether or not the =
attribute definition in the
   RADIUS document contains delineated field=
s for sub-parts of the data.
   If those fields need to be delineated in=
 RADIUS, then the data is not
   opaque, and it SHOULD be separated into=
 individual RADIUS attributes.

> I realize that the RADIUS design guidelines
> docume= nt is just an Internet-Draft, but it is a radext WG document & has
&= gt; been under construction for some period of time.

The Design Gu= idelines document text was specifically crafted based on this particulardraft, based on extensive discussion within the RADEXT WG.

> Mo= re important than
> the standardization status of the document is the= question of whether
> the guidelines make sense;

The Design = Guidelines document has completed RADEXT WG last call with only minor
co= mments outstanding.  If you had any concerns about whether the documen= t "makes
sense" you should have raised them long ago -- but you did not.=

> if so, then it may not be such a good idea to so completely i= gnore them;

Far from ignoring the Design Guidelines, this document = has actually been one of the
primary motivations for creating them -- an= d the text in Design Guidelines has been
specifically crafted to deal wi= th this particular case.

>If not, then maybe radext should rethi= nk this
> work item (especially since a co-chair of that WG is also a= co-author of
> the document under review).

Given the extensiv= e discussion on the RADEXT WG list relating to this document and
Design = Guidelines, I have personally spent quite a bit of time with Hannes, Avi an= d others
working on improving the compatibility of this document with th= e Design Guidelines. 
I did not ask to be named as an author -- th= e other authors suggested this to me.

Given that, I have no particu= lar interest in this document, other than ensuring that it
does as littl= e violence to the RADIUS protocol as possible. 

So if you have= particular concerns relating to the handling of this document, or can
p= rovide specific instances in which this document violates "Design Guideline= s" (applying
the tests in Appendix A, for example), please put them on t= he table.
 
= --_d48458f5-4d82-421c-b77e-a9e6d2d8287b_-- -- 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 Apr 29 01:34: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 EED573A6B12 for ; Tue, 29 Apr 2008 01:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 9nGCyW+Xok6e for ; Tue, 29 Apr 2008 01:34:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA31F3A6A9D for ; Tue, 29 Apr 2008 01:34:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jqkzq-000KfF-90 for radiusext-data@psg.com; Tue, 29 Apr 2008 08:15:30 +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 1Jqkpw-000JYQ-1M for radiusext@ops.ietf.org; Tue, 29 Apr 2008 08:05:26 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 19FDBA7080 for ; Tue, 29 Apr 2008 01:05:06 -0700 (PDT) Message-ID: <4816D596.6010409@nitros9.org> Date: Tue, 29 Apr 2008 10:00:22 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item References: 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@hotmail.com wrote: > Please post to the mailing list providing your opinion on whether this > document should be adopted as a working group work item. I am in favor of accepting this document as a WG item. 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 Tue Apr 29 02:21:04 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 35C353A6AD9 for ; Tue, 29 Apr 2008 02:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_LOW=-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 uQF-0uEsjDzQ for ; Tue, 29 Apr 2008 02:21:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C2433A69FF for ; Tue, 29 Apr 2008 02:21:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jqlad-00010K-OC for radiusext-data@psg.com; Tue, 29 Apr 2008 08:53:31 +0000 Received: from [217.6.95.237] (helo=tcmail23.telekom.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqlM5-000PIz-DI for radiusext@ops.ietf.org; Tue, 29 Apr 2008 08:38:39 +0000 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP for radiusext@ops.ietf.org; Tue, 29 Apr 2008 10:38:27 +0200 Received: from S4DE9JSAANL.ost.t-com.de ([10.125.177.226]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 10:38:27 +0200 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: AW: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item Date: Tue, 29 Apr 2008 10:38:26 +0200 Message-Id: <75404C7727619C4E81A6DABE442E42DD038C6593@S4DE9JSAANL.ost.t-com.de> In-Reply-To: <4816D596.6010409@nitros9.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item Thread-Index: Acip04/A6F3dFULeQ5euo8UoaZ3eNgAAJscg References: <4816D596.6010409@nitros9.org> From: Steigerwaldw To: X-OriginalArrivalTime: 29 Apr 2008 08:38:27.0678 (UTC) FILETIME=[653DF7E0:01C8A9D4] Sender: owner-radiusext@ops.ietf.org Precedence: bulk Bernard_Aboba@hotmail.com wrote: > Please post to the mailing list providing your opinion on whether this = > document should be adopted as a working group work item. I think we should adopt it. regards=20 Wolfgang T-Systems Enterprise Services GmbH Systems Integration BU Telko Wolfgang Steigerwald Goslarer Ufer 35, 10589 Berlin +49 30 3497 2058 +49 69 66531-111 (Fax) +49 171 5664350 (Mobil) E-Mail: wolfgang.steigerwald@t-systems.com Internet: http://www.t-systems.de T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Joachim Langmack*, Wilfried = Peters*,=20 Dr. Stefan Schloter, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you. T-Systems - Business flexibility=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 Tue Apr 29 09:28:00 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 E64E13A685D for ; Tue, 29 Apr 2008 09:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[AWL=-0.123, 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 LA3CbnokAUnp for ; Tue, 29 Apr 2008 09:27:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2CF228C376 for ; Tue, 29 Apr 2008 09:27:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqsXD-000B6T-5p for radiusext-data@psg.com; Tue, 29 Apr 2008 16:18:27 +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 1JqsWm-000B1T-R3 for radiusext@ops.ietf.org; Tue, 29 Apr 2008 16:18:12 +0000 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id KTXB1Z0060FhH24A606B00; Tue, 29 Apr 2008 16:17:48 +0000 Received: from gzornt61 ([124.120.224.185]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id KUGQ1Z00K40dUr88U00000; Tue, 29 Apr 2008 16:17:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=ogMvD3qT86gA:10 a=XWlPapOKyroA:10 a=48vgC7mUAAAA:8 a=AYqbtYIdNE-HJu5YUkIA:9 a=H5KngNLnJG_quXiP3uYA:7 a=CqTR3MkdscxKtbQLYzUtBsIJUL8A:4 a=TJHY2I_JLpsA:10 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: , "Glen Zorn" , , References: Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr Date: Tue, 29 Apr 2008 23:16:18 +0700 Message-ID: <002401c8aa14$79b3e640$3d01f00a@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: AcipUnEZvxg2xJNKQf6kQqsb361hXgAfn0JQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk owner-radiusext@ops.ietf.org <> scribbled on Tuesday, April 29, 2008 12:02 AM: >> Last but not least, this draft fairly universally violates several >> of the guidelines given in >> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, >> in particular those regarding the use of tags to associate different >> attributes (called "Index" in this document) and the creation of >> "complex" attributes. > > The issue of "complex attributes" was extensively discussed on > the RADEXT WG mailing list, and the Design Guidelines are > based on the WG consensus that was derived from the review > of this document. > > In particular, Section 2.1.3 of the Design Guidelines document > specifically calls out the distinction between complex > attributes which are interpreted by RADIUS, as opposed to > "opaque data" which is treated as a string by RADIUS, and > interpreted out of band: > > > The only other exception to the recommendation against complex types > is for types that can be treated as opaque data by the > RADIUS server. > For example, the EAP-Message attribute, defined in [RFC3579] Section > 3.1 contains a complex data type that is an EAP packet. Since these > complex types do not need to be parsed by the RADIUS server, the > issues arising from policy language limitations do not arise. > Similarly, since attributes of these complex types can be configured > on the server using a data type of String, dictionary > limitations are > also not encountered. Section A.1 below includes a series of > checklists that may be used to analyze a design for RECOMMENDED and > NOT RECOMMENDED behavior in relation to complex types. > > If the RADIUS Server simply passes the contents of an attribute to > some non-RADIUS portion of the network, then the data is opaque, and > SHOULD be defined to be of type String. A concrete way of judging > this requirement is whether or not the attribute definition in the > RADIUS document contains delineated fields for sub-parts of > the data. > If those fields need to be delineated in RADIUS, then the > data is not > opaque, and it SHOULD be separated into individual RADIUS > attributes. I'm quite aware of that & if, in fact, the attributes were opaque data that passage would certainly cover it. However, it doesn't appear that either the Location-Information nor the Location-Data Attribute is actually "opaque". > >> I realize that the RADIUS design guidelines document is just an >> Internet-Draft, but it is a radext WG document & has been under >> construction for some period of time. > > The Design Guidelines document text was specifically crafted > based on this particular draft, based on extensive discussion > within the RADEXT WG. > >> More important than >> the standardization status of the document is the question of whether >> the guidelines make sense; > > The Design Guidelines document has completed RADEXT WG last > call with only minor comments outstanding. If you had any > concerns about whether the document "makes sense" you should > have raised them long ago -- but you did not. I wasn't referring to myself: I've reviewed that document several times and have yet to find anything to complain about ;-). I do not, however, pretend to know the opinions of your co-authors or even your own, for that matter: AFAIK, it's not mandatory for a WG Chair to like all of the WG documents, just to ensure that they reflect WG consensus. > >> if so, then it may not be such a good idea to so completely ignore >> them; > > Far from ignoring the Design Guidelines, this document has > actually been one of the primary motivations for creating them > -- and the text in Design Guidelines has been specifically > crafted to deal with this particular case. > >> If not, then maybe radext should rethink this work item (especially >> since a co-chair of that WG is also a co-author of the document >> under review). > > Given the extensive discussion on the RADEXT WG list relating > to this document and Design Guidelines, I have personally > spent quite a bit of time with Hannes, Avi and others working > on improving the compatibility of this document with the > Design Guidelines. > I did not ask to be named as an author -- the other authors > suggested this to me. I don't think that I suggested that you had -- in fact I noted the (perhaps over ;-) enthusiastic appreciation of your efforts by your co-authors in my first message. > > Given that, I have no particular interest in this document, > other than ensuring that it does as little violence to the > RADIUS protocol as possible. > > So if you have particular concerns relating to the handling of > this document, I don't think suggested that, either... > or can provide specific instances in which this > document violates "Design Guidelines" (applying the tests in > Appendix A, for example), please put them on the table. OK. As you noted above, the Design Guidelines say If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque, and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque, and it SHOULD be separated into individual RADIUS attributes. But section 4.7 of the draft under review says o If the RADIUS server requires location information for computing the authorization decision and the RADIUS client does not provide it with the Access-Request message then the Requested-Location- Info Attribute is attached to the Access-Challenge with a hint about what is required. Two cases can be differentiated: 1. If the RADIUS client sends the requested information then the RADIUS server can process the location-based attributes. 2. If the RADIUS server does not receive the requested information in response to the Access-Challenge (including the Requested-Location-Info Attribute) then the RADIUS server may respond with an Access-Reject message with an Error-Cause Attribute (including the "Location-Info-Required" value). The RADIUS server "requires location information for computing the authorization decision". How can it make a decision based upon data that it cannot understand? It doesn't have to because "[i]f the RADIUS client sends the requested information then the RADIUS server can process the location-based attributes". Of course, "process" can mean many things and if these attributes are opaque then "process" might mean just writing the data to a file or forwarding it over some unspecified interface to another entity. So maybe the RADIUS server is making the decision based just upon the fact that it received a Location-Information/Location-Data pair in the new Access-Request (along with the echoed Attributes). The problem is that the RADIUS server didn't request just any old location data; it requested a very specific set of data (in the example later in section 4.7 it is the civic location of the user). AFAICT, the only way that the RADIUS server can tell if it has actually received the information it requested is to examine the Code and Entity sub-fields of the returned Location-Information Attribute and check that there is an associated instance of the Location-Data Attribute by matching the Index fields of the Attributes. Remember that this check for the requested information takes place before the RADIUS server processes the data; this suggests to me that these fields "need to be delineated in RADIUS" and therefore "the data is not opaque, and it SHOULD be separated into individual RADIUS attributes". Further, section A.2.2 of the Design Guidelines asks the (how I wish it was a musical ;-) question: Does the attribute define a complex data type for purposes other than authentication or security? If so, this data type SHOULD be replaced with simpler types, as discussed above in Section A.2.1. Neither the Location-Information nor the Location-Data Attributes seem to be used for authentication (authorization != authentication) or security. Section A.1.3 of the same document says (WRT Attributes encapsulating complex data types): Does the attribute encapsulate an existing data structure defined outside of the RADIUS specifications? Can the attribute be treated as opaque data by RADIUS servers (including proxies?) If both questions can be answered affirmatively, a complex structure MAY be used in a RADIUS specification. The specification of the attribute SHOULD define the encapsulating attribute to be of type String. The specification SHOULD refer to an external document defining the structure. The specification SHOULD NOT define or describe the structure[...] However, section 4.2 of draft-ietf-geopriv-radius-lo describes the structure of the Location-Information Attribute in detail; the question of opacity was dealt with above. WRT the Index fields of the Location-Information and Location-Data Attributes, the fact that they are both mandatory and large avoids many of the drawbacks mentioned WRT tags in the Design Guidelines document, nevertheless that document does state 'new attributes SHOULD use the grouping method described in http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute s-03.txt'. -- 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 Apr 29 10:51: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 20DF83A6970 for ; Tue, 29 Apr 2008 10:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[AWL=1.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 cjwksRVa2sH9 for ; Tue, 29 Apr 2008 10:51:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 37A2A28C286 for ; Tue, 29 Apr 2008 10:51:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jqtu0-000MLh-MP for radiusext-data@psg.com; Tue, 29 Apr 2008 17:46:04 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqttW-000MHk-Pb for radiusext@ops.ietf.org; Tue, 29 Apr 2008 17:45:49 +0000 Received: (qmail 761 invoked from network); 29 Apr 2008 13:45:33 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 29 Apr 2008 13:45:33 -0400 From: "David B. Nelson" To: Cc: , References: <002401c8aa14$79b3e640$3d01f00a@arubanetworks.com> Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr Date: Tue, 29 Apr 2008 13:45:21 -0400 Organization: Elbrys Networks, Inc. Message-ID: <01dc01c8aa20$cbdc31a0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcipUnEZvxg2xJNKQf6kQqsb361hXgAfn0JQABKeVeA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002401c8aa14$79b3e640$3d01f00a@arubanetworks.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk Glen Zorn writes... > I'm quite aware of that & if, in fact, the attributes were opaque > data that passage would certainly cover it. However, it doesn't > appear that either the Location-Information nor the Location-Data > Attribute is actually "opaque". I've offered similar comments early on in the review of this document. The authors explained to me that the attributes used in this document are based upon the PDUs of other protocols. Unfortunately, the PDUs of those other protocols are not suitable for direct encapsulation as "opaque" RADIUS Attributes. Instead, they required slight modifications in order to be suitable for the current purpose. For that reason, the document under review outlines the format and layout of the attributes as if they were not opaque. In fact, they are only partially opaque. Strictly speaking, for a RADIUS Attribute to be "opaque" in the way that the RADIUS Design Guidelines anticipates, it should be merely an encapsulation of a data element defined in another (typically non-RADIUS) document. What we have here is as example of re-use (with minor adaptation) rather than simple encapsulation. I think this fails to meet the spirit, if not the letter, of the RADIUS Design Guidelines. However, after substantial discussion on this point, it became clear that there were no better alternatives that met the needs of the authors of this document. This may be as good as its going to get. > OK. As you noted above, the Design Guidelines say > > If the RADIUS Server simply passes the contents of an attribute to > some non-RADIUS portion of the network, then the data is opaque, and > SHOULD be defined to be of type String. A concrete way of judging > this requirement is whether or not the attribute definition in the > RADIUS document contains delineated fields for sub-parts of the data. > If those fields need to be delineated in RADIUS, then the data is not > opaque, and it SHOULD be separated into individual RADIUS attributes. Strictly speaking, since the attribute contents are framed by field delimiters defined only in the attribute definition, and not in another protocol document, these attributes don't meet the definition of "opaque" as currently used in the RADIUS Design Guidelines. > But section 4.7 of the draft under review says > > o If the RADIUS server requires location information for computing > the authorization decision and the RADIUS client does not provide > it with the Access-Request message then the Requested-Location- > Info Attribute is attached to the Access-Challenge with a hint > about what is required. Two cases can be differentiated: > > 1. If the RADIUS client sends the requested information then the > RADIUS server can process the location-based attributes. > > 2. If the RADIUS server does not receive the requested > information in response to the Access-Challenge (including the > Requested-Location-Info Attribute) then the RADIUS server may > respond with an Access-Reject message with an Error-Cause > Attribute (including the "Location-Info-Required" value). > > The RADIUS server "requires location information for computing the > authorization decision". How can it make a decision based upon data > that it cannot understand? This is where the delineation gets fuzzy. We presume that any information carried in RADIUS messages is related to authentication or authorization. Yes, RADIUS can be (ab)used as a generic transport or all sorts of unrelated information, but that isn't the case in this instance. The use of a "back-end" or "plug-in" module to parse opaque data in a RADIUS Attribute and provide the results back to the RADIUS Server for use in the authentication and authorization decision making process is well established. Certainly that's what the EAP server does for RADIUS EAP-Message Attributes. > Of course, "process" can mean many things and if these attributes are > opaque then "process" might mean just writing the data to a file or > forwarding it over some unspecified interface to another entity. It could mean that. > AFAICT, the only way that the RADIUS server can tell if it has > actually received the information it requested is to examine the > Code and Entity sub-fields of the returned Location-Information > Attribute and check that there is an associated instance of the > Location-Data Attribute by matching the Index fields of the Attributes. Something has to do this work. It could be the RADIUS Server, or it could be the Location Policy Server, acting as a back-end service to the RADIUS Server. This is all a matter of implementation, and has nothing to do with the on-the-wire protocol. > Remember that this check for the requested information takes place > before the RADIUS server processes the data; this suggests to me that > these fields "need to be delineated in RADIUS" and therefore > "the data is not opaque, and it SHOULD be separated into individual > RADIUS attributes". I think that is a very reasonable design choice, and one that would be in compliance with the RADIUS Design Guidelines. However, we've had that discussion and the consensus seemed to be that it was too much of a change, too late in the development cycle for this document. > Further, section A.2.2 of the Design Guidelines > asks the (how I wish it was a musical ;-) question: > > Does the attribute define a complex data type for purposes other than > authentication or security? If so, this data type SHOULD be replaced > with simpler types, as discussed above in Section A.2.1. > > Neither the Location-Information nor the Location-Data Attributes seem > to be used for authentication (authorization != authentication) or > security. Yes, but I believe that this section of text was arrived at after the document under review had completed its WGLC. There is an issue of timing here. If the RADIUS Design Guidelines document had matured more quickly, it may have had a greater impact on the RADIUS Location Attributes document. I had argued along similar lines, but there was resistance to change late on in the development cycle. > Section A.1.3 of the same document says (WRT Attributes > encapsulating complex data types): > > Does the attribute encapsulate an existing data structure defined > outside of the RADIUS specifications? Can the attribute be treated > as opaque data by RADIUS servers (including proxies?) If both > questions can be answered affirmatively, a complex structure MAY be > used in a RADIUS specification. > > The specification of the attribute SHOULD define the encapsulating > attribute to be of type String. The specification SHOULD refer to an > external document defining the structure. The specification SHOULD > NOT define or describe the structure[...] > > However, section 4.2 of draft-ietf-geopriv-radius-lo describes the > structure of the Location-Information Attribute in detail; the question > of opacity was dealt with above. > > WRT the Index fields of the Location-Information and Location-Data > Attributes, the fact that they are both mandatory and large avoids many > of the drawbacks mentioned WRT tags in the Design Guidelines document, > nevertheless that document does state 'new attributes SHOULD use the > grouping method described in http://www.ietf.org/internet-drafts/draft- > ietf-radext-extended-attributes-03.txt'. Yes, if this work were to be started today, one would expect a much greater level of compliance with the RADIUS Design Guidelines 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 Tue Apr 29 11:35:31 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 2FE693A6D0B for ; Tue, 29 Apr 2008 11:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 gawUauhnuyyo for ; Tue, 29 Apr 2008 11:35:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C81C13A6AD8 for ; Tue, 29 Apr 2008 11:35:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JquZo-0001TG-P2 for radiusext-data@psg.com; Tue, 29 Apr 2008 18:29:16 +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 1JquWb-00016o-S1 for radiusext@ops.ietf.org; Tue, 29 Apr 2008 18:27:18 +0000 Received: from BLU137-W52 ([65.55.162.187]) by blu139-omc3-s3.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 11:25:56 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7a880b00-be76-4478-8b33-e2f67dee70b0_" X-Originating-IP: [131.107.0.105] From: Bernard Aboba To: CC: , Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr Date: Tue, 29 Apr 2008 11:25:56 -0700 Importance: Normal In-Reply-To: <01dc01c8aa20$cbdc31a0$5d1216ac@xpsuperdvd2> References: <002401c8aa14$79b3e640$3d01f00a@arubanetworks.com> <01dc01c8aa20$cbdc31a0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2008 18:25:56.0993 (UTC) FILETIME=[77789710:01C8AA26] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_7a880b00-be76-4478-8b33-e2f67dee70b0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > >I'm quite aware of that & if, in fact, the attributes were opaque> data = that passage would certainly cover it. However, it doesn't> appear that eit= her the Location-Information nor the Location-Data> Attribute is actually "= opaque"..... >> Strictly speaking, since the attribute contents are framed by field> del= imiters defined only in the attribute definition, and not in another> proto= col document, these attributes don't meet the definition of "opaque" as> cu= rrently used in the RADIUS Design Guidelines. =20 I think the key question here is whether a RADIUS server would need to=20 explicitly parse these attributes in order to carry out the requirements in the document. If so, then the attributes could not be classified as "opaque", because RADIUS server code would need to change. =20 > > o If the RADIUS server requires location information for computing> > t= he authorization decision and the RADIUS client does not provide> > it with= the Access-Request message then the Requested-Location-> > Info Attribute = is attached to the Access-Challenge with a hint> > about what is required. = Two cases can be differentiated: =20 The question is whether the RADIUS server makes this=20 determination based on the presence/absence of an attribute, or based on parsing its contents. If it's the latter, then the data can't be classified as "opaque".=20 > > 1. If the RADIUS client sends the requested information then the> > RAD= IUS server can process the location-based attributes. =20 For the RADIUS server to determine whether the client sent the=20 set of location information that was requested previously=20 (as opposed to just whether the client send an attribute that may or may not correspond to what was requested), it would seem=20 that parsing would be required. > > 2. If the RADIUS server does not receive the requested> > information i= n response to the Access-Challenge (including the> > Requested-Location-Inf= o Attribute) then the RADIUS server may> > respond with an Access-Reject me= ssage with an Error-Cause> > Attribute (including the "Location-Info-Requir= ed" value).> > > > The RADIUS server "requires location information for com= puting the> > authorization decision". How can it make a decision based upo= n data> > that it cannot understand? =20 If the RADIUS server can make the determination purely based on the presence/absence of the attribute, then it wouldn't need to understand the contents. However, if parsing is required (which seems to be implied by the term "requested information"), then I'd agree that the attribute is not really "opaque".=20 > > AFAICT, the only way that the RADIUS server can tell if it has > > actu= ally received the information it requested is to examine the> > Code and En= tity sub-fields of the returned Location-Information > > Attribute and chec= k that there is an associated instance of the > > Location-Data Attribute b= y matching the Index fields of the Attributes.>=20 If the goal is to determine exactly what kind of information was sent, and whether the requirements were met (as opposed to just determining if an attribute was present or not), then I'd agree.=20 =20 > > Neither the Location-Information nor the Location-Data Attributes seem>= > to be used for authentication (authorization !=3D authentication) or> > = security.=20 Yup. An exception can't be granted based on that criteria. > > WRT the Index fields of the Location-Information and Location-Data> > = Attributes, the fact that they are both mandatory and large avoids many> > = of the drawbacks mentioned WRT tags in the Design Guidelines document,> > n= evertheless that document does state 'new attributes SHOULD use the> > grou= ping method described in http://www.ietf.org/internet-drafts/draft-> > ietf= -radext-extended-attributes-03.txt'. =20 The question here is whether the Index field is actually related to groupin= g or not. = --_7a880b00-be76-4478-8b33-e2f67dee70b0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > >I'm quite aware of that & if, in fact, the attributes were opa= que
> data that passage would certainly cover it. However, it doesn't=
> appear that either the Location-Information nor the Location-Data<= BR>> Attribute is actually "opaque".....
>
> Strictly speaking, since the attribute contents are framed by = field
> delimiters defined only in the attribute definition, and not = in another
> protocol document, these attributes don't meet the defin= ition of "opaque" as
> currently used in the RADIUS Design Guidelines= .
 
I think the key question here is whether a RADIUS server would need to
explicitly parse these attributes in order to carry out the requirements in=
the document.  If so, then the attributes could not be classified as "opaque", because RADIUS server code would need to change. 

> > o If the RADIUS server requires location information for comp= uting
> > the authorization decision and the RADIUS client does no= t provide
> > it with the Access-Request message then the Requeste= d-Location-
> > Info Attribute is attached to the Access-Challenge= with a hint
> > about what is required. Two cases can be differen= tiated:
 
The question is whether the RADIUS server makes this
determination based on the presence/absence of an attribute, or
based on parsing its contents.  If it's the latter, then the data= can't
be classified as "opaque".

> > 1. If the RADIUS client sends the requested information then = the
> > RADIUS server can process the location-based attributes.  
For the RADIUS server to determine whether the client sent the
set of location information that was requested previously
(as opposed to just whether the client send an attribute that may
or may not correspond to what was requested), it would seem
that parsing would be required.

> > 2. If the RADIUS server does not receive the requested
>= ; > information in response to the Access-Challenge (including the
&g= t; > Requested-Location-Info Attribute) then the RADIUS server may
&g= t; > respond with an Access-Reject message with an Error-Cause
> &= gt; Attribute (including the "Location-Info-Required" value).
> > =
> > The RADIUS server "requires location information for computin= g the
> > authorization decision". How can it make a decision base= d upon data
> > that it cannot understand?
 
If the RADIUS server can make the determination purely based on the
presence/absence of the attribute, then it wouldn't need to understand
the contents.  However, if parsing is required (which seems to be impl= ied
by the term "requested information"), then I'd agree that the attribute
is not really "opaque".

> > AFAICT, the only way that the RADIUS server can tell if it ha= s
> > actually received the information it requested is to examin= e the
> > Code and Entity sub-fields of the returned Location-Info= rmation
> > Attribute and check that there is an associated insta= nce of the
> > Location-Data Attribute by matching the Index fiel= ds of the Attributes.
>

If the goal is to determine exactly what kind of information was sent, and<= BR> whether the requirements were met (as opposed to just determining if
an attribute was present or not), then I'd agree.
 
> > Neither the Location-Information nor the Location-Data Attributes= seem
> > to be used for authentication (authorization !=3D authen= tication) or
> > security.

Yup.  An exception can't be granted based on that criteria.
 
> > WRT the Index fields of the Location-Information and Lo= cation-Data
> > Attributes, the fact that they are both mandatory = and large avoids many
> > of the drawbacks mentioned WRT tags in t= he Design Guidelines document,
> > nevertheless that document does= state 'new attributes SHOULD use the
> > grouping method describe= d in http://www.ietf.org/internet-drafts/draft-
> > ietf-radext-ex= tended-attributes-03.txt'.
 
The question here is whether the Index field is actually related to groupin= g
or not. 
= --_7a880b00-be76-4478-8b33-e2f67dee70b0_-- -- 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 Apr 29 15:10: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 4569E3A6C6F for ; Tue, 29 Apr 2008 15:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, 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 u85-5uvnMzk8 for ; Tue, 29 Apr 2008 15:10:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 044063A69E7 for ; Tue, 29 Apr 2008 15:10:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqxvQ-0000oT-Kx for radiusext-data@psg.com; Tue, 29 Apr 2008 22:03:48 +0000 Received: from [65.55.175.202] (helo=blu139-omc3-s2.blu139.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jqxuy-0000lq-HQ for radiusext@ops.ietf.org; Tue, 29 Apr 2008 22:03:34 +0000 Received: from BLU137-W44 ([65.55.162.188]) by blu139-omc3-s2.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2008 15:03:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_88dae544-de2c-4ba5-a148-7904557bd8ca_" X-Originating-IP: [131.107.0.101] From: Bernard Aboba To: Subject: Summary: Consensus call on RADEXT WG re-charter Date: Tue, 29 Apr 2008 15:03:19 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2008 22:03:19.0925 (UTC) FILETIME=[D5AA1250:01C8AA44] Sender: owner-radiusext@ops.ietf.org Precedence: bulk --_88dae544-de2c-4ba5-a148-7904557bd8ca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The consensus call on the RADEXT WG re-charter ended on April 28. After go= ing over the RADEXT WG mailing list discussion, I believe that WG consensu= s was achieved on the=20 proposed charter, modified to take into account the proposed change to the= =20 backwards compatibility language proposed by Glen Zorn: =20 "- All documents produced MUST specify means of interoperation withlegacy R= ADIUS implementations and, if possible, be backward compatible with existin= g RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,= 4675, 5080, 5090 and 5176." =20 Here is my summary of the opinions expressed on the list: In favor (6)Alan DeKok: http://ops.ietf.org/lists/radiusext/2008/msg00221.= htmlStefan Winter: http://ops.ietf.org/lists/radiusext/2008/msg00232.htmlMa= uricio Sanchez: http://ops.ietf.org/lists/radiusext/2008/msg00248.htmlMudit= Goel: http://ops.ietf.org/lists/radiusext/2008/msg00258.htmlMike McCauley:= http://ops.ietf.org/lists/radiusext/2008/msg00234.htmlSteve Hanna: http://= ops.ietf.org/lists/radiusext/2008/msg00206.html No explicit opinion express= ed: (2)Avi Lior: http://ops.ietf.org/lists/radiusext/2008/msg00268.htmlMatt= Holdredge: http://ops.ietf.org/lists/radiusext/2008/msg00240.htmlAgainst (= 2):Glen Zorn (many postings)Joe Salowey: http://ops.ietf.org/lists/radiusex= t/2008/msg00211.html The full text of the modified charter is enclosed bel= ow:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to theRADIUS p= rotocol required to define extensions to the standardattribute space as wel= l as to address cryptographic algorithmagility and use over new secure tran= sports. In addition, RADEXT willwork on RADIUS Design Guidelines and define= new attributes for particular applications of authentication, authorizatio= n and accounting such as NAS management and local area network (LAN) usage.= In order to enable interoperation of heterogeneous RADIUS/Diameterdeployme= nts, all RADEXT WG work items MUST contain a Diametercompatibility section,= outlining how interoperability withDiameter will be maintained.Furthermore= , to ensure backward compatibility with existing RADIUSimplementations, as = well as compatibility between RADIUS and Diameter,the following restriction= s are imposed on extensions considered by theRADEXT WG: =20 - All documents produced MUST specify means of interoperation withlegacy RA= DIUS implementations and, if possible, be backward compatible with existing= RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4= 675, 5080, 5090 and 5176.- All RADIUS work MUST be compatible with equivale= nt facilities inDiameter. Where possible, new attributes should be defined = so thatthe same attribute can be used in both RADIUS and Diameter withouttr= anslation. In other cases a translation considerationssection should be inc= luded in the specification. Work ItemsThe immediate goals of the RADEXT wor= king group are to address thefollowing issues:- RADIUS design guidelines. T= his document will provide guidelines fordesign of RADIUS attributes. It wil= l specifically consider howcomplex data types may be introduced in a robust= manner, maintainingbackwards compatibility with existing RADIUS RFCs, acro= ss all theclasses of attributes: Standard, Vendor-Specific and SDO-Specific= .In addition, it will review RADIUS data types and associatedbackwards comp= atibility issues. - RADIUS Management authorization. This document will def= ine theuse of RADIUS for NAS management over IP. -RADIUS attribute space ex= tension. The standard RADIUS attributespace is currently being depleted. Th= is document will provideadditional standard attribute space, while maintain= ing backwardcompatibility with existing attributes.-RADIUS Cryptographic Al= gorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet= integrity and authentication as wellas attribute confidentiality. Given th= e increasingly successfulattacks being mounted against MD5, the ability to = supportalternative algorithms is required. This work item willinclude docum= entation of RADIUS crypto-agility requirements,as well as development of on= e or more Experimental RFCs providingsupport for negotiation of alternative= cryptographic algorithmsto protect RADIUS.- IEEE 802 attributes. New attri= butes have been proposed tosupport IEEE 802 standards for wired and wireles= s LANs. Thiswork item will support authentication, authorization andaccount= ing attributes needed by IEEE 802 groups includingIEEE 802.1, IEEE 802.11 a= nd IEEE 802.16.- New RADIUS transports. New secure transports for RADIUS wi= llbe developed, including TCP/TLS (RADSEC) and UDP/DTLS.- Documentation of = Status-Server usage. A documentdescribing usage of the Status-Server facili= ty will bedeveloped.Goals and Milestones:Jun 2008 RADIUS Design Guidelines = submitted as a Best Current Practice RFCJun 2008 RADIUS Management Authoriz= ation I-D submitted as a Proposed Standard RFCSep 2008 RADIUS Crypto-agilit= y Requirements submitted as an Informational RFCSep 2008 Extended Attribute= s I-D submitted as a Proposed Standard RFCDec 2008 IEEE 802 Attributes I-D = submitted as a Proposed Standard RFCMar 2009 Status-Server I-D submitted as= a Proposed Standard RFCMar 2009 RADSEC (RADIUS over TCP/TLS) draft submitt= ed as an Experimental RFCJune 2009 RADIUS over DTLS I-D submitted as an Exp= erimental RFCJune 2009 RADIUS Cryptographic Algorithm Agility I-D submitted= as an Experimental RFC --_88dae544-de2c-4ba5-a148-7904557bd8ca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The consensus call on the RADEXT WG re-charter ended on April 28.  Aft= er going over the
RADEXT WG mailing list discussion,  I believe th= at WG consensus was achieved on the
proposed charter, modified to take into account the proposed change to the =
backwards compatibility language proposed by Glen Zorn:
 
"- All documents produced MUST specify means of interoperation with
lega= cy RADIUS implementations and, if possible, be backward
compatible with= existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, 3580= , 4668-4673,4675, 5080, 5090 and 5176."
 
Here is my summary of the opinions expressed on the list:
 
In favor (6)
Alan DeKok: http://ops.ietf.org/lists/rad= iusext/2008/msg00221.html
Stefan Winter: http://ops.ietf.org= /lists/radiusext/2008/msg00232.html
Mauricio Sanchez: http:/= /ops.ietf.org/lists/radiusext/2008/msg00248.html
Mudit Goel: http://ops.ietf.org/lists/radiusext/2008/msg00258.html
Mike McCaule= y: http://ops.ietf.org/lists/radiusext/2008/msg00234.html
St= eve Hanna: http://ops.ietf.org/lists/radiusext/2008/msg00206.html
 
No explicit opinion expressed: (2)
Avi Lior: htt= p://ops.ietf.org/lists/radiusext/2008/msg00268.html
Matt Holdredge: = http://ops.ietf.org/lists/radiusext/2008/msg00240.html
Against (2):
Glen Zorn (many postings)
Joe Salowey: http://o= ps.ietf.org/lists/radiusext/2008/msg00211.html
  
The f= ull text of the modified charter is enclosed below:
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to th= e
RADIUS protocol required to define extensions to the standard
attri= bute space as well as to address cryptographic algorithm
agility and use= over new secure transports. In addition, RADEXT will
work on RADIUS Des= ign Guidelines and define new attributes for
particular applications of= authentication, authorization and
accounting such as NAS management an= d local area network (LAN) usage.

In order to enable interoperation= of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items = MUST contain a Diameter
compatibility section, outlining how interoperab= ility with
Diameter will be maintained.

Furthermore, to ensure ba= ckward compatibility with existing RADIUS
implementations, as well as co= mpatibility between RADIUS and Diameter,
the following restrictions are = imposed on extensions considered by the
RADEXT WG:
 
- All documents produced MUST specify means of interoperation with
= legacy RADIUS implementations and, if possible, be backward
compatible = with existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, = 3580, 4668-4673,4675, 5080, 5090 and 5176.

- All RADIUS work MUST be= compatible with equivalent facilities in
Diameter. Where possible, new = attributes should be defined so that
the same attribute can be used in b= oth RADIUS and Diameter without
translation. In other cases a translatio= n considerations
section should be included in the specification.
&nb= sp;
Work Items

The immediate goals of the RADEXT working group ar= e to address the
following issues:

- RADIUS design guidelines. Th= is document will provide guidelines for
design of RADIUS attributes. It = will specifically consider how
complex data types may be introduced in a= robust manner, maintaining
backwards compatibility with existing RADIUS= RFCs, across all the
classes of attributes: Standard, Vendor-Specific a= nd SDO-Specific.
In addition, it will review RADIUS data types and assoc= iated
backwards compatibility issues.
 
- RADIUS Management a= uthorization. This document will define the
use of RADIUS for NAS manage= ment over IP.

-RADIUS attribute space extension. The standard RADIU= S attribute
space is currently being depleted. This document will provid= e
additional standard attribute space, while maintaining backward
com= patibility with existing attributes.

-RADIUS Cryptographic Algorithm= Agility. RADIUS has traditionally
relied on MD5 for both per-packet in= tegrity and authentication as well
as attribute confidentiality. Given t= he increasingly successful
attacks being mounted against MD5, the abilit= y to support
alternative algorithms is required. This work item will
= include documentation of RADIUS crypto-agility requirements,
as well as = development of one or more Experimental RFCs providing
support for negot= iation of alternative cryptographic algorithms
to protect RADIUS.
- IEEE 802 attributes. New attributes have been proposed to
support IEE= E 802 standards for wired and wireless LANs. This
work item will support= authentication, authorization and
accounting attributes needed by IEEE = 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- N= ew RADIUS transports. New secure transports for RADIUS will
be deve= loped, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of S= tatus-Server usage. A document
describing usage of the Status-Server fac= ility will be
developed.

Goals and Milestones:
Jun 2008 RADIUS= Design Guidelines submitted as a Best Current Practice RFC
Jun 2008 RAD= IUS Management Authorization I-D submitted as a Proposed Standard RFC
Se= p 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC=
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFCDec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
= Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009= RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
Jun= e 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 R= ADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC<= /SPAN>
= --_88dae544-de2c-4ba5-a148-7904557bd8ca_-- -- 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 Apr 29 21:41: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 BD3583A694E for ; Tue, 29 Apr 2008 21:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 WQ6-eKybh9KB for ; Tue, 29 Apr 2008 21:41:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABEE73A6A89 for ; Tue, 29 Apr 2008 21:41:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr41p-000H6T-P3 for radiusext-data@psg.com; Wed, 30 Apr 2008 04:34:49 +0000 Received: from [76.96.30.32] (helo=QMTA03.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr41M-000H3i-Sm for radiusext@ops.ietf.org; Wed, 30 Apr 2008 04:34:35 +0000 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id KgJe1Z00516AWCUA300N00; Wed, 30 Apr 2008 04:31:13 +0000 Received: from CPQ-SEMPRON.mitton.com ([71.192.52.34]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id Kga71Z0030kGrnK8S00000; Wed, 30 Apr 2008 04:34:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=86i-Oc7psYIA:10 a=qNm826lNDJ8A:10 a=48vgC7mUAAAA:8 a=TexhEuN7BkzSaTQmKL8A:9 a=K7_qBdk60N9wpvxWL1wA:7 a=TV7H88JmhgnRCavbtbu6lWWW3PYA:4 a=EfJqPEOeqlMA:10 a=LY0hPdMaydYA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Apr 2008 00:31:25 -0400 To: From: David Mitton Subject: Re: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-radiusext@ops.ietf.org Precedence: bulk Message-Id: On 4/20/2008 06:55 PM, Bernard_Aboba@hotmail.com wrote: >At IETF 71, we discussed adopting the document "Crypto-Agility >Requirements for Remote Dial-In User Service (RADIUS)" >as a RADEXT WG work item. In the room, the vote was 11-0 in favor of this. > >We are now following up with a mailing list consensus call. The >document is available for inspection here: >http://www.ietf.org/internet-drafts/draft-nelson-radext-crypto-agility-requirements-00.txt > >Please post to the mailing list providing your opinion on whether >this document should be adopted as a working group work item. > >The Consensus call will last until May 6, 2008. I am in favor of this. Dave. -- 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 Apr 29 22:52: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 1F6183A6C96 for ; Tue, 29 Apr 2008 22:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_33=0.6, 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 bknL4PQNiHs9 for ; Tue, 29 Apr 2008 22:52:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 123EC3A6C26 for ; Tue, 29 Apr 2008 22:52:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr59M-000Nnm-GS for radiusext-data@psg.com; Wed, 30 Apr 2008 05:46:40 +0000 Received: from [158.64.1.34] (helo=smtp.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr58y-000Nku-CU for radiusext@ops.ietf.org; Wed, 30 Apr 2008 05:46:28 +0000 Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id C366C3027255; Wed, 30 Apr 2008 07:46:14 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by smtp.restena.lu (Postfix) with ESMTP id B41573027248; Wed, 30 Apr 2008 07:46:14 +0200 (CEST) Message-ID: <481807A6.8030907@restena.lu> Date: Wed, 30 Apr 2008 07:46:14 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Summary: Consensus call on RADEXT WG re-charter References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, one suggested correction: over the course of the discussion, it seemed that splitting TCP transport into an own document was deemed worthwhile. Such a document should be added to the milestones. Since the document probably makes use of Status-Server, and the TCP+TLS work in turn uses the TCP transport document, it should have an intermediate place in the timeline. Like Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 Non-UDP Transport Considerations I-D submitted as Proposed Standard(?) RFC Apr 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIGAem+jm90f8eFWYRAj/cAJ4kNB2JNz9Z/A4ufpc/GOaW3kgIJACcDPwc uj+tmcB6Eminto3/2sjhDyw= =Xg8K -----END PGP SIGNATURE----- -- 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 Apr 29 22:59:44 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 405D43A6B36 for ; Tue, 29 Apr 2008 22:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_33=0.6, 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 cMCt0hijTjxC for ; Tue, 29 Apr 2008 22:59:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 652F33A6BCA for ; Tue, 29 Apr 2008 22:59:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr5IQ-000OqN-UK for radiusext-data@psg.com; Wed, 30 Apr 2008 05:56:02 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr5IG-000Ooa-3G for radiusext@ops.ietf.org; Wed, 30 Apr 2008 05:55:57 +0000 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id KhP51Z0030FhH24A404300; Wed, 30 Apr 2008 05:54:01 +0000 Received: from gzornt61 ([124.120.229.134]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id Khuo1Z0022udies8U00000; Wed, 30 Apr 2008 05:55:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=nSf_JJuyM50A:10 a=s16qM3gxi5kA:10 a=6jMQxiku_TN7U9fPeqgA:9 a=swkoUSItDOje3W9F0khU1tvlbIsA:4 a=_3nJN2eeWHAA:10 From: "Glen Zorn" To: "'Stefan Winter'" , "'Bernard Aboba'" Cc: References: <481807A6.8030907@restena.lu> Subject: RE: Summary: Consensus call on RADEXT WG re-charter Date: Wed, 30 Apr 2008 12:54:41 +0700 Message-ID: <001801c8aa86$c181ada0$86e5787c@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: <481807A6.8030907@restena.lu> Thread-Index: Aciqhi5ZrpchA/NpSE2H1Cme4Zp+DAAAEm6w Sender: owner-radiusext@ops.ietf.org Precedence: bulk ... > one suggested correction: over the course of the discussion, > it seemed that splitting TCP transport into an own document > was deemed worthwhile. > > Such a document should be added to the milestones. Since the > document probably makes use of Status-Server, and the TCP+TLS > work in turn uses the TCP transport document, it should have > an intermediate place in the timeline. I agree. ... -- 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 Apr 29 23:04:57 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 72AF13A6A3F for ; Tue, 29 Apr 2008 23:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.012 X-Spam-Level: * X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, 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 jdSkJsiuaxxX for ; Tue, 29 Apr 2008 23:04:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0CED3A6B0E for ; Tue, 29 Apr 2008 23:04:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr5NA-000PP2-Dv for radiusext-data@psg.com; Wed, 30 Apr 2008 06:00:56 +0000 Received: from [208.179.69.44] (helo=WV-MAILSRV2.strixsystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr5Mv-000PNE-IT for radiusext@ops.ietf.org; Wed, 30 Apr 2008 06:00:51 +0000 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: Summary: Consensus call on RADEXT WG re-charter Date: Tue, 29 Apr 2008 23:00:39 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF3125F349@wv-mailsrv2.strixsystems.com> In-Reply-To: <001801c8aa86$c181ada0$86e5787c@arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary: Consensus call on RADEXT WG re-charter Thread-Index: Aciqhi5ZrpchA/NpSE2H1Cme4Zp+DAAAEm6wAAA4oFA= References: <481807A6.8030907@restena.lu> <001801c8aa86$c181ada0$86e5787c@arubanetworks.com> From: "Matt Holdrege" To: "Glen Zorn" , "Stefan Winter" , "Bernard Aboba" Cc: Sender: owner-radiusext@ops.ietf.org Precedence: bulk ... >> one suggested correction: over the course of the discussion, >> it seemed that splitting TCP transport into an own document >> was deemed worthwhile. >>=20 >> Such a document should be added to the milestones. Since the >> document probably makes use of Status-Server, and the TCP+TLS >> work in turn uses the TCP transport document, it should have >> an intermediate place in the timeline.=20 >I agree. Me 2. -Matt -- 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 Apr 30 05:23:35 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 1677C3A6B73 for ; Wed, 30 Apr 2008 05:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-1.035, 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 2mLfHIvb2Afr for ; Wed, 30 Apr 2008 05:23:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B51CC3A6856 for ; Wed, 30 Apr 2008 05:23:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JrBF6-0001Ed-PK for radiusext-data@psg.com; Wed, 30 Apr 2008 12:17:00 +0000 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JrBEt-0001Am-88 for radiusext@ops.ietf.org; Wed, 30 Apr 2008 12:16:52 +0000 X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="116678419" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 30 Apr 2008 08:16:44 -0400 X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="195364523" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Apr 2008 08:16:43 -0400 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: Call for Volunteers for the Renewed AAA Doctors Team Date: Wed, 30 Apr 2008 14:16:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Volunteers for the Renewed AAA Doctors Team Thread-Index: AciqvAw+fUiUSEHARXWZa6ivRsDqxQ== From: "Romascanu, Dan (Dan)" To: , Cc: , , "Ron Bonica" Sender: owner-radiusext@ops.ietf.org Precedence: bulk In discussions with the RADEXT and DIME chairs we decided to refresh the membership of the AAA-Doctors team and to re-emphasize the goals of this team as follows:=20 - Review IETF documents at IETF Last Call or IESG review phases on AAA related issues - Provide advice to IANA on queries related to definition and allocation of parameters related to the AAA protocols - Advice the Area Directors and the Working Groups in the area on issues related to the AAA architecture or protocols We ran a few weeks ago a poll through the current AAA-Doctors list members asking those who are interested to continue to be active or just watch the list to provide affirmative feedback. Based on the answers we received we believe that we should enroll a few new active members on the list. Those of you who are interested to participate in this team by providing reviews of the IETF documents and advice on AAA issues from time to time please let us know.=20 Thanks and Regards, Ron and Dan -- 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 Apr 30 05:38: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 6CA0F3A68FD for ; Wed, 30 Apr 2008 05:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, 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 nTZdxfQYZsKO for ; Wed, 30 Apr 2008 05:38:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B06C33A6856 for ; Wed, 30 Apr 2008 05:38:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JrBVQ-0004Gf-6B for radiusext-data@psg.com; Wed, 30 Apr 2008 12:33:52 +0000 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JrBUv-0004Bq-0p for radiusext@ops.ietf.org; Wed, 30 Apr 2008 12:33:34 +0000 X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="124266203" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 30 Apr 2008 08:33:19 -0400 X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="195373351" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Apr 2008 08:33:18 -0400 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: Summary: Consensus call on RADEXT WG re-charter Date: Wed, 30 Apr 2008 14:33:16 +0200 Message-ID: In-reply-to: <481807A6.8030907@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary: Consensus call on RADEXT WG re-charter Thread-Index: AciqhfpklFK+vOykTTaZrXHA6DA+lQAOBkog References: <481807A6.8030907@restena.lu> From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , "Bernard Aboba" Cc: Sender: owner-radiusext@ops.ietf.org Precedence: bulk Are there volunteers to write this document?=20 Dan =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Stefan Winter > Sent: Wednesday, April 30, 2008 8:46 AM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org > Subject: Re: Summary: Consensus call on RADEXT WG re-charter >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hello, >=20 > one suggested correction: over the course of the discussion,=20 > it seemed that splitting TCP transport into an own document=20 > was deemed worthwhile. >=20 > Such a document should be added to the milestones. Since the=20 > document probably makes use of Status-Server, and the TCP+TLS=20 > work in turn uses the TCP transport document, it should have=20 > an intermediate place in the timeline. Like >=20 > Goals and Milestones: > Jun 2008 RADIUS Design Guidelines submitted as a Best Current=20 > Practice RFC Jun 2008 RADIUS Management Authorization I-D=20 > submitted as a Proposed Standard RFC Sep 2008 RADIUS=20 > Crypto-agility Requirements submitted as an Informational RFC=20 > Sep 2008 Extended Attributes I-D submitted as a Proposed=20 > Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a=20 > Proposed Standard RFC Mar 2009 Status-Server I-D submitted as=20 > a Proposed Standard RFC >=20 > Mar 2009 Non-UDP Transport Considerations I-D submitted as Proposed > Standard(?) RFC >=20 > Apr 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an=20 > Experimental RFC June 2009 RADIUS over DTLS I-D submitted as=20 > an Experimental RFC June 2009 RADIUS Cryptographic Algorithm=20 > Agility I-D submitted as an Experimental RFC >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4-svn0 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org >=20 > iD8DBQFIGAem+jm90f8eFWYRAj/cAJ4kNB2JNz9Z/A4ufpc/GOaW3kgIJACcDPwc > uj+tmcB6Eminto3/2sjhDyw=3D > =3DXg8K > -----END PGP SIGNATURE----- >=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 Wed Apr 30 05:50: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 D09AE3A6E67 for ; Wed, 30 Apr 2008 05:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 ujrTKzw1jo-R for ; Wed, 30 Apr 2008 05:50:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE65E3A6E3F for ; Wed, 30 Apr 2008 05:50:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JrBge-0005qS-Bm for radiusext-data@psg.com; Wed, 30 Apr 2008 12:45:28 +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 1JrBgT-0005oz-Pj for radiusext@ops.ietf.org; Wed, 30 Apr 2008 12:45:23 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id C77ADA7053; Wed, 30 Apr 2008 05:45:15 -0700 (PDT) Message-ID: <481868E1.9060805@nitros9.org> Date: Wed, 30 Apr 2008 14:41:05 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: radiusext@ops.ietf.org Subject: Re: Summary: Consensus call on RADEXT WG re-charter References: <481807A6.8030907@restena.lu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk Romascanu, Dan (Dan) wrote: > Are there volunteers to write this document? TCP transport? I volunteer. 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 Apr 30 05:51: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 D57663A6A07 for ; Wed, 30 Apr 2008 05:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=0.008, 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 PYWF0sEDzzi6 for ; Wed, 30 Apr 2008 05:51:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C32EE3A6E4E for ; Wed, 30 Apr 2008 05:51:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JrBiS-00066r-Eo for radiusext-data@psg.com; Wed, 30 Apr 2008 12:47:20 +0000 Received: from [158.64.1.34] (helo=smtp.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JrBhz-00062N-G0 for radiusext@ops.ietf.org; Wed, 30 Apr 2008 12:47:05 +0000 Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id 18F3730276E5; Wed, 30 Apr 2008 14:46:50 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by smtp.restena.lu (Postfix) with ESMTP id 0805530276D1; Wed, 30 Apr 2008 14:46:50 +0200 (CEST) Message-ID: <48186A39.8080205@restena.lu> Date: Wed, 30 Apr 2008 14:46:49 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Summary: Consensus call on RADEXT WG re-charter References: <481807A6.8030907@restena.lu> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, | Are there volunteers to write this document? Parts of it are in the current RadSec I-D. I volunteer to continue working on it when it's a standalone document. Greetings, Stefan Winter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIGGo5+jm90f8eFWYRAuc6AJ9F3hDXhV3XPZPJifYt44mQKxsZSgCfQmjq 9x30VffT1z9jXz63JkTW5AU= =y6SI -----END PGP SIGNATURE----- -- 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 Apr 30 08: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 8030B28C3CE for ; Wed, 30 Apr 2008 08:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=-0.892, 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 GV5YmAE7QH+e for ; Wed, 30 Apr 2008 08:09:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B32F28C3BF for ; Wed, 30 Apr 2008 08:09:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JrDqx-000P6z-Pd for radiusext-data@psg.com; Wed, 30 Apr 2008 15:04:15 +0000 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JrDqQ-000P28-Q0 for radiusext@ops.ietf.org; Wed, 30 Apr 2008 15:03:58 +0000 X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="txt'?scan'208";a="105321518" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Apr 2008 11:03:34 -0400 X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="txt'?scan'208";a="188598948" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 30 Apr 2008 11:03:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8AAD3.5B780937" Subject: Rechartering request for RADEXT Date: Wed, 30 Apr 2008 17:03:32 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Rechartering request for RADEXT Thread-Index: Aciq01rv4di/9Va2R92AXkZAurNpxw== From: "Romascanu, Dan (Dan)" To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AAD3.5B780937 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the discussions on the list and with the WG chairs I just sent the attached charter proposal to the IESG for IESG and IAB review. Let me thank all the participants in the discussions in the last few weeks for the efforts put in the rechartering discussions and for succeeding to reach consensus on a proposal that in my view makes sense. Of course, you may expect more questions and issues to be raised in the next few weeks as the rechartering proposal goes into IESG/IAB internal review and then in broader IETF review.=20 Dan ------_=_NextPart_001_01C8AAD3.5B780937 Content-Type: text/plain; name="radext-charter-00.txt" Content-Transfer-Encoding: base64 Content-Description: radext-charter-00.txt Content-Disposition: attachment; filename="radext-charter-00.txt" UkFESVVTIEVYVGVuc2lvbnMgKHJhZGV4dCkNCg0KDQpMYXN0IE1vZGlmaWVkOiAyMDA4LTA0LTMw DQogDQpDaGFpcihzKToNCiogIEJlcm5hcmQgQWJvYmEgPEJlcm5hcmRfQWJvYmFAaG90bWFpbC5j b20+IA0KKiAgRGF2aWQgTmVsc29uIDxkLmIubmVsc29uQGNvbWNhc3QubmV0PiANCg0KDQpPcGVy YXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWEgRGlyZWN0b3Iocyk6DQoqICBEYW4gUm9tYXNjYW51 IDxkcm9tYXNjYUBhdmF5YS5jb20+IA0KKiAgUm9uYWxkIEJvbmljYSA8cmJvbmljYUBqdW5pcGVy Lm5ldD4gDQoNCg0KT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVhIEFkdmlzb3I6DQoqICBE YW4gUm9tYXNjYW51IDxkcm9tYXNjYUBhdmF5YS5jb20+IA0KDQoNClRlY2huaWNhbCBBZHZpc29y KHMpOg0KKiAgUGF1bCBDb25nZG9uIDxwYXVsLmNvbmdkb25AaHAuY29tPiANCg0KDQpNYWlsaW5n IExpc3RzOg0KR2VuZXJhbCBEaXNjdXNzaW9uOiByYWRpdXNleHRAb3BzLmlldGYub3JnDQpUbyBT dWJzY3JpYmU6IHJhZGl1c2V4dC1yZXF1ZXN0QG9wcy5pZXRmLm9yZw0KSW4gQm9keTogSW4gQm9k eTogc3Vic2NyaWJlDQpBcmNoaXZlOiBodHRwczovL29wcy5pZXRmLm9yZy9saXN0cy9yYWRpdXNl eHQNCg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOiANCg0KVGhlIFJBRElVUyBFeHRl bnNpb25zIFdvcmtpbmcgR3JvdXAgd2lsbCBmb2N1cyBvbiBleHRlbnNpb25zIHRvIHRoZQ0KUkFE SVVTIHByb3RvY29sIHJlcXVpcmVkIHRvIGRlZmluZSBleHRlbnNpb25zIHRvIHRoZSBzdGFuZGFy ZA0KYXR0cmlidXRlIHNwYWNlIGFzIHdlbGwgYXMgdG8gYWRkcmVzcyBjcnlwdG9ncmFwaGljIGFs Z29yaXRobQ0KYWdpbGl0eSBhbmQgdXNlIG92ZXIgbmV3IHRyYW5zcG9ydHMuIEluIGFkZGl0aW9u LCBSQURFWFQgd2lsbA0Kd29yayBvbiBSQURJVVMgRGVzaWduIEd1aWRlbGluZXMgYW5kIGRlZmlu ZSBuZXcgYXR0cmlidXRlcyBmb3IgDQpwYXJ0aWN1bGFyIGFwcGxpY2F0aW9ucyBvZiBhdXRoZW50 aWNhdGlvbiwgYXV0aG9yaXphdGlvbiBhbmQgDQphY2NvdW50aW5nIHN1Y2ggYXMgTkFTIG1hbmFn ZW1lbnQgYW5kIGxvY2FsIGFyZWEgbmV0d29yayAoTEFOKSB1c2FnZS4gDQoNCkluIG9yZGVyIHRv IGVuYWJsZSBpbnRlcm9wZXJhdGlvbiBvZiBoZXRlcm9nZW5lb3VzIFJBRElVUy9EaWFtZXRlcg0K ZGVwbG95bWVudHMsIGFsbCBSQURFWFQgV0cgd29yayBpdGVtcyBNVVNUIGNvbnRhaW4gYSBEaWFt ZXRlcg0KY29tcGF0aWJpbGl0eSBzZWN0aW9uLCBvdXRsaW5pbmcgaG93IGludGVyb3BlcmFiaWxp dHkgd2l0aA0KRGlhbWV0ZXIgd2lsbCBiZSBtYWludGFpbmVkLg0KDQpGdXJ0aGVybW9yZSwgdG8g ZW5zdXJlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBSQURJVVMNCmltcGxl bWVudGF0aW9ucywgYXMgd2VsbCBhcyBjb21wYXRpYmlsaXR5IGJldHdlZW4gUkFESVVTIGFuZCBE aWFtZXRlciwNCnRoZSBmb2xsb3dpbmcgcmVzdHJpY3Rpb25zIGFyZSBpbXBvc2VkIG9uIGV4dGVu c2lvbnMgY29uc2lkZXJlZCBieSB0aGUNClJBREVYVCBXRzoNCg0KLSBBbGwgZG9jdW1lbnRzIHBy b2R1Y2VkIE1VU1Qgc3BlY2lmeSBtZWFucyBvZiBpbnRlcm9wZXJhdGlvbiB3aXRoDQpsZWdhY3kg UkFESVVTIGltcGxlbWVudGF0aW9ucyBhbmQsIGlmIHBvc3NpYmxlLCBiZSBiYWNrd2FyZCANCmNv bXBhdGlibGUgd2l0aCBleGlzdGluZyBSQURJVVMgUkZDcywgaW5jbHVkaW5nIFJGQ3MgMjg2NS0y ODY5LCANCjMxNjIsIDM1NzUsIDM1NzksIDM1ODAsIDQ2NjgtNDY3Myw0Njc1LCA1MDgwLCA1MDkw IGFuZCA1MTc2Lg0KVHJhbnNwb3J0IHByb2ZpbGVzIHNob3VsZCwgaWYgcG9zc2libGUsIGJlIGNv bXBhdGlibGUgd2l0aCBSRkMgMzUzOS4gDQoNCi0gQWxsIFJBRElVUyB3b3JrIE1VU1QgYmUgY29t cGF0aWJsZSB3aXRoIGVxdWl2YWxlbnQgZmFjaWxpdGllcyBpbg0KRGlhbWV0ZXIuIFdoZXJlIHBv c3NpYmxlLCBuZXcgYXR0cmlidXRlcyBzaG91bGQgYmUgZGVmaW5lZCBzbyB0aGF0DQp0aGUgc2Ft ZSBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQgaW4gYm90aCBSQURJVVMgYW5kIERpYW1ldGVyIHdpdGhv dXQNCnRyYW5zbGF0aW9uLiBJbiBvdGhlciBjYXNlcyBhIHRyYW5zbGF0aW9uIGNvbnNpZGVyYXRp b25zDQpzZWN0aW9uIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCg0K DQpXb3JrIEl0ZW1zDQoNClRoZSBpbW1lZGlhdGUgZ29hbHMgb2YgdGhlIFJBREVYVCB3b3JraW5n IGdyb3VwIGFyZSB0byBhZGRyZXNzIHRoZQ0KZm9sbG93aW5nIGlzc3VlczoNCg0KLSBSQURJVVMg ZGVzaWduIGd1aWRlbGluZXMuIFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92aWRlIGd1aWRlbGluZXMg Zm9yDQpkZXNpZ24gb2YgUkFESVVTIGF0dHJpYnV0ZXMuIEl0IHdpbGwgc3BlY2lmaWNhbGx5IGNv bnNpZGVyIGhvdw0KY29tcGxleCBkYXRhIHR5cGVzIG1heSBiZSBpbnRyb2R1Y2VkIGluIGEgcm9i dXN0IG1hbm5lciwgbWFpbnRhaW5pbmcNCmJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggZXhp c3RpbmcgUkFESVVTIFJGQ3MsIGFjcm9zcyBhbGwgdGhlDQpjbGFzc2VzIG9mIGF0dHJpYnV0ZXM6 IFN0YW5kYXJkLCBWZW5kb3ItU3BlY2lmaWMgYW5kIFNETy1TcGVjaWZpYy4NCkluIGFkZGl0aW9u LCBpdCB3aWxsIHJldmlldyBSQURJVVMgZGF0YSB0eXBlcyBhbmQgYXNzb2NpYXRlZA0KYmFja3dh cmRzIGNvbXBhdGliaWxpdHkgaXNzdWVzLg0KDQotIFJBRElVUyBNYW5hZ2VtZW50IGF1dGhvcml6 YXRpb24uIFRoaXMgZG9jdW1lbnQgd2lsbCBkZWZpbmUgdGhlDQp1c2Ugb2YgUkFESVVTIGZvciBO QVMgbWFuYWdlbWVudCBvdmVyIElQLiANCg0KLVJBRElVUyBhdHRyaWJ1dGUgc3BhY2UgZXh0ZW5z aW9uLiBUaGUgc3RhbmRhcmQgUkFESVVTIGF0dHJpYnV0ZQ0Kc3BhY2UgaXMgY3VycmVudGx5IGJl aW5nIGRlcGxldGVkLiBUaGlzIGRvY3VtZW50IHdpbGwgcHJvdmlkZQ0KYWRkaXRpb25hbCBzdGFu ZGFyZCBhdHRyaWJ1dGUgc3BhY2UsIHdoaWxlIG1haW50YWluaW5nIGJhY2t3YXJkDQpjb21wYXRp YmlsaXR5IHdpdGggZXhpc3RpbmcgYXR0cmlidXRlcy4NCg0KLVJBRElVUyBDcnlwdG9ncmFwaGlj IEFsZ29yaXRobSBBZ2lsaXR5LiBSQURJVVMgaGFzIHRyYWRpdGlvbmFsbHkgDQpyZWxpZWQgb24g TUQ1IGZvciBib3RoIHBlci1wYWNrZXQgaW50ZWdyaXR5IGFuZCBhdXRoZW50aWNhdGlvbiBhcyB3 ZWxsDQphcyBhdHRyaWJ1dGUgY29uZmlkZW50aWFsaXR5LiBHaXZlbiB0aGUgaW5jcmVhc2luZ2x5 IHN1Y2Nlc3NmdWwNCmF0dGFja3MgYmVpbmcgbW91bnRlZCBhZ2FpbnN0IE1ENSwgdGhlIGFiaWxp dHkgdG8gc3VwcG9ydA0KYWx0ZXJuYXRpdmUgYWxnb3JpdGhtcyBpcyByZXF1aXJlZC4gVGhpcyB3 b3JrIGl0ZW0gd2lsbA0KaW5jbHVkZSBkb2N1bWVudGF0aW9uIG9mIFJBRElVUyBjcnlwdG8tYWdp bGl0eSByZXF1aXJlbWVudHMsDQphcyB3ZWxsIGFzIGRldmVsb3BtZW50IG9mIG9uZSBvciBtb3Jl IEV4cGVyaW1lbnRhbCBSRkNzIHByb3ZpZGluZw0Kc3VwcG9ydCBmb3IgbmVnb3RpYXRpb24gb2Yg YWx0ZXJuYXRpdmUgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zDQp0byBwcm90ZWN0IFJBRElVUy4N Cg0KLSBJRUVFIDgwMiBhdHRyaWJ1dGVzLiBOZXcgYXR0cmlidXRlcyBoYXZlIGJlZW4gcHJvcG9z ZWQgdG8NCnN1cHBvcnQgSUVFRSA4MDIgc3RhbmRhcmRzIGZvciB3aXJlZCBhbmQgd2lyZWxlc3Mg TEFOcy4gVGhpcw0Kd29yayBpdGVtIHdpbGwgc3VwcG9ydCBhdXRoZW50aWNhdGlvbiwgYXV0aG9y aXphdGlvbiBhbmQNCmFjY291bnRpbmcgYXR0cmlidXRlcyBuZWVkZWQgYnkgSUVFRSA4MDIgZ3Jv dXBzIGluY2x1ZGluZw0KSUVFRSA4MDIuMSwgSUVFRSA4MDIuMTEgYW5kIElFRUUgODAyLjE2Lg0K DQotIE5ldyBSQURJVVMgdHJhbnNwb3J0cy4gQSByZWxpYWJsZSB0cmFuc3BvcnQgcHJvZmlsZSBm b3INClJBRElVUyB3aWxsIGJlIGRldmVsb3BlZCwgYXMgd2VsbCBhcyBzcGVjaWZpY2F0aW9ucyBm b3IgDQpTZWN1cmUgdHJhbnNwb3J0cywgaW5jbHVkaW5nIFRDUC9UTFMgKFJBRFNFQykgYW5kIFVE UC9EVExTLg0KDQotIERvY3VtZW50YXRpb24gb2YgU3RhdHVzLVNlcnZlciB1c2FnZS4gQSBkb2N1 bWVudA0KZGVzY3JpYmluZyB1c2FnZSBvZiB0aGUgU3RhdHVzLVNlcnZlciBmYWNpbGl0eSB3aWxs IGJlDQpkZXZlbG9wZWQuDQoNCkdvYWxzIGFuZCBNaWxlc3RvbmVzOg0KDQpKdW4gMjAwOCBSQURJ VVMgRGVzaWduIEd1aWRlbGluZXMgc3VibWl0dGVkIGFzIGEgQmVzdCBDdXJyZW50IFByYWN0aWNl IFJGQw0KSnVuIDIwMDggUkFESVVTIE1hbmFnZW1lbnQgQXV0aG9yaXphdGlvbiBJLUQgc3VibWl0 dGVkIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQgUkZDDQpTZXAgMjAwOCBSQURJVVMgQ3J5cHRvLWFn aWxpdHkgUmVxdWlyZW1lbnRzIHN1Ym1pdHRlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQw0KU2Vw IDIwMDggRXh0ZW5kZWQgQXR0cmlidXRlcyBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3Rh bmRhcmQgUkZDDQpEZWMgMjAwOCBJRUVFIDgwMiBBdHRyaWJ1dGVzIEktRCBzdWJtaXR0ZWQgYXMg YSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMNCkphbiAyMDA5IFJlbGlhYmxlIFRyYW5zcG9ydCBQcm9m aWxlIGZvciBSQURJVVMgSS1EIHN1Ym1pdHRlZCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0K TWFyIDIwMDkgU3RhdHVzLVNlcnZlciBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3RhbmRh cmQgUkZDDQpNYXIgMjAwOSBSQURTRUMgKFJBRElVUyBvdmVyIFRDUC9UTFMpIGRyYWZ0IHN1Ym1p dHRlZCBhcyBhbiBFeHBlcmltZW50YWwgUkZDDQpKdW5lIDIwMDkgUkFESVVTIG92ZXIgRFRMUyBJ LUQgc3VibWl0dGVkIGFzIGFuIEV4cGVyaW1lbnRhbCBSRkMNCkp1bmUgMjAwOSBSQURJVVMgQ3J5 cHRvZ3JhcGhpYyBBbGdvcml0aG0gQWdpbGl0eSBJLUQgc3VibWl0dGVkIGFzIGFuIEV4cGVyaW1l bnRhbCBSRkMNCg0K ------_=_NextPart_001_01C8AAD3.5B780937-- -- 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, 30 Apr 2008 15:05:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8AAD3.5B780937" Subject: Rechartering request for RADEXT Date: Wed, 30 Apr 2008 17:03:32 +0200 Message-ID: Thread-Topic: Rechartering request for RADEXT Thread-Index: Aciq01rv4di/9Va2R92AXkZAurNpxw== From: "Romascanu, Dan (Dan)" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AAD3.5B780937 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the discussions on the list and with the WG chairs I just sent the attached charter proposal to the IESG for IESG and IAB review. Let me thank all the participants in the discussions in the last few weeks for the efforts put in the rechartering discussions and for succeeding to reach consensus on a proposal that in my view makes sense. Of course, you may expect more questions and issues to be raised in the next few weeks as the rechartering proposal goes into IESG/IAB internal review and then in broader IETF review.=20 Dan ------_=_NextPart_001_01C8AAD3.5B780937 Content-Type: text/plain; name="radext-charter-00.txt" Content-Transfer-Encoding: base64 Content-Description: radext-charter-00.txt Content-Disposition: attachment; filename="radext-charter-00.txt" UkFESVVTIEVYVGVuc2lvbnMgKHJhZGV4dCkNCg0KDQpMYXN0IE1vZGlmaWVkOiAyMDA4LTA0LTMw DQogDQpDaGFpcihzKToNCiogIEJlcm5hcmQgQWJvYmEgPEJlcm5hcmRfQWJvYmFAaG90bWFpbC5j b20+IA0KKiAgRGF2aWQgTmVsc29uIDxkLmIubmVsc29uQGNvbWNhc3QubmV0PiANCg0KDQpPcGVy YXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWEgRGlyZWN0b3Iocyk6DQoqICBEYW4gUm9tYXNjYW51 IDxkcm9tYXNjYUBhdmF5YS5jb20+IA0KKiAgUm9uYWxkIEJvbmljYSA8cmJvbmljYUBqdW5pcGVy Lm5ldD4gDQoNCg0KT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVhIEFkdmlzb3I6DQoqICBE YW4gUm9tYXNjYW51IDxkcm9tYXNjYUBhdmF5YS5jb20+IA0KDQoNClRlY2huaWNhbCBBZHZpc29y KHMpOg0KKiAgUGF1bCBDb25nZG9uIDxwYXVsLmNvbmdkb25AaHAuY29tPiANCg0KDQpNYWlsaW5n IExpc3RzOg0KR2VuZXJhbCBEaXNjdXNzaW9uOiByYWRpdXNleHRAb3BzLmlldGYub3JnDQpUbyBT dWJzY3JpYmU6IHJhZGl1c2V4dC1yZXF1ZXN0QG9wcy5pZXRmLm9yZw0KSW4gQm9keTogSW4gQm9k eTogc3Vic2NyaWJlDQpBcmNoaXZlOiBodHRwczovL29wcy5pZXRmLm9yZy9saXN0cy9yYWRpdXNl eHQNCg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOiANCg0KVGhlIFJBRElVUyBFeHRl bnNpb25zIFdvcmtpbmcgR3JvdXAgd2lsbCBmb2N1cyBvbiBleHRlbnNpb25zIHRvIHRoZQ0KUkFE SVVTIHByb3RvY29sIHJlcXVpcmVkIHRvIGRlZmluZSBleHRlbnNpb25zIHRvIHRoZSBzdGFuZGFy ZA0KYXR0cmlidXRlIHNwYWNlIGFzIHdlbGwgYXMgdG8gYWRkcmVzcyBjcnlwdG9ncmFwaGljIGFs Z29yaXRobQ0KYWdpbGl0eSBhbmQgdXNlIG92ZXIgbmV3IHRyYW5zcG9ydHMuIEluIGFkZGl0aW9u LCBSQURFWFQgd2lsbA0Kd29yayBvbiBSQURJVVMgRGVzaWduIEd1aWRlbGluZXMgYW5kIGRlZmlu ZSBuZXcgYXR0cmlidXRlcyBmb3IgDQpwYXJ0aWN1bGFyIGFwcGxpY2F0aW9ucyBvZiBhdXRoZW50 aWNhdGlvbiwgYXV0aG9yaXphdGlvbiBhbmQgDQphY2NvdW50aW5nIHN1Y2ggYXMgTkFTIG1hbmFn ZW1lbnQgYW5kIGxvY2FsIGFyZWEgbmV0d29yayAoTEFOKSB1c2FnZS4gDQoNCkluIG9yZGVyIHRv IGVuYWJsZSBpbnRlcm9wZXJhdGlvbiBvZiBoZXRlcm9nZW5lb3VzIFJBRElVUy9EaWFtZXRlcg0K ZGVwbG95bWVudHMsIGFsbCBSQURFWFQgV0cgd29yayBpdGVtcyBNVVNUIGNvbnRhaW4gYSBEaWFt ZXRlcg0KY29tcGF0aWJpbGl0eSBzZWN0aW9uLCBvdXRsaW5pbmcgaG93IGludGVyb3BlcmFiaWxp dHkgd2l0aA0KRGlhbWV0ZXIgd2lsbCBiZSBtYWludGFpbmVkLg0KDQpGdXJ0aGVybW9yZSwgdG8g ZW5zdXJlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBSQURJVVMNCmltcGxl bWVudGF0aW9ucywgYXMgd2VsbCBhcyBjb21wYXRpYmlsaXR5IGJldHdlZW4gUkFESVVTIGFuZCBE aWFtZXRlciwNCnRoZSBmb2xsb3dpbmcgcmVzdHJpY3Rpb25zIGFyZSBpbXBvc2VkIG9uIGV4dGVu c2lvbnMgY29uc2lkZXJlZCBieSB0aGUNClJBREVYVCBXRzoNCg0KLSBBbGwgZG9jdW1lbnRzIHBy b2R1Y2VkIE1VU1Qgc3BlY2lmeSBtZWFucyBvZiBpbnRlcm9wZXJhdGlvbiB3aXRoDQpsZWdhY3kg UkFESVVTIGltcGxlbWVudGF0aW9ucyBhbmQsIGlmIHBvc3NpYmxlLCBiZSBiYWNrd2FyZCANCmNv bXBhdGlibGUgd2l0aCBleGlzdGluZyBSQURJVVMgUkZDcywgaW5jbHVkaW5nIFJGQ3MgMjg2NS0y ODY5LCANCjMxNjIsIDM1NzUsIDM1NzksIDM1ODAsIDQ2NjgtNDY3Myw0Njc1LCA1MDgwLCA1MDkw IGFuZCA1MTc2Lg0KVHJhbnNwb3J0IHByb2ZpbGVzIHNob3VsZCwgaWYgcG9zc2libGUsIGJlIGNv bXBhdGlibGUgd2l0aCBSRkMgMzUzOS4gDQoNCi0gQWxsIFJBRElVUyB3b3JrIE1VU1QgYmUgY29t cGF0aWJsZSB3aXRoIGVxdWl2YWxlbnQgZmFjaWxpdGllcyBpbg0KRGlhbWV0ZXIuIFdoZXJlIHBv c3NpYmxlLCBuZXcgYXR0cmlidXRlcyBzaG91bGQgYmUgZGVmaW5lZCBzbyB0aGF0DQp0aGUgc2Ft ZSBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQgaW4gYm90aCBSQURJVVMgYW5kIERpYW1ldGVyIHdpdGhv dXQNCnRyYW5zbGF0aW9uLiBJbiBvdGhlciBjYXNlcyBhIHRyYW5zbGF0aW9uIGNvbnNpZGVyYXRp b25zDQpzZWN0aW9uIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCg0K DQpXb3JrIEl0ZW1zDQoNClRoZSBpbW1lZGlhdGUgZ29hbHMgb2YgdGhlIFJBREVYVCB3b3JraW5n IGdyb3VwIGFyZSB0byBhZGRyZXNzIHRoZQ0KZm9sbG93aW5nIGlzc3VlczoNCg0KLSBSQURJVVMg ZGVzaWduIGd1aWRlbGluZXMuIFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92aWRlIGd1aWRlbGluZXMg Zm9yDQpkZXNpZ24gb2YgUkFESVVTIGF0dHJpYnV0ZXMuIEl0IHdpbGwgc3BlY2lmaWNhbGx5IGNv bnNpZGVyIGhvdw0KY29tcGxleCBkYXRhIHR5cGVzIG1heSBiZSBpbnRyb2R1Y2VkIGluIGEgcm9i dXN0IG1hbm5lciwgbWFpbnRhaW5pbmcNCmJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggZXhp c3RpbmcgUkFESVVTIFJGQ3MsIGFjcm9zcyBhbGwgdGhlDQpjbGFzc2VzIG9mIGF0dHJpYnV0ZXM6 IFN0YW5kYXJkLCBWZW5kb3ItU3BlY2lmaWMgYW5kIFNETy1TcGVjaWZpYy4NCkluIGFkZGl0aW9u LCBpdCB3aWxsIHJldmlldyBSQURJVVMgZGF0YSB0eXBlcyBhbmQgYXNzb2NpYXRlZA0KYmFja3dh cmRzIGNvbXBhdGliaWxpdHkgaXNzdWVzLg0KDQotIFJBRElVUyBNYW5hZ2VtZW50IGF1dGhvcml6 YXRpb24uIFRoaXMgZG9jdW1lbnQgd2lsbCBkZWZpbmUgdGhlDQp1c2Ugb2YgUkFESVVTIGZvciBO QVMgbWFuYWdlbWVudCBvdmVyIElQLiANCg0KLVJBRElVUyBhdHRyaWJ1dGUgc3BhY2UgZXh0ZW5z aW9uLiBUaGUgc3RhbmRhcmQgUkFESVVTIGF0dHJpYnV0ZQ0Kc3BhY2UgaXMgY3VycmVudGx5IGJl aW5nIGRlcGxldGVkLiBUaGlzIGRvY3VtZW50IHdpbGwgcHJvdmlkZQ0KYWRkaXRpb25hbCBzdGFu ZGFyZCBhdHRyaWJ1dGUgc3BhY2UsIHdoaWxlIG1haW50YWluaW5nIGJhY2t3YXJkDQpjb21wYXRp YmlsaXR5IHdpdGggZXhpc3RpbmcgYXR0cmlidXRlcy4NCg0KLVJBRElVUyBDcnlwdG9ncmFwaGlj IEFsZ29yaXRobSBBZ2lsaXR5LiBSQURJVVMgaGFzIHRyYWRpdGlvbmFsbHkgDQpyZWxpZWQgb24g TUQ1IGZvciBib3RoIHBlci1wYWNrZXQgaW50ZWdyaXR5IGFuZCBhdXRoZW50aWNhdGlvbiBhcyB3 ZWxsDQphcyBhdHRyaWJ1dGUgY29uZmlkZW50aWFsaXR5LiBHaXZlbiB0aGUgaW5jcmVhc2luZ2x5 IHN1Y2Nlc3NmdWwNCmF0dGFja3MgYmVpbmcgbW91bnRlZCBhZ2FpbnN0IE1ENSwgdGhlIGFiaWxp dHkgdG8gc3VwcG9ydA0KYWx0ZXJuYXRpdmUgYWxnb3JpdGhtcyBpcyByZXF1aXJlZC4gVGhpcyB3 b3JrIGl0ZW0gd2lsbA0KaW5jbHVkZSBkb2N1bWVudGF0aW9uIG9mIFJBRElVUyBjcnlwdG8tYWdp bGl0eSByZXF1aXJlbWVudHMsDQphcyB3ZWxsIGFzIGRldmVsb3BtZW50IG9mIG9uZSBvciBtb3Jl IEV4cGVyaW1lbnRhbCBSRkNzIHByb3ZpZGluZw0Kc3VwcG9ydCBmb3IgbmVnb3RpYXRpb24gb2Yg YWx0ZXJuYXRpdmUgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zDQp0byBwcm90ZWN0IFJBRElVUy4N Cg0KLSBJRUVFIDgwMiBhdHRyaWJ1dGVzLiBOZXcgYXR0cmlidXRlcyBoYXZlIGJlZW4gcHJvcG9z ZWQgdG8NCnN1cHBvcnQgSUVFRSA4MDIgc3RhbmRhcmRzIGZvciB3aXJlZCBhbmQgd2lyZWxlc3Mg TEFOcy4gVGhpcw0Kd29yayBpdGVtIHdpbGwgc3VwcG9ydCBhdXRoZW50aWNhdGlvbiwgYXV0aG9y aXphdGlvbiBhbmQNCmFjY291bnRpbmcgYXR0cmlidXRlcyBuZWVkZWQgYnkgSUVFRSA4MDIgZ3Jv dXBzIGluY2x1ZGluZw0KSUVFRSA4MDIuMSwgSUVFRSA4MDIuMTEgYW5kIElFRUUgODAyLjE2Lg0K DQotIE5ldyBSQURJVVMgdHJhbnNwb3J0cy4gQSByZWxpYWJsZSB0cmFuc3BvcnQgcHJvZmlsZSBm b3INClJBRElVUyB3aWxsIGJlIGRldmVsb3BlZCwgYXMgd2VsbCBhcyBzcGVjaWZpY2F0aW9ucyBm b3IgDQpTZWN1cmUgdHJhbnNwb3J0cywgaW5jbHVkaW5nIFRDUC9UTFMgKFJBRFNFQykgYW5kIFVE UC9EVExTLg0KDQotIERvY3VtZW50YXRpb24gb2YgU3RhdHVzLVNlcnZlciB1c2FnZS4gQSBkb2N1 bWVudA0KZGVzY3JpYmluZyB1c2FnZSBvZiB0aGUgU3RhdHVzLVNlcnZlciBmYWNpbGl0eSB3aWxs IGJlDQpkZXZlbG9wZWQuDQoNCkdvYWxzIGFuZCBNaWxlc3RvbmVzOg0KDQpKdW4gMjAwOCBSQURJ VVMgRGVzaWduIEd1aWRlbGluZXMgc3VibWl0dGVkIGFzIGEgQmVzdCBDdXJyZW50IFByYWN0aWNl IFJGQw0KSnVuIDIwMDggUkFESVVTIE1hbmFnZW1lbnQgQXV0aG9yaXphdGlvbiBJLUQgc3VibWl0 dGVkIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQgUkZDDQpTZXAgMjAwOCBSQURJVVMgQ3J5cHRvLWFn aWxpdHkgUmVxdWlyZW1lbnRzIHN1Ym1pdHRlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQw0KU2Vw IDIwMDggRXh0ZW5kZWQgQXR0cmlidXRlcyBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3Rh bmRhcmQgUkZDDQpEZWMgMjAwOCBJRUVFIDgwMiBBdHRyaWJ1dGVzIEktRCBzdWJtaXR0ZWQgYXMg YSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMNCkphbiAyMDA5IFJlbGlhYmxlIFRyYW5zcG9ydCBQcm9m aWxlIGZvciBSQURJVVMgSS1EIHN1Ym1pdHRlZCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0K TWFyIDIwMDkgU3RhdHVzLVNlcnZlciBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3RhbmRh cmQgUkZDDQpNYXIgMjAwOSBSQURTRUMgKFJBRElVUyBvdmVyIFRDUC9UTFMpIGRyYWZ0IHN1Ym1p dHRlZCBhcyBhbiBFeHBlcmltZW50YWwgUkZDDQpKdW5lIDIwMDkgUkFESVVTIG92ZXIgRFRMUyBJ LUQgc3VibWl0dGVkIGFzIGFuIEV4cGVyaW1lbnRhbCBSRkMNCkp1bmUgMjAwOSBSQURJVVMgQ3J5 cHRvZ3JhcGhpYyBBbGdvcml0aG0gQWdpbGl0eSBJLUQgc3VibWl0dGVkIGFzIGFuIEV4cGVyaW1l bnRhbCBSRkMNCg0K ------_=_NextPart_001_01C8AAD3.5B780937-- -- 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, 30 Apr 2008 12:48:21 +0000 Message-ID: <48186A39.8080205@restena.lu> Date: Wed, 30 Apr 2008 14:46:49 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Summary: Consensus call on RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, | Are there volunteers to write this document? Parts of it are in the current RadSec I-D. I volunteer to continue working on it when it's a standalone document. Greetings, Stefan Winter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIGGo5+jm90f8eFWYRAuc6AJ9F3hDXhV3XPZPJifYt44mQKxsZSgCfQmjq 9x30VffT1z9jXz63JkTW5AU= =y6SI -----END PGP SIGNATURE----- -- 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, 30 Apr 2008 12:46:20 +0000 Message-ID: <481868E1.9060805@nitros9.org> Date: Wed, 30 Apr 2008 14:41:05 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: radiusext@ops.ietf.org Subject: Re: Summary: Consensus call on RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Romascanu, Dan (Dan) wrote: > Are there volunteers to write this document? TCP transport? I volunteer. 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, 30 Apr 2008 12:34:48 +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: Summary: Consensus call on RADEXT WG re-charter Date: Wed, 30 Apr 2008 14:33:16 +0200 Message-ID: Thread-Topic: Summary: Consensus call on RADEXT WG re-charter Thread-Index: AciqhfpklFK+vOykTTaZrXHA6DA+lQAOBkog From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , "Bernard Aboba" Cc: Are there volunteers to write this document?=20 Dan =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Stefan Winter > Sent: Wednesday, April 30, 2008 8:46 AM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org > Subject: Re: Summary: Consensus call on RADEXT WG re-charter >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hello, >=20 > one suggested correction: over the course of the discussion,=20 > it seemed that splitting TCP transport into an own document=20 > was deemed worthwhile. >=20 > Such a document should be added to the milestones. Since the=20 > document probably makes use of Status-Server, and the TCP+TLS=20 > work in turn uses the TCP transport document, it should have=20 > an intermediate place in the timeline. Like >=20 > Goals and Milestones: > Jun 2008 RADIUS Design Guidelines submitted as a Best Current=20 > Practice RFC Jun 2008 RADIUS Management Authorization I-D=20 > submitted as a Proposed Standard RFC Sep 2008 RADIUS=20 > Crypto-agility Requirements submitted as an Informational RFC=20 > Sep 2008 Extended Attributes I-D submitted as a Proposed=20 > Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a=20 > Proposed Standard RFC Mar 2009 Status-Server I-D submitted as=20 > a Proposed Standard RFC >=20 > Mar 2009 Non-UDP Transport Considerations I-D submitted as Proposed > Standard(?) RFC >=20 > Apr 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an=20 > Experimental RFC June 2009 RADIUS over DTLS I-D submitted as=20 > an Experimental RFC June 2009 RADIUS Cryptographic Algorithm=20 > Agility I-D submitted as an Experimental RFC >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4-svn0 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org >=20 > iD8DBQFIGAem+jm90f8eFWYRAj/cAJ4kNB2JNz9Z/A4ufpc/GOaW3kgIJACcDPwc > uj+tmcB6Eminto3/2sjhDyw=3D > =3DXg8K > -----END PGP SIGNATURE----- >=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: Wed, 30 Apr 2008 12:18:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Call for Volunteers for the Renewed AAA Doctors Team Date: Wed, 30 Apr 2008 14:16:41 +0200 Message-ID: Thread-Topic: Call for Volunteers for the Renewed AAA Doctors Team Thread-Index: AciqvAw+fUiUSEHARXWZa6ivRsDqxQ== From: "Romascanu, Dan (Dan)" To: , Cc: , , "Ron Bonica" In discussions with the RADEXT and DIME chairs we decided to refresh the membership of the AAA-Doctors team and to re-emphasize the goals of this team as follows:=20 - Review IETF documents at IETF Last Call or IESG review phases on AAA related issues - Provide advice to IANA on queries related to definition and allocation of parameters related to the AAA protocols - Advice the Area Directors and the Working Groups in the area on issues related to the AAA architecture or protocols We ran a few weeks ago a poll through the current AAA-Doctors list members asking those who are interested to continue to be active or just watch the list to provide affirmative feedback. Based on the answers we received we believe that we should enroll a few new active members on the list. Those of you who are interested to participate in this team by providing reviews of the IETF documents and advice on AAA issues from time to time please let us know.=20 Thanks and Regards, Ron and Dan -- 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, 30 Apr 2008 06:01:44 +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: Summary: Consensus call on RADEXT WG re-charter Date: Tue, 29 Apr 2008 23:00:39 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF3125F349@wv-mailsrv2.strixsystems.com> Thread-Topic: Summary: Consensus call on RADEXT WG re-charter Thread-Index: Aciqhi5ZrpchA/NpSE2H1Cme4Zp+DAAAEm6wAAA4oFA= From: "Matt Holdrege" To: "Glen Zorn" , "Stefan Winter" , "Bernard Aboba" Cc: ... >> one suggested correction: over the course of the discussion, >> it seemed that splitting TCP transport into an own document >> was deemed worthwhile. >>=20 >> Such a document should be added to the milestones. Since the >> document probably makes use of Status-Server, and the TCP+TLS >> work in turn uses the TCP transport document, it should have >> an intermediate place in the timeline.=20 >I agree. Me 2. -Matt -- 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, 30 Apr 2008 05:56:57 +0000 From: "Glen Zorn" To: "'Stefan Winter'" , "'Bernard Aboba'" Cc: Subject: RE: Summary: Consensus call on RADEXT WG re-charter Date: Wed, 30 Apr 2008 12:54:41 +0700 Message-ID: <001801c8aa86$c181ada0$86e5787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Aciqhi5ZrpchA/NpSE2H1Cme4Zp+DAAAEm6w ... > one suggested correction: over the course of the discussion, > it seemed that splitting TCP transport into an own document > was deemed worthwhile. > > Such a document should be added to the milestones. Since the > document probably makes use of Status-Server, and the TCP+TLS > work in turn uses the TCP transport document, it should have > an intermediate place in the timeline. I agree. ... -- 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, 30 Apr 2008 05:48:00 +0000 Message-ID: <481807A6.8030907@restena.lu> Date: Wed, 30 Apr 2008 07:46:14 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Summary: Consensus call on RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, one suggested correction: over the course of the discussion, it seemed that splitting TCP transport into an own document was deemed worthwhile. Such a document should be added to the milestones. Since the document probably makes use of Status-Server, and the TCP+TLS work in turn uses the TCP transport document, it should have an intermediate place in the timeline. Like Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 Non-UDP Transport Considerations I-D submitted as Proposed Standard(?) RFC Apr 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIGAem+jm90f8eFWYRAj/cAJ4kNB2JNz9Z/A4ufpc/GOaW3kgIJACcDPwc uj+tmcB6Eminto3/2sjhDyw= =Xg8K -----END PGP SIGNATURE----- -- 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, 30 Apr 2008 04:36:06 +0000 Date: Wed, 30 Apr 2008 00:31:25 -0400 To: From: David Mitton Subject: Re: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: On 4/20/2008 06:55 PM, Bernard_Aboba@hotmail.com wrote: >At IETF 71, we discussed adopting the document "Crypto-Agility >Requirements for Remote Dial-In User Service (RADIUS)" >as a RADEXT WG work item. In the room, the vote was 11-0 in favor of this. > >We are now following up with a mailing list consensus call. The >document is available for inspection here: >http://www.ietf.org/internet-drafts/draft-nelson-radext-crypto-agility-requirements-00.txt > >Please post to the mailing list providing your opinion on whether >this document should be adopted as a working group work item. > >The Consensus call will last until May 6, 2008. I am in favor of this. Dave. -- 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, 29 Apr 2008 22:05:12 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_88dae544-de2c-4ba5-a148-7904557bd8ca_" From: Bernard Aboba To: Subject: Summary: Consensus call on RADEXT WG re-charter Date: Tue, 29 Apr 2008 15:03:19 -0700 MIME-Version: 1.0 --_88dae544-de2c-4ba5-a148-7904557bd8ca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The consensus call on the RADEXT WG re-charter ended on April 28. After go= ing over the RADEXT WG mailing list discussion, I believe that WG consensu= s was achieved on the=20 proposed charter, modified to take into account the proposed change to the= =20 backwards compatibility language proposed by Glen Zorn: =20 "- All documents produced MUST specify means of interoperation withlegacy R= ADIUS implementations and, if possible, be backward compatible with existin= g RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,= 4675, 5080, 5090 and 5176." =20 Here is my summary of the opinions expressed on the list: In favor (6)Alan DeKok: http://ops.ietf.org/lists/radiusext/2008/msg00221.= htmlStefan Winter: http://ops.ietf.org/lists/radiusext/2008/msg00232.htmlMa= uricio Sanchez: http://ops.ietf.org/lists/radiusext/2008/msg00248.htmlMudit= Goel: http://ops.ietf.org/lists/radiusext/2008/msg00258.htmlMike McCauley:= http://ops.ietf.org/lists/radiusext/2008/msg00234.htmlSteve Hanna: http://= ops.ietf.org/lists/radiusext/2008/msg00206.html No explicit opinion express= ed: (2)Avi Lior: http://ops.ietf.org/lists/radiusext/2008/msg00268.htmlMatt= Holdredge: http://ops.ietf.org/lists/radiusext/2008/msg00240.htmlAgainst (= 2):Glen Zorn (many postings)Joe Salowey: http://ops.ietf.org/lists/radiusex= t/2008/msg00211.html The full text of the modified charter is enclosed bel= ow:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to theRADIUS p= rotocol required to define extensions to the standardattribute space as wel= l as to address cryptographic algorithmagility and use over new secure tran= sports. In addition, RADEXT willwork on RADIUS Design Guidelines and define= new attributes for particular applications of authentication, authorizatio= n and accounting such as NAS management and local area network (LAN) usage.= In order to enable interoperation of heterogeneous RADIUS/Diameterdeployme= nts, all RADEXT WG work items MUST contain a Diametercompatibility section,= outlining how interoperability withDiameter will be maintained.Furthermore= , to ensure backward compatibility with existing RADIUSimplementations, as = well as compatibility between RADIUS and Diameter,the following restriction= s are imposed on extensions considered by theRADEXT WG: =20 - All documents produced MUST specify means of interoperation withlegacy RA= DIUS implementations and, if possible, be backward compatible with existing= RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4= 675, 5080, 5090 and 5176.- All RADIUS work MUST be compatible with equivale= nt facilities inDiameter. Where possible, new attributes should be defined = so thatthe same attribute can be used in both RADIUS and Diameter withouttr= anslation. In other cases a translation considerationssection should be inc= luded in the specification. Work ItemsThe immediate goals of the RADEXT wor= king group are to address thefollowing issues:- RADIUS design guidelines. T= his document will provide guidelines fordesign of RADIUS attributes. It wil= l specifically consider howcomplex data types may be introduced in a robust= manner, maintainingbackwards compatibility with existing RADIUS RFCs, acro= ss all theclasses of attributes: Standard, Vendor-Specific and SDO-Specific= .In addition, it will review RADIUS data types and associatedbackwards comp= atibility issues. - RADIUS Management authorization. This document will def= ine theuse of RADIUS for NAS management over IP. -RADIUS attribute space ex= tension. The standard RADIUS attributespace is currently being depleted. Th= is document will provideadditional standard attribute space, while maintain= ing backwardcompatibility with existing attributes.-RADIUS Cryptographic Al= gorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet= integrity and authentication as wellas attribute confidentiality. Given th= e increasingly successfulattacks being mounted against MD5, the ability to = supportalternative algorithms is required. This work item willinclude docum= entation of RADIUS crypto-agility requirements,as well as development of on= e or more Experimental RFCs providingsupport for negotiation of alternative= cryptographic algorithmsto protect RADIUS.- IEEE 802 attributes. New attri= butes have been proposed tosupport IEEE 802 standards for wired and wireles= s LANs. Thiswork item will support authentication, authorization andaccount= ing attributes needed by IEEE 802 groups includingIEEE 802.1, IEEE 802.11 a= nd IEEE 802.16.- New RADIUS transports. New secure transports for RADIUS wi= llbe developed, including TCP/TLS (RADSEC) and UDP/DTLS.- Documentation of = Status-Server usage. A documentdescribing usage of the Status-Server facili= ty will bedeveloped.Goals and Milestones:Jun 2008 RADIUS Design Guidelines = submitted as a Best Current Practice RFCJun 2008 RADIUS Management Authoriz= ation I-D submitted as a Proposed Standard RFCSep 2008 RADIUS Crypto-agilit= y Requirements submitted as an Informational RFCSep 2008 Extended Attribute= s I-D submitted as a Proposed Standard RFCDec 2008 IEEE 802 Attributes I-D = submitted as a Proposed Standard RFCMar 2009 Status-Server I-D submitted as= a Proposed Standard RFCMar 2009 RADSEC (RADIUS over TCP/TLS) draft submitt= ed as an Experimental RFCJune 2009 RADIUS over DTLS I-D submitted as an Exp= erimental RFCJune 2009 RADIUS Cryptographic Algorithm Agility I-D submitted= as an Experimental RFC --_88dae544-de2c-4ba5-a148-7904557bd8ca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The consensus call on the RADEXT WG re-charter ended on April 28.  Aft= er going over the
RADEXT WG mailing list discussion,  I believe th= at WG consensus was achieved on the
proposed charter, modified to take into account the proposed change to the =
backwards compatibility language proposed by Glen Zorn:
 
"- All documents produced MUST specify means of interoperation with
lega= cy RADIUS implementations and, if possible, be backward
compatible with= existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, 3580= , 4668-4673,4675, 5080, 5090 and 5176."
 
Here is my summary of the opinions expressed on the list:
 
In favor (6)
Alan DeKok: http://ops.ietf.org/lists/rad= iusext/2008/msg00221.html
Stefan Winter: http://ops.ietf.org= /lists/radiusext/2008/msg00232.html
Mauricio Sanchez: http:/= /ops.ietf.org/lists/radiusext/2008/msg00248.html
Mudit Goel: http://ops.ietf.org/lists/radiusext/2008/msg00258.html
Mike McCaule= y: http://ops.ietf.org/lists/radiusext/2008/msg00234.html
St= eve Hanna: http://ops.ietf.org/lists/radiusext/2008/msg00206.html
 
No explicit opinion expressed: (2)
Avi Lior: htt= p://ops.ietf.org/lists/radiusext/2008/msg00268.html
Matt Holdredge: = http://ops.ietf.org/lists/radiusext/2008/msg00240.html
Against (2):
Glen Zorn (many postings)
Joe Salowey: http://o= ps.ietf.org/lists/radiusext/2008/msg00211.html
  
The f= ull text of the modified charter is enclosed below:
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to th= e
RADIUS protocol required to define extensions to the standard
attri= bute space as well as to address cryptographic algorithm
agility and use= over new secure transports. In addition, RADEXT will
work on RADIUS Des= ign Guidelines and define new attributes for
particular applications of= authentication, authorization and
accounting such as NAS management an= d local area network (LAN) usage.

In order to enable interoperation= of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items = MUST contain a Diameter
compatibility section, outlining how interoperab= ility with
Diameter will be maintained.

Furthermore, to ensure ba= ckward compatibility with existing RADIUS
implementations, as well as co= mpatibility between RADIUS and Diameter,
the following restrictions are = imposed on extensions considered by the
RADEXT WG:
 
- All documents produced MUST specify means of interoperation with
= legacy RADIUS implementations and, if possible, be backward
compatible = with existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, = 3580, 4668-4673,4675, 5080, 5090 and 5176.

- All RADIUS work MUST be= compatible with equivalent facilities in
Diameter. Where possible, new = attributes should be defined so that
the same attribute can be used in b= oth RADIUS and Diameter without
translation. In other cases a translatio= n considerations
section should be included in the specification.
&nb= sp;
Work Items

The immediate goals of the RADEXT working group ar= e to address the
following issues:

- RADIUS design guidelines. Th= is document will provide guidelines for
design of RADIUS attributes. It = will specifically consider how
complex data types may be introduced in a= robust manner, maintaining
backwards compatibility with existing RADIUS= RFCs, across all the
classes of attributes: Standard, Vendor-Specific a= nd SDO-Specific.
In addition, it will review RADIUS data types and assoc= iated
backwards compatibility issues.
 
- RADIUS Management a= uthorization. This document will define the
use of RADIUS for NAS manage= ment over IP.

-RADIUS attribute space extension. The standard RADIU= S attribute
space is currently being depleted. This document will provid= e
additional standard attribute space, while maintaining backward
com= patibility with existing attributes.

-RADIUS Cryptographic Algorithm= Agility. RADIUS has traditionally
relied on MD5 for both per-packet in= tegrity and authentication as well
as attribute confidentiality. Given t= he increasingly successful
attacks being mounted against MD5, the abilit= y to support
alternative algorithms is required. This work item will
= include documentation of RADIUS crypto-agility requirements,
as well as = development of one or more Experimental RFCs providing
support for negot= iation of alternative cryptographic algorithms
to protect RADIUS.
- IEEE 802 attributes. New attributes have been proposed to
support IEE= E 802 standards for wired and wireless LANs. This
work item will support= authentication, authorization and
accounting attributes needed by IEEE = 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- N= ew RADIUS transports. New secure transports for RADIUS will
be deve= loped, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of S= tatus-Server usage. A document
describing usage of the Status-Server fac= ility will be
developed.

Goals and Milestones:
Jun 2008 RADIUS= Design Guidelines submitted as a Best Current Practice RFC
Jun 2008 RAD= IUS Management Authorization I-D submitted as a Proposed Standard RFC
Se= p 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC=
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFCDec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
= Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009= RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
Jun= e 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 R= ADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC<= /SPAN>
= --_88dae544-de2c-4ba5-a148-7904557bd8ca_-- -- 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, 29 Apr 2008 18:30:41 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_7a880b00-be76-4478-8b33-e2f67dee70b0_" From: Bernard Aboba To: CC: , Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr Date: Tue, 29 Apr 2008 11:25:56 -0700 MIME-Version: 1.0 --_7a880b00-be76-4478-8b33-e2f67dee70b0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > >I'm quite aware of that & if, in fact, the attributes were opaque> data = that passage would certainly cover it. However, it doesn't> appear that eit= her the Location-Information nor the Location-Data> Attribute is actually "= opaque"..... >> Strictly speaking, since the attribute contents are framed by field> del= imiters defined only in the attribute definition, and not in another> proto= col document, these attributes don't meet the definition of "opaque" as> cu= rrently used in the RADIUS Design Guidelines. =20 I think the key question here is whether a RADIUS server would need to=20 explicitly parse these attributes in order to carry out the requirements in the document. If so, then the attributes could not be classified as "opaque", because RADIUS server code would need to change. =20 > > o If the RADIUS server requires location information for computing> > t= he authorization decision and the RADIUS client does not provide> > it with= the Access-Request message then the Requested-Location-> > Info Attribute = is attached to the Access-Challenge with a hint> > about what is required. = Two cases can be differentiated: =20 The question is whether the RADIUS server makes this=20 determination based on the presence/absence of an attribute, or based on parsing its contents. If it's the latter, then the data can't be classified as "opaque".=20 > > 1. If the RADIUS client sends the requested information then the> > RAD= IUS server can process the location-based attributes. =20 For the RADIUS server to determine whether the client sent the=20 set of location information that was requested previously=20 (as opposed to just whether the client send an attribute that may or may not correspond to what was requested), it would seem=20 that parsing would be required. > > 2. If the RADIUS server does not receive the requested> > information i= n response to the Access-Challenge (including the> > Requested-Location-Inf= o Attribute) then the RADIUS server may> > respond with an Access-Reject me= ssage with an Error-Cause> > Attribute (including the "Location-Info-Requir= ed" value).> > > > The RADIUS server "requires location information for com= puting the> > authorization decision". How can it make a decision based upo= n data> > that it cannot understand? =20 If the RADIUS server can make the determination purely based on the presence/absence of the attribute, then it wouldn't need to understand the contents. However, if parsing is required (which seems to be implied by the term "requested information"), then I'd agree that the attribute is not really "opaque".=20 > > AFAICT, the only way that the RADIUS server can tell if it has > > actu= ally received the information it requested is to examine the> > Code and En= tity sub-fields of the returned Location-Information > > Attribute and chec= k that there is an associated instance of the > > Location-Data Attribute b= y matching the Index fields of the Attributes.>=20 If the goal is to determine exactly what kind of information was sent, and whether the requirements were met (as opposed to just determining if an attribute was present or not), then I'd agree.=20 =20 > > Neither the Location-Information nor the Location-Data Attributes seem>= > to be used for authentication (authorization !=3D authentication) or> > = security.=20 Yup. An exception can't be granted based on that criteria. > > WRT the Index fields of the Location-Information and Location-Data> > = Attributes, the fact that they are both mandatory and large avoids many> > = of the drawbacks mentioned WRT tags in the Design Guidelines document,> > n= evertheless that document does state 'new attributes SHOULD use the> > grou= ping method described in http://www.ietf.org/internet-drafts/draft-> > ietf= -radext-extended-attributes-03.txt'. =20 The question here is whether the Index field is actually related to groupin= g or not. = --_7a880b00-be76-4478-8b33-e2f67dee70b0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > >I'm quite aware of that & if, in fact, the attributes were opa= que
> data that passage would certainly cover it. However, it doesn't=
> appear that either the Location-Information nor the Location-Data<= BR>> Attribute is actually "opaque".....
>
> Strictly speaking, since the attribute contents are framed by = field
> delimiters defined only in the attribute definition, and not = in another
> protocol document, these attributes don't meet the defin= ition of "opaque" as
> currently used in the RADIUS Design Guidelines= .
 
I think the key question here is whether a RADIUS server would need to
explicitly parse these attributes in order to carry out the requirements in=
the document.  If so, then the attributes could not be classified as "opaque", because RADIUS server code would need to change. 

> > o If the RADIUS server requires location information for comp= uting
> > the authorization decision and the RADIUS client does no= t provide
> > it with the Access-Request message then the Requeste= d-Location-
> > Info Attribute is attached to the Access-Challenge= with a hint
> > about what is required. Two cases can be differen= tiated:
 
The question is whether the RADIUS server makes this
determination based on the presence/absence of an attribute, or
based on parsing its contents.  If it's the latter, then the data= can't
be classified as "opaque".

> > 1. If the RADIUS client sends the requested information then = the
> > RADIUS server can process the location-based attributes.  
For the RADIUS server to determine whether the client sent the
set of location information that was requested previously
(as opposed to just whether the client send an attribute that may
or may not correspond to what was requested), it would seem
that parsing would be required.

> > 2. If the RADIUS server does not receive the requested
>= ; > information in response to the Access-Challenge (including the
&g= t; > Requested-Location-Info Attribute) then the RADIUS server may
&g= t; > respond with an Access-Reject message with an Error-Cause
> &= gt; Attribute (including the "Location-Info-Required" value).
> > =
> > The RADIUS server "requires location information for computin= g the
> > authorization decision". How can it make a decision base= d upon data
> > that it cannot understand?
 
If the RADIUS server can make the determination purely based on the
presence/absence of the attribute, then it wouldn't need to understand
the contents.  However, if parsing is required (which seems to be impl= ied
by the term "requested information"), then I'd agree that the attribute
is not really "opaque".

> > AFAICT, the only way that the RADIUS server can tell if it ha= s
> > actually received the information it requested is to examin= e the
> > Code and Entity sub-fields of the returned Location-Info= rmation
> > Attribute and check that there is an associated insta= nce of the
> > Location-Data Attribute by matching the Index fiel= ds of the Attributes.
>

If the goal is to determine exactly what kind of information was sent, and<= BR> whether the requirements were met (as opposed to just determining if
an attribute was present or not), then I'd agree.
 
> > Neither the Location-Information nor the Location-Data Attributes= seem
> > to be used for authentication (authorization !=3D authen= tication) or
> > security.

Yup.  An exception can't be granted based on that criteria.
 
> > WRT the Index fields of the Location-Information and Lo= cation-Data
> > Attributes, the fact that they are both mandatory = and large avoids many
> > of the drawbacks mentioned WRT tags in t= he Design Guidelines document,
> > nevertheless that document does= state 'new attributes SHOULD use the
> > grouping method describe= d in http://www.ietf.org/internet-drafts/draft-
> > ietf-radext-ex= tended-attributes-03.txt'.
 
The question here is whether the Index field is actually related to groupin= g
or not. 
= --_7a880b00-be76-4478-8b33-e2f67dee70b0_-- -- 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, 29 Apr 2008 17:47:15 +0000 From: "David B. Nelson" To: Cc: , Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr Date: Tue, 29 Apr 2008 13:45:21 -0400 Organization: Elbrys Networks, Inc. Message-ID: <01dc01c8aa20$cbdc31a0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcipUnEZvxg2xJNKQf6kQqsb361hXgAfn0JQABKeVeA= Glen Zorn writes... > I'm quite aware of that & if, in fact, the attributes were opaque > data that passage would certainly cover it. However, it doesn't > appear that either the Location-Information nor the Location-Data > Attribute is actually "opaque". I've offered similar comments early on in the review of this document. The authors explained to me that the attributes used in this document are based upon the PDUs of other protocols. Unfortunately, the PDUs of those other protocols are not suitable for direct encapsulation as "opaque" RADIUS Attributes. Instead, they required slight modifications in order to be suitable for the current purpose. For that reason, the document under review outlines the format and layout of the attributes as if they were not opaque. In fact, they are only partially opaque. Strictly speaking, for a RADIUS Attribute to be "opaque" in the way that the RADIUS Design Guidelines anticipates, it should be merely an encapsulation of a data element defined in another (typically non-RADIUS) document. What we have here is as example of re-use (with minor adaptation) rather than simple encapsulation. I think this fails to meet the spirit, if not the letter, of the RADIUS Design Guidelines. However, after substantial discussion on this point, it became clear that there were no better alternatives that met the needs of the authors of this document. This may be as good as its going to get. > OK. As you noted above, the Design Guidelines say > > If the RADIUS Server simply passes the contents of an attribute to > some non-RADIUS portion of the network, then the data is opaque, and > SHOULD be defined to be of type String. A concrete way of judging > this requirement is whether or not the attribute definition in the > RADIUS document contains delineated fields for sub-parts of the data. > If those fields need to be delineated in RADIUS, then the data is not > opaque, and it SHOULD be separated into individual RADIUS attributes. Strictly speaking, since the attribute contents are framed by field delimiters defined only in the attribute definition, and not in another protocol document, these attributes don't meet the definition of "opaque" as currently used in the RADIUS Design Guidelines. > But section 4.7 of the draft under review says > > o If the RADIUS server requires location information for computing > the authorization decision and the RADIUS client does not provide > it with the Access-Request message then the Requested-Location- > Info Attribute is attached to the Access-Challenge with a hint > about what is required. Two cases can be differentiated: > > 1. If the RADIUS client sends the requested information then the > RADIUS server can process the location-based attributes. > > 2. If the RADIUS server does not receive the requested > information in response to the Access-Challenge (including the > Requested-Location-Info Attribute) then the RADIUS server may > respond with an Access-Reject message with an Error-Cause > Attribute (including the "Location-Info-Required" value). > > The RADIUS server "requires location information for computing the > authorization decision". How can it make a decision based upon data > that it cannot understand? This is where the delineation gets fuzzy. We presume that any information carried in RADIUS messages is related to authentication or authorization. Yes, RADIUS can be (ab)used as a generic transport or all sorts of unrelated information, but that isn't the case in this instance. The use of a "back-end" or "plug-in" module to parse opaque data in a RADIUS Attribute and provide the results back to the RADIUS Server for use in the authentication and authorization decision making process is well established. Certainly that's what the EAP server does for RADIUS EAP-Message Attributes. > Of course, "process" can mean many things and if these attributes are > opaque then "process" might mean just writing the data to a file or > forwarding it over some unspecified interface to another entity. It could mean that. > AFAICT, the only way that the RADIUS server can tell if it has > actually received the information it requested is to examine the > Code and Entity sub-fields of the returned Location-Information > Attribute and check that there is an associated instance of the > Location-Data Attribute by matching the Index fields of the Attributes. Something has to do this work. It could be the RADIUS Server, or it could be the Location Policy Server, acting as a back-end service to the RADIUS Server. This is all a matter of implementation, and has nothing to do with the on-the-wire protocol. > Remember that this check for the requested information takes place > before the RADIUS server processes the data; this suggests to me that > these fields "need to be delineated in RADIUS" and therefore > "the data is not opaque, and it SHOULD be separated into individual > RADIUS attributes". I think that is a very reasonable design choice, and one that would be in compliance with the RADIUS Design Guidelines. However, we've had that discussion and the consensus seemed to be that it was too much of a change, too late in the development cycle for this document. > Further, section A.2.2 of the Design Guidelines > asks the (how I wish it was a musical ;-) question: > > Does the attribute define a complex data type for purposes other than > authentication or security? If so, this data type SHOULD be replaced > with simpler types, as discussed above in Section A.2.1. > > Neither the Location-Information nor the Location-Data Attributes seem > to be used for authentication (authorization != authentication) or > security. Yes, but I believe that this section of text was arrived at after the document under review had completed its WGLC. There is an issue of timing here. If the RADIUS Design Guidelines document had matured more quickly, it may have had a greater impact on the RADIUS Location Attributes document. I had argued along similar lines, but there was resistance to change late on in the development cycle. > Section A.1.3 of the same document says (WRT Attributes > encapsulating complex data types): > > Does the attribute encapsulate an existing data structure defined > outside of the RADIUS specifications? Can the attribute be treated > as opaque data by RADIUS servers (including proxies?) If both > questions can be answered affirmatively, a complex structure MAY be > used in a RADIUS specification. > > The specification of the attribute SHOULD define the encapsulating > attribute to be of type String. The specification SHOULD refer to an > external document defining the structure. The specification SHOULD > NOT define or describe the structure[...] > > However, section 4.2 of draft-ietf-geopriv-radius-lo describes the > structure of the Location-Information Attribute in detail; the question > of opacity was dealt with above. > > WRT the Index fields of the Location-Information and Location-Data > Attributes, the fact that they are both mandatory and large avoids many > of the drawbacks mentioned WRT tags in the Design Guidelines document, > nevertheless that document does state 'new attributes SHOULD use the > grouping method described in http://www.ietf.org/internet-drafts/draft- > ietf-radext-extended-attributes-03.txt'. Yes, if this work were to be started today, one would expect a much greater level of compliance with the RADIUS Design Guidelines 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: Tue, 29 Apr 2008 16:19:48 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: , "Glen Zorn" , , Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr Date: Tue, 29 Apr 2008 23:16:18 +0700 Message-ID: <002401c8aa14$79b3e640$3d01f00a@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcipUnEZvxg2xJNKQf6kQqsb361hXgAfn0JQ owner-radiusext@ops.ietf.org <> scribbled on Tuesday, April 29, 2008 12:02 AM: >> Last but not least, this draft fairly universally violates several >> of the guidelines given in >> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, >> in particular those regarding the use of tags to associate different >> attributes (called "Index" in this document) and the creation of >> "complex" attributes. > > The issue of "complex attributes" was extensively discussed on > the RADEXT WG mailing list, and the Design Guidelines are > based on the WG consensus that was derived from the review > of this document. > > In particular, Section 2.1.3 of the Design Guidelines document > specifically calls out the distinction between complex > attributes which are interpreted by RADIUS, as opposed to > "opaque data" which is treated as a string by RADIUS, and > interpreted out of band: > > > The only other exception to the recommendation against complex types > is for types that can be treated as opaque data by the > RADIUS server. > For example, the EAP-Message attribute, defined in [RFC3579] Section > 3.1 contains a complex data type that is an EAP packet. Since these > complex types do not need to be parsed by the RADIUS server, the > issues arising from policy language limitations do not arise. > Similarly, since attributes of these complex types can be configured > on the server using a data type of String, dictionary > limitations are > also not encountered. Section A.1 below includes a series of > checklists that may be used to analyze a design for RECOMMENDED and > NOT RECOMMENDED behavior in relation to complex types. > > If the RADIUS Server simply passes the contents of an attribute to > some non-RADIUS portion of the network, then the data is opaque, and > SHOULD be defined to be of type String. A concrete way of judging > this requirement is whether or not the attribute definition in the > RADIUS document contains delineated fields for sub-parts of > the data. > If those fields need to be delineated in RADIUS, then the > data is not > opaque, and it SHOULD be separated into individual RADIUS > attributes. I'm quite aware of that & if, in fact, the attributes were opaque data that passage would certainly cover it. However, it doesn't appear that either the Location-Information nor the Location-Data Attribute is actually "opaque". > >> I realize that the RADIUS design guidelines document is just an >> Internet-Draft, but it is a radext WG document & has been under >> construction for some period of time. > > The Design Guidelines document text was specifically crafted > based on this particular draft, based on extensive discussion > within the RADEXT WG. > >> More important than >> the standardization status of the document is the question of whether >> the guidelines make sense; > > The Design Guidelines document has completed RADEXT WG last > call with only minor comments outstanding. If you had any > concerns about whether the document "makes sense" you should > have raised them long ago -- but you did not. I wasn't referring to myself: I've reviewed that document several times and have yet to find anything to complain about ;-). I do not, however, pretend to know the opinions of your co-authors or even your own, for that matter: AFAIK, it's not mandatory for a WG Chair to like all of the WG documents, just to ensure that they reflect WG consensus. > >> if so, then it may not be such a good idea to so completely ignore >> them; > > Far from ignoring the Design Guidelines, this document has > actually been one of the primary motivations for creating them > -- and the text in Design Guidelines has been specifically > crafted to deal with this particular case. > >> If not, then maybe radext should rethink this work item (especially >> since a co-chair of that WG is also a co-author of the document >> under review). > > Given the extensive discussion on the RADEXT WG list relating > to this document and Design Guidelines, I have personally > spent quite a bit of time with Hannes, Avi and others working > on improving the compatibility of this document with the > Design Guidelines. > I did not ask to be named as an author -- the other authors > suggested this to me. I don't think that I suggested that you had -- in fact I noted the (perhaps over ;-) enthusiastic appreciation of your efforts by your co-authors in my first message. > > Given that, I have no particular interest in this document, > other than ensuring that it does as little violence to the > RADIUS protocol as possible. > > So if you have particular concerns relating to the handling of > this document, I don't think suggested that, either... > or can provide specific instances in which this > document violates "Design Guidelines" (applying the tests in > Appendix A, for example), please put them on the table. OK. As you noted above, the Design Guidelines say If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque, and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque, and it SHOULD be separated into individual RADIUS attributes. But section 4.7 of the draft under review says o If the RADIUS server requires location information for computing the authorization decision and the RADIUS client does not provide it with the Access-Request message then the Requested-Location- Info Attribute is attached to the Access-Challenge with a hint about what is required. Two cases can be differentiated: 1. If the RADIUS client sends the requested information then the RADIUS server can process the location-based attributes. 2. If the RADIUS server does not receive the requested information in response to the Access-Challenge (including the Requested-Location-Info Attribute) then the RADIUS server may respond with an Access-Reject message with an Error-Cause Attribute (including the "Location-Info-Required" value). The RADIUS server "requires location information for computing the authorization decision". How can it make a decision based upon data that it cannot understand? It doesn't have to because "[i]f the RADIUS client sends the requested information then the RADIUS server can process the location-based attributes". Of course, "process" can mean many things and if these attributes are opaque then "process" might mean just writing the data to a file or forwarding it over some unspecified interface to another entity. So maybe the RADIUS server is making the decision based just upon the fact that it received a Location-Information/Location-Data pair in the new Access-Request (along with the echoed Attributes). The problem is that the RADIUS server didn't request just any old location data; it requested a very specific set of data (in the example later in section 4.7 it is the civic location of the user). AFAICT, the only way that the RADIUS server can tell if it has actually received the information it requested is to examine the Code and Entity sub-fields of the returned Location-Information Attribute and check that there is an associated instance of the Location-Data Attribute by matching the Index fields of the Attributes. Remember that this check for the requested information takes place before the RADIUS server processes the data; this suggests to me that these fields "need to be delineated in RADIUS" and therefore "the data is not opaque, and it SHOULD be separated into individual RADIUS attributes". Further, section A.2.2 of the Design Guidelines asks the (how I wish it was a musical ;-) question: Does the attribute define a complex data type for purposes other than authentication or security? If so, this data type SHOULD be replaced with simpler types, as discussed above in Section A.2.1. Neither the Location-Information nor the Location-Data Attributes seem to be used for authentication (authorization != authentication) or security. Section A.1.3 of the same document says (WRT Attributes encapsulating complex data types): Does the attribute encapsulate an existing data structure defined outside of the RADIUS specifications? Can the attribute be treated as opaque data by RADIUS servers (including proxies?) If both questions can be answered affirmatively, a complex structure MAY be used in a RADIUS specification. The specification of the attribute SHOULD define the encapsulating attribute to be of type String. The specification SHOULD refer to an external document defining the structure. The specification SHOULD NOT define or describe the structure[...] However, section 4.2 of draft-ietf-geopriv-radius-lo describes the structure of the Location-Information Attribute in detail; the question of opacity was dealt with above. WRT the Index fields of the Location-Information and Location-Data Attributes, the fact that they are both mandatory and large avoids many of the drawbacks mentioned WRT tags in the Design Guidelines document, nevertheless that document does state 'new attributes SHOULD use the grouping method described in http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute s-03.txt'. -- 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, 29 Apr 2008 09:18:04 +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: AW: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item Date: Tue, 29 Apr 2008 10:38:26 +0200 Message-Id: <75404C7727619C4E81A6DABE442E42DD038C6593@S4DE9JSAANL.ost.t-com.de> Thread-Topic: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item Thread-Index: Acip04/A6F3dFULeQ5euo8UoaZ3eNgAAJscg From: Steigerwaldw To: Bernard_Aboba@hotmail.com wrote: > Please post to the mailing list providing your opinion on whether this = > document should be adopted as a working group work item. I think we should adopt it. regards=20 Wolfgang T-Systems Enterprise Services GmbH Systems Integration BU Telko Wolfgang Steigerwald Goslarer Ufer 35, 10589 Berlin +49 30 3497 2058 +49 69 66531-111 (Fax) +49 171 5664350 (Mobil) E-Mail: wolfgang.steigerwald@t-systems.com Internet: http://www.t-systems.de T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, = Albert Henn, Olaf Heyden*, Katrin Horstmann, Joachim Langmack*, Wilfried = Peters*,=20 Dr. Stefan Schloter, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you. T-Systems - Business flexibility=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: Tue, 29 Apr 2008 08:31:47 +0000 Message-ID: <4816D596.6010409@nitros9.org> Date: Tue, 29 Apr 2008 10:00:22 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard_Aboba@hotmail.com wrote: > Please post to the mailing list providing your opinion on whether this > document should be adopted as a working group work item. I am in favor of accepting this document as a WG item. 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: Mon, 28 Apr 2008 17:03:31 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_d48458f5-4d82-421c-b77e-a9e6d2d8287b_" From: Bernard Aboba To: Glen Zorn , CC: Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr Date: Mon, 28 Apr 2008 10:01:50 -0700 MIME-Version: 1.0 --_d48458f5-4d82-421c-b77e-a9e6d2d8287b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Last but not least, this draft fairly universally violates several of > the guidelines given in > http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, in > particular those regarding the use of tags to associate different > attributes (called "Index" in this document) and the creation of > "complex" attributes. =20 The issue of "complex attributes" was extensively discussed on=20 the RADEXT WG mailing list, and the Design Guidelines are=20 based on the WG consensus that was derived from the review=20 of this document. =20 In particular, Section 2.1.3 of the Design Guidelines document specifically calls out the distinction between complex attributes which are interpreted by RADIUS, as opposed to "opaque data" which is treated as a string by RADIUS, and interpreted out of band: The only other exception to the recommendation against complex types is for types that can be treated as opaque data by the RADIUS server. For example, the EAP-Message attribute, defined in [RFC3579] Section 3.1 contains a complex data type that is an EAP packet. Since these complex types do not need to be parsed by the RADIUS server, the issues arising from policy language limitations do not arise. Similarly, since attributes of these complex types can be configured on the server using a data type of String, dictionary limitations are also not encountered. Section A.1 below includes a series of checklists that may be used to analyze a design for RECOMMENDED and NOT RECOMMENDED behavior in relation to complex types. If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque, and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque, and it SHOULD be separated into individual RADIUS attributes. > I realize that the RADIUS design guidelines > document is just an Internet-Draft, but it is a radext WG document & has > been under construction for some period of time. =20 The Design Guidelines document text was specifically crafted based on this = particular draft, based on extensive discussion within the RADEXT WG.=20 > More important than > the standardization status of the document is the question of whether > the guidelines make sense;=20 The Design Guidelines document has completed RADEXT WG last call with only = minor comments outstanding. If you had any concerns about whether the document "= makes sense" you should have raised them long ago -- but you did not.=20 > if so, then it may not be such a good idea to so completely ignore them;= =20 Far from ignoring the Design Guidelines, this document has actually been on= e of the primary motivations for creating them -- and the text in Design Guidelines = has been specifically crafted to deal with this particular case.=20 >If not, then maybe radext should rethink this > work item (especially since a co-chair of that WG is also a co-author of > the document under review). Given the extensive discussion on the RADEXT WG list relating to this docum= ent and Design Guidelines, I have personally spent quite a bit of time with Hannes,= Avi and others working on improving the compatibility of this document with the Design Gui= delines. =20 I did not ask to be named as an author -- the other authors suggested this = to me.=20 Given that, I have no particular interest in this document, other than ensu= ring that it does as little violence to the RADIUS protocol as possible. =20 So if you have particular concerns relating to the handling of this documen= t, or can provide specific instances in which this document violates "Design Guidelin= es" (applying the tests in Appendix A, for example), please put them on the table.=20 =20 --_d48458f5-4d82-421c-b77e-a9e6d2d8287b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Last but not least, this draft fairly universally violates several of<= br>> the guidelines given in
> http://www.ietf.org/internet-drafts= /draft-ietf-radext-design-02.txt, in
> particular those regarding the= use of tags to associate different
> attributes (called "Index" in t= his document) and the creation of
> "complex" attributes.

Th= e issue of "complex attributes" was extensively discussed on
the RADEXT= WG mailing list,  and the Design Guidelines are
based on the WG c= onsensus that was derived from the review
of this document.  =

In particular, Section 2.1.3 of the Design Guidelines document spe= cifically
calls out the distinction between complex attributes which are= interpreted
by RADIUS, as opposed to "opaque data" which is treated as = a string
by RADIUS, and interpreted out of band:

   The only=
 other exception to the recommendation against complex types
   is for t=
ypes that can be treated as opaque data by the RADIUS server.
   For exa=
mple, the EAP-Message attribute, defined in [RFC3579] Section
   3.1 con=
tains a complex data type that is an EAP packet.  Since these
   complex=
 types do not need to be parsed by the RADIUS server, the
   issues aris=
ing from policy language limitations do not arise.
   Similarly, since a=
ttributes of these complex types can be configured
   on the server usin=
g a data type of String, dictionary limitations are
   also not encounte=
red.  Section A.1 below includes a series of
   checklists that may be u=
sed to analyze a design for RECOMMENDED and
   NOT RECOMMENDED behavior =
in relation to complex types.

   If the RADIUS Server simply passes =
the contents of an attribute to
   some non-RADIUS portion of the networ=
k, then the data is opaque, and
   SHOULD be defined to be of type Strin=
g.  A concrete way of judging
   this requirement is whether or not the =
attribute definition in the
   RADIUS document contains delineated field=
s for sub-parts of the data.
   If those fields need to be delineated in=
 RADIUS, then the data is not
   opaque, and it SHOULD be separated into=
 individual RADIUS attributes.

> I realize that the RADIUS design guidelines
> docume= nt is just an Internet-Draft, but it is a radext WG document & has
&= gt; been under construction for some period of time.

The Design Gu= idelines document text was specifically crafted based on this particulardraft, based on extensive discussion within the RADEXT WG.

> Mo= re important than
> the standardization status of the document is the= question of whether
> the guidelines make sense;

The Design = Guidelines document has completed RADEXT WG last call with only minor
co= mments outstanding.  If you had any concerns about whether the documen= t "makes
sense" you should have raised them long ago -- but you did not.=

> if so, then it may not be such a good idea to so completely i= gnore them;

Far from ignoring the Design Guidelines, this document = has actually been one of the
primary motivations for creating them -- an= d the text in Design Guidelines has been
specifically crafted to deal wi= th this particular case.

>If not, then maybe radext should rethi= nk this
> work item (especially since a co-chair of that WG is also a= co-author of
> the document under review).

Given the extensiv= e discussion on the RADEXT WG list relating to this document and
Design = Guidelines, I have personally spent quite a bit of time with Hannes, Avi an= d others
working on improving the compatibility of this document with th= e Design Guidelines. 
I did not ask to be named as an author -- th= e other authors suggested this to me.

Given that, I have no particu= lar interest in this document, other than ensuring that it
does as littl= e violence to the RADIUS protocol as possible. 

So if you have= particular concerns relating to the handling of this document, or can
p= rovide specific instances in which this document violates "Design Guideline= s" (applying
the tests in Appendix A, for example), please put them on t= he table.
 
= --_d48458f5-4d82-421c-b77e-a9e6d2d8287b_-- -- 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, 25 Apr 2008 17:51:36 +0000 From: "Glen Zorn" To: "'Stefan Winter'" Cc: Subject: RE: Consensus Call on RADEXT WG re-charter Date: Sat, 26 Apr 2008 00:50:27 +0700 Message-ID: <00a001c8a6fc$e0c3d900$2a01f00a@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: Acim0Os7jmA7hU+3SvOKhzYI3TSXxAAK8HIA Stefan Winter scribbled on Friday, April 25, 2008 7:36 PM: ... > > - using (D)TLS to secure the payload > > (where I would hope that DTLS and TLS have enough similarities > to warrant being put into one document. Not sure about that though.) Personally, I'd much prefer keeping these things neatly separated. ... -- 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, 25 Apr 2008 17:50:28 +0000 From: "Glen Zorn" To: "'Stefan Winter'" Cc: "'David B. Nelson'" , Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Sat, 26 Apr 2008 00:48:22 +0700 Message-ID: <009f01c8a6fc$9965bc90$2a01f00a@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: Acimzr8ewPkv1Qq0TsCzOebm1svMlQALCDRg Stefan Winter scribbled on Friday, April 25, 2008 7:20 PM: > Hi, > >> One thing that's wrong is that it ignores the limitations on the >> RADIUS PDU that exist primarily (or solely) because of the UDP >> transport. One example: the maximum length of 4096 octets for a >> Radius packet was chosen (IIRC) based upon the maximum size of a >> _UDP_ frame that could be reliably transmitted w/o fragmentation _in >> the access networks of the day_. It doesn't seem to be very smart >> to go to all the trouble of defining RADIUSoTCP while leaving this >> kind of unnecessary, UDP-specific limitation in place. > > You are perfectly right in condemning the number 4096. It was > a limitation which was pretty much arbitrary. When using TCP, > one wouldn't be forced to keep it if using the TCP transport _only_, > from end to end. > > But giving up on this limitation would completely ruin > translation back to RADIUS-as-in-2865. Which is a common use > for existing RADIUS deployments where the NAS speaks RADIUS > only. And from what I gathered in this discussion so far it is > seen as being of paramount importance that this translation works. > > I think I remember a discussion a while back about what to do > with Diameter Accepts above 4096 Bytes, and how to build a > translation agent that is able to turn this into RADIUS. IIRC, > the outcome was that it isn't possible at all, and that an > Accept which is too large has to be translated into a Reject. "Impossible" is such an interesting word, especially when applied to software ;-). It's certainly _technically_ possible to do this with a slight modification of the RADIUS protocol; what seems to be _politically_ impossible is making the slight change. > (the discussion took place when talking about NAS-Filter-Rule > and the issue "Diameter-RADIUS gateway behavior not completely > specified" in general) > > I definitely want to steer clear of this. Unfortunately, the > only way of doing so is to stay with 4096. Maybe an option > would be: if a deployment scenario can be *sure* to be free of > plain RADIUS elements everywhere, it MAY use larger payloads. That seems a bit Draconian: al that is necessary (without the minor change mentioned above) is that RadSec gateways never forward an illegal RADIUS packet to a RADIUS client or server (it's really very useful to treat the two as distinct protocols). ... -- 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, 25 Apr 2008 12:36:54 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: Consensus Call on RADEXT WG re-charter Date: Fri, 25 Apr 2008 14:35:54 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2535261.zC9x1YdXcC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804251435.58191.stefan.winter@restena.lu> --nextPart2535261.zC9x1YdXcC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Good point. On that note, it seems that RadSec (as currently specified) > creates one new option but eliminates another. Would it be worthwhile > defining RADIUS over TCP, & then how to use TLS to protect it? That sounds good to me. In some earlier offline discussions I also heard of= =20 people wanting to do RADIUS-over-SSH-TCP-port-forwarding. Not my personal=20 favourite, but still. The idea would then be to have one document about: =2D identifying parts of 2865 that are of relevance for UDP only =2D how to replace those UDP transport specifics with TCP and another document about =2D using (D)TLS to secure the payload (where I would hope that DTLS and TLS have enough similarities to warrant=20 being put into one document. Not sure about that though.) RadSec would then be the application of both in conjunction. Does that sound acceptable? 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 --nextPart2535261.zC9x1YdXcC 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) iD8DBQBIEdAu+jm90f8eFWYRAoBuAJ9LGQ01kVDFcaUBVmPk28wMc/7eIACfe88F OUTtSkXHWTirBdVkHRXTwnY= =MwTd -----END PGP SIGNATURE----- --nextPart2535261.zC9x1YdXcC-- -- 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, 25 Apr 2008 12:22:02 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" Subject: Re: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 25 Apr 2008 14:20:18 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: "'David B. Nelson'" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20173584.xWeD92MYle"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804251420.24075.stefan.winter@restena.lu> --nextPart20173584.xWeD92MYle Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > One thing that's wrong is that it ignores the limitations on the RADIUS > PDU that exist primarily (or solely) because of the UDP transport. One > example: the maximum length of 4096 octets for a Radius packet was > chosen (IIRC) based upon the maximum size of a _UDP_ frame that could be > reliably transmitted w/o fragmentation _in the access networks of the > day_. It doesn't seem to be very smart to go to all the trouble of > defining RADIUSoTCP while leaving this kind of unnecessary, UDP-specific > limitation in place. You are perfectly right in condemning the number 4096. It was a limitation= =20 which was pretty much arbitrary. When using TCP, one wouldn't be forced to= =20 keep it if using the TCP transport _only_, from end to end. But giving up on this limitation would completely ruin translation back to= =20 RADIUS-as-in-2865. Which is a common use for existing RADIUS deployments=20 where the NAS speaks RADIUS only. And from what I gathered in this discussi= on=20 so far it is seen as being of paramount importance that this translation=20 works. I think I remember a discussion a while back about what to do with Diameter= =20 Accepts above 4096 Bytes, and how to build a translation agent that is able= =20 to turn this into RADIUS. IIRC, the outcome was that it isn't possible at=20 all, and that an Accept which is too large has to be translated into a=20 Reject. (the discussion took place when talking about NAS-Filter-Rule and t= he=20 issue "Diameter-RADIUS gateway behavior not completely specified" in genera= l) I definitely want to steer clear of this. Unfortunately, the only way of do= ing=20 so is to stay with 4096. Maybe an option would be: if a deployment scenario= =20 can be *sure* to be free of plain RADIUS elements everywhere, it MAY use=20 larger payloads. But honestly, I'd prefer to keep it as simple and error-proof (as in:=20 configuration errors) as possible and forbid larger payloads outright.=20 Greetings, Stefan Winter P.S.: 4096 was the max "_in the access networks of the day_"? Anyone have a= =20 clue what that network was? Token Ring? =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 --nextPart20173584.xWeD92MYle 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) iD8DBQBIEcyI+jm90f8eFWYRAvSaAJ0WAaB9nmQLg55+Twph4BXmxZyjrwCfbtv8 Se85ymEYy8YXcp74C+3OeLU= =VaPK -----END PGP SIGNATURE----- --nextPart20173584.xWeD92MYle-- -- 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, 22 Apr 2008 05:12:26 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Tue, 22 Apr 2008 12:10:01 +0700 Message-ID: <006701c8a437$2fe73fe0$63d3797c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuAAC+dgoAAPzBRAAFdDMYAAH+3/gA== owner-radiusext@ops.ietf.org <> scribbled on Monday, April 21, 2008 9:00 PM: > Glen Zorn writes... > >> A wonderful attitude, except that the only thing the IETF produces is >> words; therefore, it behooves us to make sure that those words are >> correct. > > Yes, and I think that what is correct in this case will not be > accurately described by a well-used phrase such as "backwards > compatible" or "interoperable". I think we need spell out > exactly what we expect, in a couple of sentences. Good idea. ... -- 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, 21 Apr 2008 14:04:04 +0000 From: "David B. Nelson" To: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Mon, 21 Apr 2008 09:59:31 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00fe01c8a3b7$ec35a360$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuAAC+dgoAAPzBRAAFdDMYA= Glen Zorn writes... > A wonderful attitude, except that the only thing the IETF produces > is words; therefore, it behooves us to make sure that those words > are correct. Yes, and I think that what is correct in this case will not be accurately described by a well-used phrase such as "backwards compatible" or "interoperable". I think we need spell out exactly what we expect, in a couple of sentences. -- 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, 21 Apr 2008 01:14:45 +0000 Message-ID: From: To: Subject: Preliminary minutes of IETF 71 Date: Sun, 20 Apr 2008 18:13:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01C8A312.3C2EAD90" This is a multi-part message in MIME format. ------=_NextPart_000_0132_01C8A312.3C2EAD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable are available here: http://www.drizzle.com/~aboba/RADEXT/IETF71_RADEXT_MINUTES.txt ------=_NextPart_000_0132_01C8A312.3C2EAD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
are available here:
htt= p://www.drizzle.com/~aboba/RADEXT/IETF71_RADEXT_MINUTES.txt
------=_NextPart_000_0132_01C8A312.3C2EAD90-- -- 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, 20 Apr 2008 22:56:49 +0000 Message-ID: From: To: Subject: Consensus call: Adoption of RADIUS Crypto-Agility Requirements document as a RADEXT WG work item Date: Sun, 20 Apr 2008 15:55:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C8A2FE.EF9E48E0" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C8A2FE.EF9E48E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 71, we discussed adopting the document "Crypto-Agility = Requirements for Remote Dial-In User Service (RADIUS)"=20 as a RADEXT WG work item. In the room, the vote was 11-0 in favor of = this.=20 We are now following up with a mailing list consensus call. The = document is available for inspection here: http://www.ietf.org/internet-drafts/draft-nelson-radext-crypto-agility-re= quirements-00.txt Please post to the mailing list providing your opinion on whether this = document should be adopted as a working group work item.=20 The Consensus call will last until May 6, 2008. ------=_NextPart_000_0013_01C8A2FE.EF9E48E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 71, we discussed adopting the = document=20 "Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)"=20
as a RADEXT WG work item.  In the = room, the vote was 11-0 in favor of this. =
 
We are now following up with a mailing = list=20 consensus call.  The document is available for inspection=20 here:
http://www.ietf.org/internet-drafts/draft-nels= on-radext-crypto-agility-requirements-00.txt
 
Please post to the mailing list = providing your=20 opinion on whether this document = should be=20 adopted as a working group work item. 
 
The Consensus call will = last until May 6,=20 2008.
------=_NextPart_000_0013_01C8A2FE.EF9E48E0-- -- 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, 19 Apr 2008 20:22:04 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Sun, 20 Apr 2008 03:20:07 +0700 Message-ID: <00a501c8a25a$cb4e1eb0$65e4787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuAAC+dgoAAPzBRA owner-radiusext@ops.ietf.org <> scribbled on Saturday, April 19, 2008 7:47 PM: > Glen Zorn writes... > >> The first thing to be addressed is the (bogus) usage of the term >> "backward compatibility" in the proposed charter. PLEASE replace it >> with "interoperable" or a synonym thereof. > > With all due respect, this seems to me like another "name game" issue. > Let's worry more about what we want the properties to be, and > less about what we call it A wonderful attitude, except that the only thing the IETF produces is words; therefore, it behooves us to make sure that those words are correct. It's not a game (or if it is, it's the only one in (our) town). > > > > -- > 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: Sat, 19 Apr 2008 12:48:14 +0000 From: "David B. Nelson" To: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Sat, 19 Apr 2008 08:46:43 -0400 Message-ID: <00f901c8a21b$6cf79240$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuAAC+dgoA== Glen Zorn writes... > The first thing to be addressed is the (bogus) usage of the term > "backward compatibility" in the proposed charter. PLEASE replace it > with "interoperable" or a synonym thereof. With all due respect, this seems to me like another "name game" issue. Let's worry more about what we want the properties to be, and less about what we call it -- 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, 19 Apr 2008 07:18:12 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Sat, 19 Apr 2008 14:16:12 +0700 Message-ID: <006601c8a1ed$48962660$65e4787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtgACHqyuA= owner-radiusext@ops.ietf.org <> scribbled on Friday, April 18, 2008 10:01 PM: > Glen Zorn writes... > >> One example: the maximum length of 4096 octets for a Radius packet >> was chosen (IIRC) based upon the maximum size of a _UDP_ frame that >> could be reliably transmitted w/o fragmentation _in the access >> networks of the day_. > > I've forgotten that discussion. Isn't 4096 the maximum size > *any* UDP frame, IP fragmentation and reassembly notwithstanding? No. The Length field in the UDP header is 16 bits long; RFC 768 notes that the minimum length is 8 octets but doesn't mention any maximum. > >> It doesn't seem to be very smart to go to all the trouble of defining >> RADIUSoTCP while leaving this kind of unnecessary, UDP-specific >> limitation in place. > > I recall that you have many times advocated the need for > longer RADIUS packets and/or more/longer RADIUS attributes. This isn't my personal opinion: I have just been echoing customer requests. > > It is true that any RADSEC to RADIUS gateway needs to address > what is to be done about larger than UDP-size RADSEC messages > in translating them to RADIUS messages. > > I need to see if that issue is covered in the "AAA Transports" RFC... > > I believe that addressing this issue ought to be another > element of our definition of backwards compatibility for > RADIUS over non-UDP transports. The first thing to be addressed is the (bogus) usage of the term "backward compatibility" in the proposed charter. PLEASE replace it with "interoperable" or a synonym thereof. > > > > -- > 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: Fri, 18 Apr 2008 18:22:03 +0000 From: "David B. Nelson" To: Subject: RE: RADEXT WG re-charter Date: Fri, 18 Apr 2008 14:18:32 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000701c8a180$9c199ff0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acihexs9wuQMFAPzQfeXaNdQk2jAsQAAxCgwAAB5miA= Joseph Salowey writes... > ...you could encrypt the attributes that need to be separated, such > as keys, with an appropriate algorithm, such as SIV or the ever > unpopular AES keywrap, and then encapsulate the whole message > including the encrypted attributes with DTLS, IPSEC, etc. to > protect additional attributes in transit. > > So, I don't view these mechanisms as mutually exclusive. In point of fact, based on the notion that NASes may be required to continue using the legacy UDP-based RADIUS, these approaches may be complementary. There may be cases where encrypted attributes are preferable to encrypted transport. The converse may also be true. -- 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, 18 Apr 2008 18:16:46 +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: RADEXT WG re-charter Date: Fri, 18 Apr 2008 11:16:39 -0700 Message-ID: Thread-Topic: RADEXT WG re-charter Thread-Index: Acihexs9wuQMFAPzQfeXaNdQk2jAsQAAxCgw From: "Joseph Salowey (jsalowey)" To: "Dan Harkins" Cc: "David B. Nelson" , , "Glen Zorn" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5317; t=1208542550; x=1209406550; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=7MB1kGtGzLUWAYTuqkbIeFQVlVNZl8dJO9bZ0jCs3yQ=; b=teRlrz/Ibgt2L4yeAA/Wb/KiDP3dUzxx5K6VjgQH8sLVwB0PQX1tTFHbWZ 4y35UxnpqiI7zLS2TCqmWqhXULwOSegKBDacT2C0biZSe7mrLj6RywYbrOzQ vpqwvuioD4oxDGjftLGdTQmpuTbM1FYY2GzXZMS3U7abuOeJ1mLRU=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); This is not a requirement for all deployments. If it is a requirement then transport security presents a challenge, but it seems you could encrypt the attributes that need to be separated, such as keys, with an appropriate algorithm, such as SIV or the ever unpopular AES keywrap, and then encapsulate the whole message including the encrypted attributes with DTLS, IPSEC, etc. to protect additional attributes in transit. =20 So, I don't view these mechanisms as mutually exclusive.=20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org]=20 > Sent: Friday, April 18, 2008 10:39 AM > To: Joseph Salowey (jsalowey) > Cc: David B. Nelson; radiusext@ops.ietf.org; Glen Zorn;=20 > bernard_aboba@hotmail.com > Subject: RE: RADEXT WG re-charter >=20 >=20 > Hi Joe, >=20 > Pardon me for leaping so far back in this thread. >=20 > Is it a requirement to support multiple pieces of data=20 > encrypted with different keys in the same message? If it is=20 > then apparently both DTLS and IPsec are out-of-the-running=20 > since both those options secure the entire payload with one=20 > set of keys. Is this your view? >=20 > regards, >=20 > Dan. >=20 > On Tue, April 15, 2008 1:07 pm, Joseph Salowey (jsalowey) wrote: > > There are a few reasons why you would want to wrap keys separately=20 > > from other data. As you mentioned, the recommended=20 > algorithms for key=20 > > wrap may not be suitable for encrypting bulk data without special=20 > > consideration and some bulk data encryption algorithms may not be=20 > > recommended for key wrap without special consideration. Another=20 > > reason is that you may want the entity that handles the=20 > keys and their=20 > > context to be different from the entity that handles the=20 > rest of the attributes. > > > > > > Neither of these reasons forces you to have encryption tied=20 > directly=20 > > to the key attribute. It is convenient since one is very often=20 > > interested in encrypting keys, but you can achieve the same=20 > thing with=20 > > a generic encryption attribute if you take care. You need=20 > to support=20 > > multiple pieces of data encrypted with different keys (key IDs, alg=20 > > IDs, message boundaries, etc.) in the same message and you need to=20 > > make sure that the various supported encryption algorithms are used=20 > > correctly (type of cleartext, sufficient randomization, integrity=20 > > protection, etc.). These things don't necessarily happen=20 > automatically or come for free. > > > > If you don't consider keys as part of the data you are wrapping for=20 > > crypto agility, I'm not sure you will end up with a result that is=20 > > very useful. > > > > Joe > >> -----Original Message----- > >> From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] > >> Sent: Monday, April 14, 2008 10:29 AM > >> To: radiusext@ops.ietf.org; 'Glen Zorn' > >> Cc: Joseph Salowey (jsalowey); Bernard_Aboba@hotmail.com > >> Subject: RE: RADEXT WG re-charter > >> > >> Glen Zorn writes... > >> > >> > 'Frankly, my dear, I don't give a damn.' > >> > >> Cute... > >> > >> > It's been nearly 4 years (!) since=20 > draft-zorn-radius-keywrap-00.txt=20 > >> > was posted ... for at least 3 years there have been at 2=20 > (or more)=20 > >> > independent, interoperable implementations that were=20 > FIPS-certified. > >> > >> Given that there are implementations of this key-wrap scheme,=20 > >> presumably using VSAs, it might be well to publish an Information=20 > >> RFC, describing the actual implementations, using those VSAs. > >> > >> > But wait! Let's spend a little (lot) more time=20 > conjecturing about=20 > >> > another way, a way to solve "the general problem" (AKA=20 > "boiling the=20 > >> > ocean" if it's a proposal we don't care for). Well, gosh, > >> no thanks, > >> > but you guys go ahead & have fun! > >> > >> RADEXT has a chartered work item to address crypto-agility. > >> We have requirements for this wok, and we now have an ID capturing=20 > >> those requirements. We don't have a requirement to specifically=20 > >> address key-wrap, as a separate problem. My questions is whether=20 > >> RADEXT really needs to create two drafts to satisfy the=20 > >> crypto-agility work item, one for key-wrap and one for general=20 > >> purpose encrypted attributes. The fact that solutions,=20 > and drafts,=20 > >> exist to address key-wrap and encrypted attributes separately is a=20 > >> point in favor of retaining the separation. I'm just questioning=20 > >> whether that's a sufficient basis on which to decide that we need=20 > >> such separation of concerns. > >> > >> If the consensus us of the WG is that we should proceed=20 > with separate=20 > >> documents for key-wrap and general crypto-agility, we can propose=20 > >> doing that in our revised charter. It would be nice, however, to=20 > >> have a reason beyond the existence of (4 year old) drafts that are=20 > >> structured that way. > >> > >> > >> > > > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > >=20 >=20 >=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: Fri, 18 Apr 2008 17:40:24 +0000 Message-ID: Date: Fri, 18 Apr 2008 10:38:58 -0700 (PDT) Subject: RE: RADEXT WG re-charter From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" Cc: "David B. Nelson" , radiusext@ops.ietf.org, "Glen Zorn" , bernard_aboba@hotmail.com User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Joe, Pardon me for leaping so far back in this thread. Is it a requirement to support multiple pieces of data encrypted with different keys in the same message? If it is then apparently both DTLS and IPsec are out-of-the-running since both those options secure the entire payload with one set of keys. Is this your view? regards, Dan. On Tue, April 15, 2008 1:07 pm, Joseph Salowey (jsalowey) wrote: > There are a few reasons why you would want to wrap keys separately from > other data. As you mentioned, the recommended algorithms for key wrap > may not be suitable for encrypting bulk data without special > consideration and some bulk data encryption algorithms may not be > recommended for key wrap without special consideration. Another reason > is that you may want the entity that handles the keys and their context > to be different from the entity that handles the rest of the attributes. > > > Neither of these reasons forces you to have encryption tied directly to > the key attribute. It is convenient since one is very often interested > in encrypting keys, but you can achieve the same thing with a generic > encryption attribute if you take care. You need to support multiple > pieces of data encrypted with different keys (key IDs, alg IDs, message > boundaries, etc.) in the same message and you need to make sure that the > various supported encryption algorithms are used correctly (type of > cleartext, sufficient randomization, integrity protection, etc.). These > things don't necessarily happen automatically or come for free. > > If you don't consider keys as part of the data you are wrapping for > crypto agility, I'm not sure you will end up with a result that is very > useful. > > Joe >> -----Original Message----- >> From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] >> Sent: Monday, April 14, 2008 10:29 AM >> To: radiusext@ops.ietf.org; 'Glen Zorn' >> Cc: Joseph Salowey (jsalowey); Bernard_Aboba@hotmail.com >> Subject: RE: RADEXT WG re-charter >> >> Glen Zorn writes... >> >> > 'Frankly, my dear, I don't give a damn.' >> >> Cute... >> >> > It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt >> > was posted ... for at least 3 years there have been at 2 (or more) >> > independent, interoperable implementations that were FIPS-certified. >> >> Given that there are implementations of this key-wrap scheme, >> presumably using VSAs, it might be well to publish an >> Information RFC, describing the actual implementations, using >> those VSAs. >> >> > But wait! Let's spend a little (lot) more time conjecturing about >> > another way, a way to solve "the general problem" (AKA "boiling the >> > ocean" if it's a proposal we don't care for). Well, gosh, >> no thanks, >> > but you guys go ahead & have fun! >> >> RADEXT has a chartered work item to address crypto-agility. >> We have requirements for this wok, and we now have an ID >> capturing those requirements. We don't have a requirement to >> specifically address key-wrap, as a separate problem. My >> questions is whether RADEXT really needs to create two drafts >> to satisfy the crypto-agility work item, one for key-wrap and >> one for general purpose encrypted attributes. The fact that >> solutions, and drafts, exist to address key-wrap and >> encrypted attributes separately is a point in favor of >> retaining the separation. I'm just questioning whether >> that's a sufficient basis on which to decide that we need >> such separation of concerns. >> >> If the consensus us of the WG is that we should proceed with >> separate documents for key-wrap and general crypto-agility, >> we can propose doing that in our revised charter. It would >> be nice, however, to have a reason beyond the existence of (4 >> year old) drafts that are structured that way. >> >> >> > > -- > 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: Fri, 18 Apr 2008 15:04:38 +0000 From: "David B. Nelson" To: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 11:00:49 -0400 Organization: Elbrys Networks, Inc. Message-ID: <039601c8a164$fd337a70$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugAAWmUtg Glen Zorn writes... > One example: the maximum length of 4096 octets for a Radius packet > was chosen (IIRC) based upon the maximum size of a _UDP_ frame that > could be reliably transmitted w/o fragmentation _in the access > networks of the day_. I've forgotten that discussion. Isn't 4096 the maximum size *any* UDP frame, IP fragmentation and reassembly notwithstanding? > It doesn't seem to be very smart to go to all the trouble of > defining RADIUSoTCP while leaving this kind of unnecessary, > UDP-specific limitation in place. I recall that you have many times advocated the need for longer RADIUS packets and/or more/longer RADIUS attributes. It is true that any RADSEC to RADIUS gateway needs to address what is to be done about larger than UDP-size RADSEC messages in translating them to RADIUS messages. I need to see if that issue is covered in the "AAA Transports" RFC... I believe that addressing this issue ought to be another element of our definition of backwards compatibility for RADIUS over non-UDP transports. -- 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, 18 Apr 2008 14:56:24 +0000 From: "David B. Nelson" To: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 10:52:12 -0400 Organization: Elbrys Networks, Inc. Message-ID: <039501c8a163$c8f60620$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcihKuHbMfFVkL5IT1ybt9emDl20ngAOEbyA Stefan Winter writes... > Well, if an implementation would do RadSec exclusively, and NOT > listen on UDP/1812 as well, then yes, RADIUS clients would not be > able to communicate with that implementation. > > Reality however is that all the implementations so far can do > both, UDP/1812 and RadSec on TCP/2083, and are able to translate > between both. Such implementations *are* interoperable with existing > RADIUS clients. So one of the elements of our backwards compatibility definition might be that any implementation (server or proxy) of RADIUS over a non-UDP transport that will be used to directly service a NAS MUST additionally implement a "RADIUS Classic" UDP/1812 listener. -- 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, 18 Apr 2008 08:02:36 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Matt Holdrege" Subject: Re: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 10:01:30 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1346050.FOUIHeYVxR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804181001.34810.stefan.winter@restena.lu> --nextPart1346050.FOUIHeYVxR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > If you go by the assumption, as reality pretty much dictates, that > RADIUS is not divorced from specific transport binding, then you should > be very cautious to avoid creating a heck of a lot of confusion > downstream from where we sit. For the last umpteen years RADIUS has been > RADIUS. True we have caused all sorts of havoc with attributes, but that > hasn't killed basic interoperability between RADIUS clients and servers. > This new effort would kill that basic interoperability. Therefore you > need to make very clear that the result of this work will NOT be > interoperable with the massive world-wide deployment of RADIUS clients. Well, if an implementation would do RadSec exclusively, and NOT listen on=20 UDP/1812 as well, then yes, RADIUS clients would not be able to communicate= =20 with that implementation. Reality however is that all the implementations so far can do both, UDP/181= 2=20 and RadSec on TCP/2083, and are able to translate between both. Such=20 implementations *are* interoperable with existing RADIUS clients. Since this is a (sane) behaviour by all implementations so far, it might be= =20 wise to add an according note to the RadSec I-D that: if interoperability=20 with standard RADIUS clients is required, the implementation also has to=20 listen on UDP/1812 (I used to think that goes without saying, but it=20 certainly doesn't hurt to put that sentence in there). I wouldn't want to=20 mandate this for all implementations as a MUST though, since I can easily=20 imagine proxy interconnections in a backend that have no business with NASe= s,=20 and for such deployments it would just be an unnecessary burden to mandate= =20 listening in UDP/1812. 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 --nextPart1346050.FOUIHeYVxR 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) iD8DBQBICFVe+jm90f8eFWYRArEzAJ4jt7YNVhA9QQN5DMPN8cwCr7vmjwCfceOD bxz9BLCGnK1wGgSxSepHdR4= =ia6H -----END PGP SIGNATURE----- --nextPart1346050.FOUIHeYVxR-- -- 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, 18 Apr 2008 07:22:33 +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: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 00:21:33 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181BF6@wv-mailsrv2.strixsystems.com> Thread-Topic: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAAExpsUA== From: "Matt Holdrege" To: "David B. Nelson" , -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson Sent: Friday, April 18, 2008 12:14 AM Glen Zorn writes... > I AM REALLY OPPOSED TO BS, however ... If I thought that slam was targeted at me, I might be offended. :-) > ... I don't really understand this manic grasping at straws to=20 > claim RadSec's "backward compatibility", to the point that now we > have 'if you used this interface when you wrote your code (as opposed > to the easy, obvious one)' then it's really almost the same but not > quite'. We need a reasonable definition of "backward compatible" to scope this work. It needs to be unambiguous, so that we can tell when it has or has not been met. It has to be simple enough that we can understand it. Whether or not you agree that RADIUS *has* an application layer specification that can be divorced from a specific transport binding, it is important that the RADSEC specification (or any other alternate transport specifications for RADIUS) make it clear that all we want to tinker with in this work item is the *transport* layer. We want the RADIUS PDUs to remain otherwise unchanged. What's wrong with that? ---------------------------------------------------------------- If you go by the assumption, as reality pretty much dictates, that RADIUS is not divorced from specific transport binding, then you should be very cautious to avoid creating a heck of a lot of confusion downstream from where we sit. For the last umpteen years RADIUS has been RADIUS. True we have caused all sorts of havoc with attributes, but that hasn't killed basic interoperability between RADIUS clients and servers. This new effort would kill that basic interoperability. Therefore you need to make very clear that the result of this work will NOT be interoperable with the massive world-wide deployment of RADIUS clients. -Matt -- 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, 18 Apr 2008 04:30:19 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Fri, 18 Apr 2008 11:28:18 +0700 Message-ID: <006601c8a10c$aa26ad00$6ce2787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlAADIyugA== owner-radiusext@ops.ietf.org <> scribbled on Friday, April 18, 2008 5:14 AM: ... >> ... I don't really understand this manic grasping at straws to claim >> RadSec's "backward compatibility", to the point that now we have 'if >> you used this interface when you wrote your code (as opposed to the >> easy, obvious one)' then it's really almost the same but not quite'. > > We need a reasonable definition of "backward compatible" to > scope this work. > It needs to be unambiguous, so that we can tell when it has or > has not been met. It has to be simple enough that we can understand > it. I agree completely. What is amazing is that, given the fact that "backward compatibility" has been in the charter since the WG was formed (& has been used as a stick to beat to death several useful proposals), this definition doesn't already exist. In fact, its utility as an ad hoc bludgeon is such that I doubt that such a clear, unambiguous definition will be forthcoming (let alone written into the charter). I sincerely hope that I'm proven wrong... > > Whether or not you agree that RADIUS *has* an application > layer specification that can be divorced from a specific > transport binding, it is important that the RADSEC > specification (or any other alternate transport specifications > for RADIUS) make it clear that all we want to tinker with in > this work item is the *transport* layer. We want the RADIUS > PDUs to remain otherwise unchanged. > > What's wrong with that? One thing that's wrong is that it ignores the limitations on the RADIUS PDU that exist primarily (or solely) because of the UDP transport. One example: the maximum length of 4096 octets for a Radius packet was chosen (IIRC) based upon the maximum size of a _UDP_ frame that could be reliably transmitted w/o fragmentation _in the access networks of the day_. It doesn't seem to be very smart to go to all the trouble of defining RADIUSoTCP while leaving this kind of unnecessary, UDP-specific limitation in place. ... -- 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, 17 Apr 2008 23:05:21 +0000 Message-ID: <1b0ef15e32c8840021ae4d76299649c7.squirrel@www.trepanning.net> Date: Thu, 17 Apr 2008 16:04:26 -0700 (PDT) Subject: RE: RADEXT WG re-charter From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" Cc: "David B. Nelson" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit A very intersting discussion.... Yes, bulk data protection with the current key wrapping scheme (RFC3394) is problematic. It requires things to be 64-bit aligned, it doesn't allow "associated data" (AD) which is authenticated but not encrypted, and while it is probably secure it does not have a formal proof of security behind it. All of these problems can be addressed by the SIV mode of AES. SIV can provide deterministic "key wrapping" when a component of the plaintext is random, and it can provide nonce-based bulk data encryption. In both variants it allows AD. It also provides security even in the presence of nonce reuse. This last issue is especially critical when one does not have a dynamic key exchange but, instead, uses statically provisioned keys on the client and server. If one side crashes and loses state (like a counter value or knowledge of previously used nonces) the security of the system must not suffer, nor is it realistic to require each side to checkpoint state in some non-volatile storage. Secure key wrapping with AD plus bulk data encryption with AD that is resistant to nonce reuse, all in one cipher mode. That sounds useful.... Dan. On Wed, April 16, 2008 3:28 pm, Joseph Salowey (jsalowey) wrote: > > >> -----Original Message----- >> From: owner-radiusext@ops.ietf.org >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson >> Sent: Wednesday, April 16, 2008 5:52 AM >> To: radiusext@ops.ietf.org >> Subject: RE: RADEXT WG re-charter >> >> Joseph Salowey writes... >> >> > There are a few reasons why you would want to wrap keys separately >> > from other data. As you mentioned, the recommended >> algorithms for key >> > wrap may not be suitable for encrypting bulk data without special >> > consideration ... >> >> Yes, because in those cases you are *relying* on the >> randomness of the key material. >> > [Joe] That's at least part of the problem, but in general these > algorithms were not designed for bulk data encryption so there may be > other issues that I don't know about. > >> > ... and some bulk data encryption algorithms may not be recommended >> > for key wrap without special consideration. >> >> That's the part I still don't understand. The only >> "consideration" I've heard so far is that "NIST hasn't >> blessed it", which is political and not technical. Of >> course, if you think that a critical goal of RADIUS >> Crypto-Agility is to facilitate creating FIPS certifiable >> products, then maybe this should be listed in the RADIUS >> Crypto-Agility Requirements draft. >> > [Joe] I wouldn't say this is just political. NIST has designed an > algorithm for the purpose of wrapping keys. While this may not be > everybody's favorite solution it seems silly to design a crypto-agility > solution that cannot accommodate it. I would say the requirement is to > support key wrapping. > >> > Another reason is that you may want the entity that handles >> the keys >> > and their context to be different from the entity that handles the >> > rest of the attributes. >> >> Perhaps. You could provide that enforced "separation of >> concerns" by using a separate KEK for the keys and a DEK for >> the data. The algorithm and mode need not be different to >> provide the isolation. Since the key management and >> distribution, e.g. automated key management, is currently out >> of scope for RADIUS Crypto-Agility, that shouldn't present an >> impediment. >> > [Joe] Yes, at the very least the keys must be different, but for the > reasons discussed above you may want to vary the algorithms as well. I > would think if you can figure out how to have different keys you can > also figure out how to support different algorithms. > > >> > Neither of these reasons forces you to have encryption tied >> directly >> > to the key attribute. It is convenient since one is very often >> > interested in encrypting keys, but you can achieve the same >> thing with >> > a generic encryption attribute if you take care. >> >> OK. What care do we need to take? >> > [Joe] That's what I scribbled about on parenthesis below. > >> > You need to support multiple pieces of data encrypted with >> different >> > keys (key IDs, alg IDs, message boundaries, etc.) in the >> same message >> > and you need to make sure that the various supported encryption >> > algorithms are used correctly (type of cleartext, sufficient >> > randomization, integrity protection, etc.). >> >> If we determine that the algorithm and mode that do not >> depend upon a random payload, but are still strong when the >> payload happens to be random, what's the issue? >> > [Joe] As stated above the issues are using the algorithms for what they > are designed for and support separation between keys and their context > from other attributes. There can be multiple ways we can design this > which would work out fine by pushing some of the inconvenient bits to > different places. > >> > If you don't consider keys as part of the data you are wrapping for >> > crypto agility, I'm not sure you will end up with a result that is >> > very useful. >> >> Sure. We need to have a method that works for keys, too. >> I'm trying to figure out if there is a "one size fits all" >> algorithm and method (assuming a separate KEK), and if not, >> why not. So far the only impediment that I see remaining is >> the "it's not blessed by NIST" for that particular >> application, e.g. key wrap. >> > [Joe] NIST as defined a key wrapping algorithm, it may not be the best > thing for all purposes, but it is good enough for key wrapping and it > has been implemented for this purpose in various solutions. Designing a > crypto-agility solution that cannot support this seems short-sighted > since NIST validation is an important part of many customer's > requirements. This is especially true since one of the main pieces of > data people are concerned about protecting in today's deployments are > keys. While I favor a specific attribute for key wrap solution, I do > not think it is necessary to design it this way. If we support > different encrypted payloads in the same message with different keys and > different algorithms you have effectively the same thing (you just > wouldn't know that it was a key and its context that was wrapped). We > should limit the usage of key-wrap specific algorithms to the purpose > they were designed for. > >> BTW, thank you very much for a *technical* discussion of the >> issue. It's quite refreshing. :-) >> >> >> >> -- >> 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: > -- 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, 17 Apr 2008 22:18:00 +0000 From: "David B. Nelson" To: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Thu, 17 Apr 2008 18:14:27 -0400 Organization: Elbrys Networks, Inc. Message-ID: <034d01c8a0d8$6652ed70$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6AACRVUlA= Glen Zorn writes... > I AM REALLY OPPOSED TO BS, however ... If I thought that slam was targeted at me, I might be offended. :-) > ... I don't really understand this manic grasping at straws to > claim RadSec's "backward compatibility", to the point that now we > have 'if you used this interface when you wrote your code (as opposed > to the easy, obvious one)' then it's really almost the same but not > quite'. We need a reasonable definition of "backward compatible" to scope this work. It needs to be unambiguous, so that we can tell when it has or has not been met. It has to be simple enough that we can understand it. Whether or not you agree that RADIUS *has* an application layer specification that can be divorced from a specific transport binding, it is important that the RADSEC specification (or any other alternate transport specifications for RADIUS) make it clear that all we want to tinker with in this work item is the *transport* layer. We want the RADIUS PDUs to remain otherwise unchanged. What's wrong with that? -- 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, 17 Apr 2008 22:06:31 +0000 From: "David B. Nelson" To: Subject: RE: RADEXT WG re-charter Date: Thu, 17 Apr 2008 18:02:34 -0400 Organization: Elbrys Networks, Inc. Message-ID: <034901c8a0d6$bd89cf70$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcigIibHOklDiy1GQ3WOXzFohAm2igAs3ZOQ Bernard Aboba writes... > At IETF 71, the technical discussion brought up the following points: > > a. The integrity protection for keywrap is considerably *weaker* > (e.g. 64 bits) than for standard MIC algorithms. > b. Encryption algorithms for keywrap cannot be securely used to do > bulk encryption of data, but algorithms that can do bulk encryption > can securely be used to encrypt keys. Are there specific recommendations (e.g. an "SP" series document) from NIST that cover the use of bulk encryption algorithms to encrypt keys? > c. Existing IETF standards (such as Diameter EAP, RFC 4702) use TLS to > protect keys. > Given this, I would suggest that assertions made about NIST positions > should be ruled out of scope, unless they come directly from > representatives of NIST. Or presumably from existing NIST publications... I tend to think (individual opinion) that facilitating FIPS "certifiable" implementations might be a reasonable requirement to be added into the RADIUS Crypto-Agility Requirements draft, assuming the reference is to an existing NIST publication. I understand that these publications would discuss algorithms and modes only, and not cover how to encapsulate a key in a RADIUS attribute. -- 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, 17 Apr 2008 20:17:24 +0000 Message-Id: <7.0.1.0.2.20080417160616.02403730@nist.gov> Date: Thu, 17 Apr 2008 16:15:54 -0400 To: ietf@ietf.org, dime@ietf.org, radiusext@ops.ietf.org From: Katrin Hoeper Subject: Invitation to join IETF proxy mailing list Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_22428828==.ALT" --=====================_22428828==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts. For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a result of our meeting, a proxy email list was created to further investigate the proxy problems. We decided to use AAA proxies as a starting point for our discussion on the list. The long-term (and ideal) goal could be to extend the results of the AAA proxy discussion in order to address proxy-related security issues in general. However, for now we will focus on AAA proxies. This email serves as an invitation for anybody interested to join our discussions on the list. Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies Best regards, Katrin Hoeper ---------- Katrin Hoeper Computer Security Division National Institute of Standards and Technology (NIST) 100 Bureau Dr. Mail stop: 8930 Gaithersburg, MD 20878 (301) 975 - 4024 --=====================_22428828==.ALT Content-Type: text/html; charset="us-ascii" Hi,

Security problems related to network proxies persistently come up in several IETF WGs and may affect the security of existing IETF network solutions while slowing down the progress of some current Internet Drafts.

For this reason, Tim Polk and I organized an informal meeting in Philadelphia at IETF 71 to discuss these so-called "proxy problems" and their implications. As a
result of our meeting, a proxy email list was created to further investigate the proxy problems.

We decided to use AAA proxies as a starting point for our discussion on the list. The long-term (and ideal) goal could be to extend the results of the AAA proxy discussion in order to address proxy-related security issues in general. However, for now we will focus on AAA proxies.

This email serves as an invitation for anybody interested to join our discussions on the list.
Please subscribe at: https://www.ietf.org/mailman/listinfo/proxies

Best regards,
Katrin Hoeper

Katrin Hoeper
Computer Security Division
National Institute of Standards and Technology (NIST)
100 Bureau Dr. Mail stop: 8930
Gaithersburg, MD 20878
(301) 975 - 4024
 --=====================_22428828==.ALT-- -- 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, 17 Apr 2008 17:18:49 +0000 From: Avi Lior To: Glen Zorn CC: "Bernard_Aboba@hotmail.com" , "radiusext@ops.ietf.org" Date: Thu, 17 Apr 2008 13:17:07 -0400 Subject: RE: Consensus Call on RADEXT WG re-charter Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMpXIFccirmMPQOO1YeKWg6NdLABN4KQgADiQZSAAGJ3IYA== Message-ID: <8A8CFE8F89C38B41A749C19328C76D63038852B100@exchange02.bridgewatersys.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@comcast.net] > Sent: Thursday, April 17, 2008 1:35 AM > To: Avi Lior > Cc: Bernard_Aboba@hotmail.com; radiusext@ops.ietf.org > Subject: RE: Consensus Call on RADEXT WG re-charter > > owner-radiusext@ops.ietf.org <> scribbled on Wednesday, April > 16, 2008 11:20 PM: > > > There is a very interesting thing happening here with the notion of > > adding a new transport to RADIUS: specifically TCP/TLS transport to > > RADIUS. > > > > In recent experiences in other SDOs people were concerned about the > > scalability of Diameter. Specifically, in the hot arena of Femto > > Cells and Diameter, people were wondering how a diameter > server would > > maintain 100,000 plus connections with the femtos. This > without using > > multiple servers. > > > > So here we are thinking about perhaps introducing a UDP > transport or > > something equivalent for the Diameter server -- at least for that > > first hop between the femto cell in your home and the > operator's site. > > > > Perhaps the right approach for these protocols is to allow them to > > utilize the correct transport for the job at hand. > > Having no choice is seemingly problematic. > > Good point. On that note, it seems that RadSec (as currently > specified) creates one new option but eliminates another. > Would it be worthwhile defining RADIUS over TCP, & then how > to use TLS to protect it? Yes. -- 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, 17 Apr 2008 05:36:33 +0000 From: "Glen Zorn" To: "'Avi Lior'" Cc: , Subject: RE: Consensus Call on RADEXT WG re-charter Date: Thu, 17 Apr 2008 12:34:57 +0700 Message-ID: <000f01c8a04c$ce894380$9ae4787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcieMpXIFccirmMPQOO1YeKWg6NdLABN4KQgADiQZSA= owner-radiusext@ops.ietf.org <> scribbled on Wednesday, April 16, 2008 11:20 PM: > There is a very interesting thing happening here with the > notion of adding a new transport to RADIUS: specifically > TCP/TLS transport to RADIUS. > > In recent experiences in other SDOs people were concerned > about the scalability of Diameter. Specifically, in the hot > arena of Femto Cells and Diameter, people were wondering how a > diameter server would maintain 100,000 plus connections with > the femtos. This without using multiple servers. > > So here we are thinking about perhaps introducing a UDP > transport or something equivalent for the Diameter server -- > at least for that first hop between the femto cell in your > home and the operator's site. > > Perhaps the right approach for these protocols is to allow > them to utilize the correct transport for the job at hand. > Having no choice is seemingly problematic. Good point. On that note, it seems that RadSec (as currently specified) creates one new option but eliminates another. Would it be worthwhile defining RADIUS over TCP, & then how to use TLS to protect it? ... -- 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, 17 Apr 2008 05:04:32 +0000 From: "Glen Zorn" To: "'David B. Nelson'" , Cc: "'Matt Holdrege'" Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Thu, 17 Apr 2008 12:02:28 +0700 Message-ID: <000001c8a048$450e3e70$9ae4787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MAAWjL6A owner-radiusext@ops.ietf.org <> scribbled on Thursday, April 17, 2008 1:07 AM: > Matt Holdrege writes... > >> OK, that's fine, but then if *real* RADIUS clients aren't really a >> part of this effort, then why is it in this WG? > > Hmmm. Because the WG isn't limited to considering only RADIUS > extensions that [primarily] impact the NAS? Hmmm. Since _everything_ has to change, how can you say that? > >> I assume you have some reason for not using IETF recommended IPsec to >> secure proxy-to-proxy data? > > That issue has been discussed. There are implementations and > deployments of RADIUS over IPsec. The thing that some folks > don't like about IPsec is that it's a Layer 3 protocol and > isn't visible to applications at Layer 4 (e.g. > at the socket interface) the way TLS is. > >> If so, why don't you create another proxy-server to proxy-server >> encryption protocol? > > One could claim that RADSEC neatly fills that bill. Conceptually, yes; it's nowhere near fully baked from a standards POV IMHO, but it (or something very similar) has been working in very large commercial roaming networks for a very long time. BTW (since it doesn't seem to have gotten through to some people) let me say it again: I am not & never have been opposed to the standardization of RadSec. I think that it's a mistake to undertake the task in this WG (not least of all because of an obvious antagonism to innovation on the part of some members) but since the tide of opinion seems to be to do that it's fine. I AM REALLY OPPOSED TO BS, however & I don't really understand this manic grasping at straws to claim RadSec's "backward compatibility", to the point that now we have 'if you used this interface when you wrote your code (as opposed to the easy, obvious one)' then it's really almost the same but not quite'. Please. ... -- 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, 17 Apr 2008 00:27:09 +0000 Message-ID: From: "Bernard Aboba" To: "David B. Nelson" , Subject: Re: RADEXT WG re-charter Date: Wed, 16 Apr 2008 17:25:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > That's the part I still don't understand. The only "consideration" I've > heard so far is that "NIST hasn't blessed it", which is political and not > technical. At IETF 71, the technical discussion brought up the following points: a. The integrity protection for keywrap is considerably *weaker* (e.g. 64 bits) than for standard MIC algorithms. b. Encryption algorithms for keywrap cannot be securely used to do bulk encryption of data, but algorithms that can do bulk encryption can securely be used to encrypt keys. c. Existing IETF standards (such as Diameter EAP, RFC 4702) use TLS to protect keys. There are no known security issues relating to this. As far as the "politics" goes, at various points during this discussion, assertions have been made with respect to NIST's position. However, when NIST was contacted to verify those assertions, they indicated that the assertions either did not represent the official position of NIST, or that NIST had not yet taken a position. Given this, I would suggest that assertions made about NIST positions should be ruled out of scope, unless they come directly from representatives of NIST. -- 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, 16 Apr 2008 22:29:17 +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: RADEXT WG re-charter Date: Wed, 16 Apr 2008 15:28:49 -0700 Message-ID: Thread-Topic: RADEXT WG re-charter Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFAAAers8AAWnCbAAEQZ+DAAE3icMA== From: "Joseph Salowey (jsalowey)" To: "David B. Nelson" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5647; t=1208384879; x=1209248879; c=relaxed/simple; s=sjdkim2002; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=w37jCLzqUvB26Dckum0qwX1znadW2a5GjO5wciDIHgA=; b=Io2SebrFXlhnAv4A2/pzLbg/I5LleBwCpFDDL64jiDMThM1JoDRg1D/2WV f60aNfIgkBd6hCu1UWSky6nh0kh9vcnjDvH/GMF/XbY+9StgtaoGh1ADoDaI eghouR90NG; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: Wednesday, April 16, 2008 5:52 AM > To: radiusext@ops.ietf.org > Subject: RE: RADEXT WG re-charter >=20 > Joseph Salowey writes... > =20 > > There are a few reasons why you would want to wrap keys separately=20 > > from other data. As you mentioned, the recommended=20 > algorithms for key=20 > > wrap may not be suitable for encrypting bulk data without special=20 > > consideration ... >=20 > Yes, because in those cases you are *relying* on the=20 > randomness of the key material. >=20 [Joe] That's at least part of the problem, but in general these algorithms were not designed for bulk data encryption so there may be other issues that I don't know about.=20 > > ... and some bulk data encryption algorithms may not be recommended=20 > > for key wrap without special consideration. >=20 > That's the part I still don't understand. The only=20 > "consideration" I've heard so far is that "NIST hasn't=20 > blessed it", which is political and not technical. Of=20 > course, if you think that a critical goal of RADIUS=20 > Crypto-Agility is to facilitate creating FIPS certifiable=20 > products, then maybe this should be listed in the RADIUS=20 > Crypto-Agility Requirements draft. >=20 [Joe] I wouldn't say this is just political. NIST has designed an algorithm for the purpose of wrapping keys. While this may not be everybody's favorite solution it seems silly to design a crypto-agility solution that cannot accommodate it. I would say the requirement is to support key wrapping.=20 > > Another reason is that you may want the entity that handles=20 > the keys=20 > > and their context to be different from the entity that handles the=20 > > rest of the attributes. >=20 > Perhaps. You could provide that enforced "separation of=20 > concerns" by using a separate KEK for the keys and a DEK for=20 > the data. The algorithm and mode need not be different to=20 > provide the isolation. Since the key management and=20 > distribution, e.g. automated key management, is currently out=20 > of scope for RADIUS Crypto-Agility, that shouldn't present an=20 > impediment. >=20 [Joe] Yes, at the very least the keys must be different, but for the reasons discussed above you may want to vary the algorithms as well. I would think if you can figure out how to have different keys you can also figure out how to support different algorithms.=20 > > Neither of these reasons forces you to have encryption tied=20 > directly=20 > > to the key attribute. It is convenient since one is very often=20 > > interested in encrypting keys, but you can achieve the same=20 > thing with=20 > > a generic encryption attribute if you take care. >=20 > OK. What care do we need to take? >=20 [Joe] That's what I scribbled about on parenthesis below.=20 > > You need to support multiple pieces of data encrypted with=20 > different=20 > > keys (key IDs, alg IDs, message boundaries, etc.) in the=20 > same message=20 > > and you need to make sure that the various supported encryption=20 > > algorithms are used correctly (type of cleartext, sufficient=20 > > randomization, integrity protection, etc.). >=20 > If we determine that the algorithm and mode that do not=20 > depend upon a random payload, but are still strong when the=20 > payload happens to be random, what's the issue? >=20 [Joe] As stated above the issues are using the algorithms for what they are designed for and support separation between keys and their context from other attributes. There can be multiple ways we can design this which would work out fine by pushing some of the inconvenient bits to different places.=20 > > If you don't consider keys as part of the data you are wrapping for=20 > > crypto agility, I'm not sure you will end up with a result that is=20 > > very useful. >=20 > Sure. We need to have a method that works for keys, too. =20 > I'm trying to figure out if there is a "one size fits all"=20 > algorithm and method (assuming a separate KEK), and if not,=20 > why not. So far the only impediment that I see remaining is=20 > the "it's not blessed by NIST" for that particular=20 > application, e.g. key wrap. >=20 [Joe] NIST as defined a key wrapping algorithm, it may not be the best thing for all purposes, but it is good enough for key wrapping and it has been implemented for this purpose in various solutions. Designing a crypto-agility solution that cannot support this seems short-sighted since NIST validation is an important part of many customer's requirements. This is especially true since one of the main pieces of data people are concerned about protecting in today's deployments are keys. While I favor a specific attribute for key wrap solution, I do not think it is necessary to design it this way. If we support different encrypted payloads in the same message with different keys and different algorithms you have effectively the same thing (you just wouldn't know that it was a key and its context that was wrapped). We should limit the usage of key-wrap specific algorithms to the purpose they were designed for. =20 > BTW, thank you very much for a *technical* discussion of the=20 > issue. It's quite refreshing. :-) >=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: Wed, 16 Apr 2008 18:11:04 +0000 From: "David B. Nelson" To: Cc: "'Matt Holdrege'" Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 14:07:26 -0400 Organization: Elbrys Networks, Inc. Message-ID: <029f01c89fec$b9f8d5d0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9AAACZ8MA== Matt Holdrege writes... > OK, that's fine, but then if *real* RADIUS clients aren't really > a part of this effort, then why is it in this WG? Hmmm. Because the WG isn't limited to considering only RADIUS extensions that [primarily] impact the NAS? > I assume you have some reason for not using IETF recommended IPsec > to secure proxy-to-proxy data? That issue has been discussed. There are implementations and deployments of RADIUS over IPsec. The thing that some folks don't like about IPsec is that it's a Layer 3 protocol and isn't visible to applications at Layer 4 (e.g. at the socket interface) the way TLS is. > If so, why don't you create another proxy-server to proxy-server > encryption protocol? One could claim that RADSEC neatly fills that bill. -- 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, 16 Apr 2008 18:00:52 +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: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 11:00:08 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181A3C@wv-mailsrv2.strixsystems.com> Thread-Topic: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/wAABlR9A= From: "Matt Holdrege" To: "David B. Nelson" , -----Original Message----- From: David B. Nelson [mailto:dnelson@elbrysnetworks.com]=20 Sent: Wednesday, April 16, 2008 7:51 PM Matt Holdrege writes... > RADIUS has always used UDP and perhaps a lot of developers have=20 > counted on that and never developed their products to be socket > layer neutral. This is quite possible. > Not to mention that a firmware change of clients is not really=20 > an option in most cases. My personal (individual WG member) opinion is that the RADSEC work is interesting for proxy-to-proxy and proxy-to-home-server usages. I think that it would be fairly rare to see it in NAS-to-server or NAS-to-proxy cases. That takes most of the "sting" out of the "wedded-to-UDP" issues with NAS-based client implementations. I think of proxies as being a server and client glued together, BTW. -------------------------------------------------------------- OK, that's fine, but then if *real* RADIUS clients aren't really a part of this effort, then why is it in this WG? I assume you have some reason for not using IETF recommended IPsec to secure proxy-to-proxy data? If so, why don't you create another proxy-server to proxy-server encryption protocol? Sorry, I expect this has been discussed before already. If so, disregard my question. -Matt -- 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, 16 Apr 2008 17:54:19 +0000 From: "David B. Nelson" To: Cc: "'Matt Holdrege'" Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 13:50:34 -0400 Organization: Elbrys Networks, Inc. Message-ID: <029e01c89fea$5f2eb7c0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkAAA+C/w Matt Holdrege writes... > RADIUS has always used UDP and perhaps a lot of developers have > counted on that and never developed their products to be socket > layer neutral. This is quite possible. > Not to mention that a firmware change of clients is not really > an option in most cases. My personal (individual WG member) opinion is that the RADSEC work is interesting for proxy-to-proxy and proxy-to-home-server usages. I think that it would be fairly rare to see it in NAS-to-server or NAS-to-proxy cases. That takes most of the "sting" out of the "wedded-to-UDP" issues with NAS-based client implementations. I think of proxies as being a server and client glued together, BTW. -- 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, 16 Apr 2008 17:22:12 +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: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 10:21:02 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181A2B@wv-mailsrv2.strixsystems.com> Thread-Topic: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaAAA7vqkA== From: "Matt Holdrege" To: "David B. Nelson" , -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson An alternate point of view is that a RADIUS client or server implementation doesn't need to change very much if the sockets that it opens are stream sockets as opposed to datagram sockets. The data flow, above the socket layer, (i.e. the application PDU stream) is the same. In that regard, the RADIUS protocol specification relies upon, but does not include the socket layer and all the layers below. ------------------------------------------------------------------------ ----------------- The above would be a heck of an assumption to make for all RADIUS clients out in the field. The real world is rarely as simple as a high level protocol architecture document. RADIUS has always used UDP and perhaps a lot of developers have counted on that and never developed their products to be socket layer neutral. Not to mention that a firmware change of clients is not really an option in most cases. However as I said before, it's nothing much to cry about on the server side. -- 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, 16 Apr 2008 17:06:05 +0000 From: "David B. Nelson" To: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 13:02:26 -0400 Organization: Elbrys Networks, Inc. Message-ID: <029d01c89fe3$a60d4820$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3wAA8SKaA= Glen Zorn writes... > > For transport items this basically means "uses RADIUS packet > > formats defined in RFC 2865, 2866 and 5176" (although the > > ports can be different). > > So what you're saying is that two nodes can be unable to > communicate & still be "backward compatible"? I don't think that's what was meant. I think understand your position: -- The use of UDP is mandated in RFC 2865. -- Packets sent by clients over UDP to Port 1812, won't be received by a server listening on TCP Port . An alternate point of view is that a RADIUS client or server implementation doesn't need to change very much if the sockets that it opens are stream sockets as opposed to datagram sockets. The data flow, above the socket layer, (i.e. the application PDU stream) is the same. In that regard, the RADIUS protocol specification relies upon, but does not include the socket layer and all the layers below. -- 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, 16 Apr 2008 16:28:33 +0000 From: Mudit Goel To: "Bernard_Aboba@hotmail.com" , "radiusext@ops.ietf.org" Date: Wed, 16 Apr 2008 09:27:36 -0700 Subject: RE: Consensus Call on RADEXT WG re-charter Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMuM1ypKFHVrRSFWbhLct/k3bKABq9K8w Message-ID: <456A5146F9319946A179B523B9FC91D60D9EE7109E@NA-EXMSG-C114.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_456A5146F9319946A179B523B9FC91D60D9EE7109ENAEXMSGC114re_" MIME-Version: 1.0 --_000_456A5146F9319946A179B523B9FC91D60D9EE7109ENAEXMSGC114re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in favor of this proposal. Mudit Goel From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Bernard_Aboba@hotmail.com Sent: Monday, April 14, 2008 6:20 AM To: radiusext@ops.ietf.org Subject: Consensus Call on RADEXT WG re-charter This is a consensus call for acceptance of the RADEXT WG re-charter. The consensus call will last until April 28, 2008. Please send email to the li= st stating whether you are in favor or opposed to the RADEXT WG re-charter proposal: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RF= C June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC --_000_456A5146F9319946A179B523B9FC91D60D9EE7109ENAEXMSGC114re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in favor of this proposal.

 

Mudit Goel

 

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Be= half Of Bernard_Aboba@hotmail.com
Sent: Monday, April 14, 2008 6:20 AM
To: radiusext@ops.ietf.org
Subject: Consensus Call on RADEXT WG re-charter

 

This is a consensus call for acceptance of the RADEXT WG re-charter.  = The

consensus call will last until April 28, 2008.  Please send email to the li= st

stating whether you are in favor or opposed to the RADEXT WG re-charter=

proposal:

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Description of Working Group:


The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage.

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
 

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC<= br> Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RF= C
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

--_000_456A5146F9319946A179B523B9FC91D60D9EE7109ENAEXMSGC114re_-- -- 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, 16 Apr 2008 16:21:29 +0000 From: Avi Lior To: "Bernard_Aboba@hotmail.com" , "radiusext@ops.ietf.org" Date: Wed, 16 Apr 2008 12:19:50 -0400 Subject: RE: Consensus Call on RADEXT WG re-charter Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMpXIFccirmMPQOO1YeKWg6NdLABN4KQg Message-ID: <8A8CFE8F89C38B41A749C19328C76D63038852B0B6@exchange02.bridgewatersys.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8A8CFE8F89C38B41A749C19328C76D63038852B0B6exchange02bri_" MIME-Version: 1.0 --_000_8A8CFE8F89C38B41A749C19328C76D63038852B0B6exchange02bri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a very interesting thing happening here with the notion of adding = a new transport to RADIUS: specifically TCP/TLS transport to RADIUS. In recent experiences in other SDOs people were concerned about the scalabi= lity of Diameter. Specifically, in the hot arena of Femto Cells and Diamet= er, people were wondering how a diameter server would maintain 100,000 plus= connections with the femtos. This without using multiple servers. So here we are thinking about perhaps introducing a UDP transport or someth= ing equivalent for the Diameter server -- at least for that first hop betwe= en the femto cell in your home and the operator's site. Perhaps the right approach for these protocols is to allow them to utilize = the correct transport for the job at hand. Having no choice is seemingly p= roblematic. Avi ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Bernard_Aboba@hotmail.com Sent: Monday, April 14, 2008 9:20 AM To: radiusext@ops.ietf.org Subject: Consensus Call on RADEXT WG re-charter This is a consensus call for acceptance of the RADEXT WG re-charter. The consensus call will last until April 28, 2008. Please send email to the li= st stating whether you are in favor or opposed to the RADEXT WG re-charter proposal: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RF= C June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC --_000_8A8CFE8F89C38B41A749C19328C76D63038852B0B6exchange02bri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There is a very interesting thing happening here with the notion o= f=20 adding a new transport to RADIUS: specifically TCP/TLS transport to=20 RADIUS. 
 
In=20 recent experiences in other SDOs people were concerned about the scalabilit= y of=20 Diameter.  Specifically, in the hot arena of Femto Cells and Diameter,= =20 people were wondering how a diameter server would maintain 100,000 plu= s=20 connections with the femtos.  This without using multiple=20 servers.
 
So=20 here we are thinking about perhaps introducing a UDP transport or something= =20 equivalent for the Diameter server -- at least for that first hop betw= een=20 the femto cell in your home and the operator's site.
 
Perhaps the right approach for these protocols is to allow th= em to=20 utilize the correct transport for the job at hand.  Having no choice i= s=20 seemingly problematic.
 
 Avi

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of=20 Bernard_Aboba@hotmail.com
Sent: Monday, April 14, 2008 9:20= =20 AM
To: radiusext@ops.ietf.org
Subject: Consensus Call= on=20 RADEXT WG re-charter

This is a consensus call for acceptance= =20 of the RADEXT WG re-charter.  The
consensus call will last until April&nbs= p;28,=20 2008.  Please send email to the list
stating whether you are in favor or oppo= sed to=20 the RADEXT WG re-charter
proposal:
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Description of Working Group:

The RADIUS Extensions Working Group will focus on ext= ensions=20 to the
RADIUS protocol required to define extensions to the=20 standard
attribute space as well as to address cryptographic=20 algorithm
agility and use over new secure transports. In addition, RAD= EXT=20 will
work on RADIUS Design Guidelines and define new attributes for=20
particular applications of authentication, authorization and=20
accounting such as NAS management and local area network (LAN) usage.= =20

In order to enable interoperation of heterogeneous=20 RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a=20 Diameter
compatibility section, outlining how interoperability=20 with
Diameter will be maintained.

Furthermore, to ensure backwa= rd=20 compatibility with existing RADIUS
implementations, as well as=20 compatibility between RADIUS and Diameter,
the following restrictions = are=20 imposed on extensions considered by the
RADEXT WG:

- All RADIUS= work=20 MUST be backward compatible with existing RADIUS
RFCs, including RFCs= =20 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and=20 5176.

- All RADIUS work MUST be compatible with equivalent facilit= ies=20 in
Diameter. Where possible, new attributes should be defined so=20 that
the same attribute can be used in both RADIUS and Diameter=20 without
translation. In other cases a translation considerations
se= ction=20 should be included in the specification.
 

Work=20 Items

The immediate goals of the RADEXT working group are to addre= ss=20 the
following issues:

- RADIUS design guidelines. This document= will=20 provide guidelines for
design of RADIUS attributes. It will specifical= ly=20 consider how
complex data types may be introduced in a robust manner,= =20 maintaining
backwards compatibility with existing RADIUS RFCs, across = all=20 the
classes of attributes: Standard, Vendor-Specific and=20 SDO-Specific.
In addition, it will review RADIUS data types and=20 associated
backwards compatibility issues.
 
- RADIUS Manag= ement=20 authorization. This document will define the
use of RADIUS for NAS=20 management over IP.

-RADIUS attribute space extension. The standa= rd=20 RADIUS attribute
space is currently being depleted. This document will= =20 provide
additional standard attribute space, while maintaining=20 backward
compatibility with existing attributes.

-RADIUS=20 Cryptographic Algorithm Agility. RADIUS has traditionally
relied on M= D5=20 for both per-packet integrity and authentication as well
as attribute= =20 confidentiality. Given the increasingly successful
attacks being mount= ed=20 against MD5, the ability to support
alternative algorithms is required= .=20 This work item will
include documentation of RADIUS crypto-agility=20 requirements,
as well as development of one or more Experimental RFCs= =20 providing
support for negotiation of alternative cryptographic=20 algorithms
to protect RADIUS.

- IEEE 802 attributes. New attrib= utes=20 have been proposed to
support IEEE 802 standards for wired and wireles= s=20 LANs. This
work item will support authentication, authorization=20 and
accounting attributes needed by IEEE 802 groups including
IEEE= =20 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. New s= ecure=20 transports for RADIUS will
be developed, including TCP/TLS (RADSEC) an= d=20 UDP/DTLS.

- Documentation of Status-Server usage. A=20 document
describing usage of the Status-Server facility will=20 be
developed.

Goals and Milestones:
Jun 2008 RADIUS Design=20 Guidelines submitted as a Best Current Practice RFC
Jun 2008 RADIUS=20 Management Authorization I-D submitted as a Proposed Standard RFC
Sep = 2008=20 RADIUS Crypto-agility Requirements submitted as an Informational RFC
S= ep=20 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec = 2008=20 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009= =20 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC= =20 (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
June 2009= =20 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS= =20 Cryptographic Algorithm Agility I-D submitted as an Experimental=20 RFC
--_000_8A8CFE8F89C38B41A749C19328C76D63038852B0B6exchange02bri_-- -- 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, 16 Apr 2008 12:53:15 +0000 From: "David B. Nelson" To: Subject: RE: RADEXT WG re-charter Date: Wed, 16 Apr 2008 08:52:02 -0400 Message-ID: <00a201c89fc0$aadb86f0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFAAAers8AAWnCbAAEQZ+DA= Joseph Salowey writes... > There are a few reasons why you would want to wrap keys separately from > other data. As you mentioned, the recommended algorithms for key wrap > may not be suitable for encrypting bulk data without special > consideration ... Yes, because in those cases you are *relying* on the randomness of the key material. > ... and some bulk data encryption algorithms may not be > recommended for key wrap without special consideration. That's the part I still don't understand. The only "consideration" I've heard so far is that "NIST hasn't blessed it", which is political and not technical. Of course, if you think that a critical goal of RADIUS Crypto-Agility is to facilitate creating FIPS certifiable products, then maybe this should be listed in the RADIUS Crypto-Agility Requirements draft. > Another reason is that you may want the entity that handles the keys > and their context to be different from the entity that handles the rest > of the attributes. Perhaps. You could provide that enforced "separation of concerns" by using a separate KEK for the keys and a DEK for the data. The algorithm and mode need not be different to provide the isolation. Since the key management and distribution, e.g. automated key management, is currently out of scope for RADIUS Crypto-Agility, that shouldn't present an impediment. > Neither of these reasons forces you to have encryption tied directly to > the key attribute. It is convenient since one is very often interested > in encrypting keys, but you can achieve the same thing with a generic > encryption attribute if you take care. OK. What care do we need to take? > You need to support multiple pieces of data encrypted with different > keys (key IDs, alg IDs, message boundaries, etc.) in the same message > and you need to make sure that the various supported encryption > algorithms are used correctly (type of cleartext, sufficient > randomization, integrity protection, etc.). If we determine that the algorithm and mode that do not depend upon a random payload, but are still strong when the payload happens to be random, what's the issue? > If you don't consider keys as part of the data you are wrapping for > crypto agility, I'm not sure you will end up with a result that is very > useful. Sure. We need to have a method that works for keys, too. I'm trying to figure out if there is a "one size fits all" algorithm and method (assuming a separate KEK), and if not, why not. So far the only impediment that I see remaining is the "it's not blessed by NIST" for that particular application, e.g. key wrap. BTW, thank you very much for a *technical* discussion of the issue. It's quite refreshing. :-) -- 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, 16 Apr 2008 08:21:20 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Romascanu, Dan \(Dan\)'" , "'Alan DeKok'" Cc: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 15:19:49 +0700 Message-ID: <007d01c89f9a$adb6d6c0$99e0787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcifkbETK6dfXn4BTn2TuxBbfSC6hgACLe3w Bernard Aboba scribbled on Wednesday, April 16, 2008 2:16 PM: > For transport items this basically means "uses RADIUS packet > formats defined in RFC 2865, 2866 and 5176" (although the > ports can be different). So what you're saying is that two nodes can be unable to communicate & still be "backward compatible"? -- 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, 16 Apr 2008 08:16:56 +0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" , "'Alan DeKok'" Cc: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 15:15:26 +0700 Message-ID: <007c01c89f9a$15d575f0$99e0787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: Acie1bYTHYV+lGqeRfSK7nUmuV4hmQAs0GFQAAEPh0AAAQFYwA== Romascanu, Dan (Dan) scribbled on Wednesday, April 16, 2008 1:46 PM: > Can you guys try to agree on a paragraph which explains what > 'backward compatibility' means in the context of this charter? The term is meaningless in the context of this charter & should be removed or at the very least _highly_ qualified. Saying (as the currently proposed charter does) that "All RADIUS work MUST be backward compatible with existing RADIUS RFCs" is just absurd. That said, the following paragraph would work, Think: - All documents produced MUST specify means of interoperation with legacy RADIUS implementations and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. > > It seems to me that this is the principal item of disagreement in > this debate. > > Dan > ... -- 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, 16 Apr 2008 08:12:24 +0000 Message-ID: <4805B3B6.9060108@nitros9.org> Date: Wed, 16 Apr 2008 10:07:18 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Bernard Aboba CC: "Romascanu, Dan (Dan)" , Glen Zorn , radiusext@ops.ietf.org Subject: Re: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > For transport items this basically means "uses RADIUS packet formats > defined in RFC 2865, 2866 and 5176" (although the ports can be different). Yes. 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, 16 Apr 2008 07:16:26 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_73941c2c-b0c9-42e7-b3e8-eb54b26d419b_" From: Bernard Aboba To: "Romascanu, Dan (Dan)" , Glen Zorn , Alan DeKok CC: Subject: RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 00:15:37 -0700 MIME-Version: 1.0 --_73941c2c-b0c9-42e7-b3e8-eb54b26d419b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For transport items this basically means "uses RADIUS packet formats define= d in RFC 2865, 2866 and 5176" (although the ports can be different). --_73941c2c-b0c9-42e7-b3e8-eb54b26d419b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For transport items this basically means "uses RADIUS packet formats define= d in RFC 2865, 2866 and 5176" (although the ports can be different).
= --_73941c2c-b0c9-42e7-b3e8-eb54b26d419b_-- -- 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, 16 Apr 2008 06:47:20 +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: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 08:46:19 +0200 Message-ID: Thread-Topic: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Thread-Index: Acie1bYTHYV+lGqeRfSK7nUmuV4hmQAs0GFQAAEPh0A= From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "Alan DeKok" Cc: Can you guys try to agree on a paragraph which explains what 'backward compatibility' means in the context of this charter?=20 It seems to me that this is the principal item of disagreement in this debate.=20 Dan =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn > Sent: Wednesday, April 16, 2008 9:37 AM > To: 'Alan DeKok' > Cc: radiusext@ops.ietf.org > Subject: Meaning of "backward compatible" WAS RE: Consensus=20 > Call on RADEXT WG re-charter >=20 > Alan DeKok scribbled on=20 > Tuesday, April 15, 2008 3:46 PM: >=20 > > Glen Zorn wrote: > >> OK, since RFC 2865 only defines RADIUS in terms of UDP, it=20 > must not=20 > >> be the authoritative reference for "RADIUS *at all*". =20 > What is? I'd=20 > >> like to read it... > >=20 > > The authoritative reference for RADIUS is this WG. If the=20 > consensus=20 > > is to add bells, whistles, or flying monkeys to RADIUS,=20 > then that is=20 > > our perogative. > >=20 > > The alternative is to worship at the holy shrine of the existing=20 > > RFC's, which were handed down from on high by the holy priests of=20 > > RADIUS. As mere mortals, we are incapable of changing holy=20 > writ, and=20 > > must confess that the RFC's are perfect. > >=20 > > I shall therefore submit a request to the RFC editor=20 > admitting that=20 > > RFC 5080 is blasphemy, as it points out > > *errors* in the original RFC's. > > It should therefore be withdrawn immediately, before the=20 > holy priests=20 > > of RADIUS burn me at the stake. >=20 > Could we just try to stay on topic, please? My assertion was=20 > that to claim "backward compatibility" between 2 protocols=20 > which can only communicate through a translating gateway is=20 > essentially meaningless. > That has nothing to do with "priests" or "holy writ", even=20 > less with the ludicrous claim that this WG is some kind of=20 > global help desk for RADIUS developers. Back to the subject=20 > at hand, you managed to define "backward compatibility" in a=20 > slightly different context a couple of months ago (see=20 > https://ops.ietf.org/lists/radiusext/2008/msg00000.html > for the complete message): "Everyone accepts that=20 > implementations have to be updated to handle new standards. =20 > One of the major efforts in RADIUS has been to maintain=20 > backwards compatibility with existing deployments. i.e. if a=20 > product doesn't implement the new standard, it can still=20 > communicate with products that do implement that standard." =20 > A RadSec implementation doesn't also listen on UDP 1812=20 > pretty obviously flunks that test (not that I think it's a=20 > particularly good one, but it's yours). If there is to be=20 > _any_ interoperability between RADIUS and RadSec, then the=20 > definition of the protocol gateway behavior is at least as,=20 > if not more, important than the standardization of RadSec. > Unfortunately, this doesn't seem to be reflected in the=20 > charter that everyone seems in such a hurry to rubberstamp;=20 > maybe because RadSec is by definition "backward compatible"? =20 >=20 > >=20 > > Alan DeKok. >=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: Wed, 16 Apr 2008 06:38:48 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: Subject: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 13:37:17 +0700 Message-ID: <007501c89f8c$57c0f380$99e0787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: Acie1bYTHYV+lGqeRfSK7nUmuV4hmQAs0GFQ Alan DeKok scribbled on Tuesday, April 15, 2008 3:46 PM: > Glen Zorn wrote: >> OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not >> be the authoritative reference for "RADIUS *at all*". What is? I'd >> like to read it... > > The authoritative reference for RADIUS is this WG. If the > consensus is to add bells, whistles, or flying monkeys to > RADIUS, then that is our perogative. > > The alternative is to worship at the holy shrine of the > existing RFC's, which were handed down from on high by the > holy priests of RADIUS. As mere mortals, we are incapable of > changing holy writ, and must confess that the RFC's are perfect. > > I shall therefore submit a request to the RFC editor > admitting that RFC 5080 is blasphemy, as it points out > *errors* in the original RFC's. > It should therefore be withdrawn immediately, before the holy > priests of RADIUS burn me at the stake. Could we just try to stay on topic, please? My assertion was that to claim "backward compatibility" between 2 protocols which can only communicate through a translating gateway is essentially meaningless. That has nothing to do with "priests" or "holy writ", even less with the ludicrous claim that this WG is some kind of global help desk for RADIUS developers. Back to the subject at hand, you managed to define "backward compatibility" in a slightly different context a couple of months ago (see https://ops.ietf.org/lists/radiusext/2008/msg00000.html for the complete message): "Everyone accepts that implementations have to be updated to handle new standards. One of the major efforts in RADIUS has been to maintain backwards compatibility with existing deployments. i.e. if a product doesn't implement the new standard, it can still communicate with products that do implement that standard." A RadSec implementation doesn't also listen on UDP 1812 pretty obviously flunks that test (not that I think it's a particularly good one, but it's yours). If there is to be _any_ interoperability between RADIUS and RadSec, then the definition of the protocol gateway behavior is at least as, if not more, important than the standardization of RadSec. Unfortunately, this doesn't seem to be reflected in the charter that everyone seems in such a hurry to rubberstamp; maybe because RadSec is by definition "backward compatible"? > > 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, 16 Apr 2008 05:42:45 +0000 From: "Glen Zorn" To: "'Matt Holdrege'" , "'Joseph Salowey \(jsalowey\)'" , "'Bernard Aboba'" , "'Alan DeKok'" Cc: "'radext mailing list'" Subject: RE: SNMP vs. RADIUS transport mappings Date: Wed, 16 Apr 2008 12:40:36 +0700 Message-ID: <006301c89f84$73c7c2f0$99e0787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYAAGg6B8AAA9cNQABhWwpA= owner-radiusext@ops.ietf.org <> scribbled on Wednesday, April 16, 2008 1:08 AM: > SNMP had the full support of the IAB and IESG who pushed many > years for the full development of the protocol. RADIUS has > been denigrated by a long list of IAB and IESG leadership as > something that never should have been allowed to happen and > should not have a place in any future IETF protocol > development. I don't know if it would be possible to get the > level of support needed to do what you are suggesting, but it > would have been nice to have done that work back in the 90's. > > But all that is IETF politics and future RADIUS development > shouldn't worry too much about past politics. In a perfect world that would be true; unfortunately, 'the song goes on'... ... -- 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, 16 Apr 2008 01:23:53 +0000 From: "Sanchez, Mauricio (ProCurve)" To: "Bernard_Aboba@hotmail.com" , "radiusext@ops.ietf.org" Date: Wed, 16 Apr 2008 01:21:45 +0000 Subject: RE: Consensus Call on RADEXT WG re-charter Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMok4qsMVgbLISSqLMqEx2GjNuAA4JRHw Message-ID: Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013B_01C89ED8.776DFAC0" MIME-Version: 1.0 ------=_NextPart_000_013B_01C89ED8.776DFAC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_013C_01C89ED8.776DFAC0" ------=_NextPart_001_013C_01C89ED8.776DFAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am in favor of this proposal. MS From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard_Aboba@hotmail.com Sent: Monday, April 14, 2008 6:20 AM To: radiusext@ops.ietf.org Subject: Consensus Call on RADEXT WG re-charter This is a consensus call for acceptance of the RADEXT WG re-charter. The consensus call will last until April 28, 2008. Please send email to the list stating whether you are in favor or opposed to the RADEXT WG re-charter proposal: ======================================================= Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC ------=_NextPart_001_013C_01C89ED8.776DFAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in favor of this proposal.

 

MS

 

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On = Behalf Of Bernard_Aboba@hotmail.com
Sent: Monday, April 14, 2008 6:20 AM
To: radiusext@ops.ietf.org
Subject: Consensus Call on RADEXT WG = re-charter

 

This is a consensus call for acceptance of the RADEXT WG = re-charter.  The

consensus call will last until April 28, 2008.  Please send email to the = list

stating whether you are in favor or opposed to the RADEXT WG = re-charter

proposal:

 

 

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Description of Working = Group:


The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage. =

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and = Diameter,
the following restrictions are imposed on extensions considered by = the
RADEXT WG:

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
 

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines = for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as = well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice = RFC
Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed = Standard RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an = Informational RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard = RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard = RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental = RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

------=_NextPart_001_013C_01C89ED8.776DFAC0-- ------=_NextPart_000_013B_01C89ED8.776DFAC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhB3lLeh2K9TSN0bRHs7 wmmDMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0xMTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAIC20 InJbjxHbFARQiJa3lZPqTCrVfV5vngYprhEGanLYRa9c6bf2tbkHdxBelAHWJaLSzZW6NF4K3fkq NjtRHaR16iUovo4pRS6hJvUywmKS38AK5V6iAMcYf1n57MF3WcG2ZVeI97IUd9cYB0G8dY+vGp77 WZNqiQC9vwkPTzwwggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDQxNTE2MDk1M1owIwYJ KoZIhvcNAQkEMRYEFG3VhAPSp1k57+nysszIE9cev5ptMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgOSKERT9u8rhMT0HtkIbDPqnQlsS4FPjbFWNwtHW0j319kpLQZMDFg4pMm0paVRk gP39/keUXrW/0t+aYvzoLNUZaN6ME/Jl8eeJamrXI+hBNzU/2k5DNMcTJPpziUVtWBjkHWVgSW0Z ualjKPRXGaLZusKHwSI20kCh6v2Ynk1FAAAAAAAA ------=_NextPart_000_013B_01C89ED8.776DFAC0-- -- 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, 15 Apr 2008 21:53:21 +0000 Message-ID: <480522A5.2080208@nitros9.org> Date: Tue, 15 Apr 2008 23:48:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" CC: radiusext@ops.ietf.org Subject: Re: RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joseph Salowey (jsalowey) wrote: > There are a few reasons why you would want to wrap keys separately from > other data. As you mentioned, the recommended algorithms for key wrap > may not be suitable for encrypting bulk data without special > consideration and some bulk data encryption algorithms may not be > recommended for key wrap without special consideration. Another reason > is that you may want the entity that handles the keys and their context > to be different from the entity that handles the rest of the attributes. i.e. distributing wireless keys to a NAS. For reasons outlined in RFC 3538, RadSec is likely not a good idea for NAS -> local AAA communications. DTLS is better for transport, but still may be difficult for some to implement. Encrypting only the keys is likely sufficient. 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: Tue, 15 Apr 2008 20:59:45 +0000 From: Mike McCauley To: "David B. Nelson" Subject: Re: Consensus Call on RADEXT WG re-charter Date: Wed, 16 Apr 2008 06:58:33 +1000 User-Agent: KMail/1.8.2 Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200804160658.34248.mikem@open.com.au> On Tuesday 15 April 2008 22:54, David B. Nelson wrote: > Matt Holdrege wrote: > > As far as backwards compatibility is concerned, I hope everyone realizes > > that RADIUS is an extremely well installed **SERVICE** and a completely > > new **SERVICE** would be a waste of everyone=92s time. People can scream > > and yell about having to twiddle bits in their servers and proxies but I > > don=92t care. It is the clients that you should really be concerned wit= h. > > Right. While I think the RADSEC folks indicate they have some client > implementations, my impression of the work is that its more useful > between the first-hop proxy and the home server. > > For the RADESC folks: Is there any reason that the first-hop proxy > couldn't terminate a RADIUS (RADIUS over UDP) session with the NAS and > originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream > proxies or home server? Thats a very common model which is permitted by the spec and supported by o= ur=20 implementation (at least), with the view of protecting the traffic while it= =20 traverses the internet but without requiring RadSec capable clients. Cheers. > > > > -- > 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: =2D-=20 Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server=20 anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,=20 Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,=20 TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- 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, 15 Apr 2008 20:07:40 +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: RADEXT WG re-charter Date: Tue, 15 Apr 2008 13:07:24 -0700 Message-ID: Thread-Topic: RADEXT WG re-charter Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFAAAers8AAWnCbA From: "Joseph Salowey (jsalowey)" To: "David B. Nelson" , , "Glen Zorn" Cc: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3504; t=1208289994; x=1209153994; c=relaxed/simple; s=sjdkim4002; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=rnyo5RQGguxc8LihqxMd1hh6c5boYtNtk7MTNty7Vsc=; b=DOVeoyPa1Bp+QmEbclY32V+WyiJGTlG/89J1aR/ro2P0RpseyhfgIz3Gw+ BBH1mCL3z8sgB52Su877D/kt1fYrgHcT0FCbA4QqxI9vE7i2L40/cT2PU7Ju YfZM6iEr09; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); There are a few reasons why you would want to wrap keys separately from other data. As you mentioned, the recommended algorithms for key wrap may not be suitable for encrypting bulk data without special consideration and some bulk data encryption algorithms may not be recommended for key wrap without special consideration. Another reason is that you may want the entity that handles the keys and their context to be different from the entity that handles the rest of the attributes. Neither of these reasons forces you to have encryption tied directly to the key attribute. It is convenient since one is very often interested in encrypting keys, but you can achieve the same thing with a generic encryption attribute if you take care. You need to support multiple pieces of data encrypted with different keys (key IDs, alg IDs, message boundaries, etc.) in the same message and you need to make sure that the various supported encryption algorithms are used correctly (type of cleartext, sufficient randomization, integrity protection, etc.). These things don't necessarily happen automatically or come for free.=20 If you don't consider keys as part of the data you are wrapping for crypto agility, I'm not sure you will end up with a result that is very useful. =20 Joe=20 > -----Original Message----- > From: David B. Nelson [mailto:dnelson@elbrysnetworks.com]=20 > Sent: Monday, April 14, 2008 10:29 AM > To: radiusext@ops.ietf.org; 'Glen Zorn' > Cc: Joseph Salowey (jsalowey); Bernard_Aboba@hotmail.com > Subject: RE: RADEXT WG re-charter >=20 > Glen Zorn writes... >=20 > > 'Frankly, my dear, I don't give a damn.'=20 >=20 > Cute... >=20 > > It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt=20 > > was posted ... for at least 3 years there have been at 2 (or more)=20 > > independent, interoperable implementations that were FIPS-certified. >=20 > Given that there are implementations of this key-wrap scheme,=20 > presumably using VSAs, it might be well to publish an=20 > Information RFC, describing the actual implementations, using=20 > those VSAs. >=20 > > But wait! Let's spend a little (lot) more time conjecturing about=20 > > another way, a way to solve "the general problem" (AKA "boiling the=20 > > ocean" if it's a proposal we don't care for). Well, gosh,=20 > no thanks,=20 > > but you guys go ahead & have fun! >=20 > RADEXT has a chartered work item to address crypto-agility. =20 > We have requirements for this wok, and we now have an ID=20 > capturing those requirements. We don't have a requirement to=20 > specifically address key-wrap, as a separate problem. My=20 > questions is whether RADEXT really needs to create two drafts=20 > to satisfy the crypto-agility work item, one for key-wrap and=20 > one for general purpose encrypted attributes. The fact that=20 > solutions, and drafts, exist to address key-wrap and=20 > encrypted attributes separately is a point in favor of=20 > retaining the separation. I'm just questioning whether=20 > that's a sufficient basis on which to decide that we need=20 > such separation of concerns. >=20 > If the consensus us of the WG is that we should proceed with=20 > separate documents for key-wrap and general crypto-agility,=20 > we can propose doing that in our revised charter. It would=20 > be nice, however, to have a reason beyond the existence of (4=20 > year old) drafts that are structured that way. >=20 >=20 >=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: Tue, 15 Apr 2008 18:08:27 +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: SNMP vs. RADIUS transport mappings Date: Tue, 15 Apr 2008 11:07:46 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181955@wv-mailsrv2.strixsystems.com> Thread-Topic: SNMP vs. RADIUS transport mappings Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYAAGg6B8AAA9cNQ From: "Matt Holdrege" To: "Joseph Salowey (jsalowey)" , "Bernard Aboba" , "Glen Zorn" , "Alan DeKok" Cc: "radext mailing list" SNMP had the full support of the IAB and IESG who pushed many years for the full development of the protocol. RADIUS has been denigrated by a long list of IAB and IESG leadership as something that never should have been allowed to happen and should not have a place in any future IETF protocol development. I don't know if it would be possible to get the level of support needed to do what you are suggesting, but it would have been nice to have done that work back in the 90's. But all that is IETF politics and future RADIUS development shouldn't worry too much about past politics. -Matt -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Joseph Salowey (jsalowey) Sent: Tuesday, April 15, 2008 7:46 PM To: Bernard Aboba; Glen Zorn; Alan DeKok Cc: radext mailing list Subject: RE: SNMP vs. RADIUS transport mappings SNMPv3 made the effort to define an architecture that created abstract interfaces between modules such as security and transport as is defined in the architecture documents you cite. This makes it possible to implement new transport and security mechanisms within the SNMPv3 architecture (although the architecture has to be extended somewhat to accommodate a transport security mechanism). RADIUS has no such formal modular architecture. I suppose that one could be retro-fitted, but it hasn't been done yet. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, April 14, 2008 10:26 PM > To: 'Glen Zorn'; 'Alan DeKok' > Cc: 'radext mailing list' > Subject: SNMP vs. RADIUS transport mappings >=20 > >UDP transport is forever enshrined in RFC 2865, however;=20 > maybe that's a=20 > >bad thing, but it's true nonetheless. >=20 > How is this different from say, SNMP?=20 >=20 > The original transport mappings for SNMP (RFC 1089, 1906)=20 > were all datagram transports. >=20 > The logic for SNMP over UDP was quite well enshrined. For=20 > example, see the following discussion, which has some=20 > parallels with RFC 2865 Section 2.4: > http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm >=20 > Yet, RFC 3430 defined SNMP over TCP: > http://www.ietf.org/rfc/rfc3430.txt >=20 > Normative references included the following: >=20 > Transport Mappings for SNMP: > http://www.ietf.org/rfc/rfc3417.txt > SNMP applications: > http://www.ietf.org/rfc/rfc3413.txt > An Architecture for Describing SNMP Management Frameworks: > http://www.ietf.org/rfc/rfc3411.txt >=20 >=20 >=20 >=20 >=20 > =20 >=20 >=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: -- 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, 15 Apr 2008 17:46:36 +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: SNMP vs. RADIUS transport mappings Date: Tue, 15 Apr 2008 10:45:39 -0700 Message-ID: Thread-Topic: SNMP vs. RADIUS transport mappings Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYAAGg6B8A== From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , "Glen Zorn" , "Alan DeKok" Cc: "radext mailing list" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1987; t=1208281492; x=1209145492; 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=20SNMP=20vs.=20RADIUS=20transport=20mappi ngs |Sender:=20; bh=52m28GEzc157u4LntfuiVyVb/Y/0j2Ckw8PJYHJFNYo=; b=A5VLVnYDfGTMOwWenOtZ5aDGiBYNyucmYQoNalZNwtZmX5JTIRMSxT9rwc R3a5A6Ipyue9YmAWjNlHrXRNA+6I4eOHy6diTJF9DhXjgaTYUaGDMiTp6D/X n2ToNIQ3IlQkN/VHS7enojOQtKJwApbmytXHeT7VIV+iCoqsIR4ds=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); SNMPv3 made the effort to define an architecture that created abstract interfaces between modules such as security and transport as is defined in the architecture documents you cite. This makes it possible to implement new transport and security mechanisms within the SNMPv3 architecture (although the architecture has to be extended somewhat to accommodate a transport security mechanism). RADIUS has no such formal modular architecture. I suppose that one could be retro-fitted, but it hasn't been done yet. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, April 14, 2008 10:26 PM > To: 'Glen Zorn'; 'Alan DeKok' > Cc: 'radext mailing list' > Subject: SNMP vs. RADIUS transport mappings >=20 > >UDP transport is forever enshrined in RFC 2865, however;=20 > maybe that's a=20 > >bad thing, but it's true nonetheless. >=20 > How is this different from say, SNMP?=20 >=20 > The original transport mappings for SNMP (RFC 1089, 1906)=20 > were all datagram transports. >=20 > The logic for SNMP over UDP was quite well enshrined. For=20 > example, see the following discussion, which has some=20 > parallels with RFC 2865 Section 2.4: > http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm >=20 > Yet, RFC 3430 defined SNMP over TCP: > http://www.ietf.org/rfc/rfc3430.txt >=20 > Normative references included the following: >=20 > Transport Mappings for SNMP: > http://www.ietf.org/rfc/rfc3417.txt > SNMP applications: > http://www.ietf.org/rfc/rfc3413.txt > An Architecture for Describing SNMP Management Frameworks: > http://www.ietf.org/rfc/rfc3411.txt >=20 >=20 >=20 >=20 >=20 > =20 >=20 >=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: Tue, 15 Apr 2008 13:07:20 +0000 From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 15:06:22 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: "David B. Nelson" MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2914078.NQhsPztXlm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804151506.26463.stefan.winter@restena.lu> --nextPart2914078.NQhsPztXlm Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Right. While I think the RADSEC folks indicate they have some client > implementations, my impression of the work is that its more useful > between the first-hop proxy and the home server. > > For the RADESC folks: Is there any reason that the first-hop proxy > couldn't terminate a RADIUS (RADIUS over UDP) session with the NAS and > originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream > proxies or home server? That's perfectly possible. In fact, we had planned to deploy it exactly for= =20 the server-to-server use case.=20 It just happened that the use case of "APs in weird environments" *also*=20 showed up, and there was additional merit in having client gear that speaks= =20 RadSec itself. There is nothing that stops one from having RADIUS client gear and a RadSec= =20 server behind because the conversion is lossless. This is what happens for my own country deployment in the Luxembourg TLD:=20 upstream connection to the European root is via RadSec, while the connected= =20 institutions use plain RADIUS to talk to the TLD server. 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 --nextPart2914078.NQhsPztXlm 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) iD8DBQBIBKhS+jm90f8eFWYRAqDTAJ0UbRW9C7lJhifJrKgNkBTjA5kb0gCfYGia JVz4HAdqLzS5QAacrwQpuFk= =RGMV -----END PGP SIGNATURE----- --nextPart2914078.NQhsPztXlm-- -- 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, 15 Apr 2008 12:55:41 +0000 Message-ID: <4804A580.1060104@elbrysnetworks.com> Date: Tue, 15 Apr 2008 08:54:24 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Matt Holdrege wrote: > As far as backwards compatibility is concerned, I hope everyone realizes > that RADIUS is an extremely well installed **SERVICE** and a completely > new **SERVICE** would be a waste of everyone’s time. People can scream > and yell about having to twiddle bits in their servers and proxies but I > don’t care. It is the clients that you should really be concerned with. Right. While I think the RADSEC folks indicate they have some client implementations, my impression of the work is that its more useful between the first-hop proxy and the home server. For the RADESC folks: Is there any reason that the first-hop proxy couldn't terminate a RADIUS (RADIUS over UDP) session with the NAS and originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream proxies or home server? -- 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, 15 Apr 2008 10:31:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89EE3.BA9F6E73" Subject: RE: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 03:30:28 -0700 Message-ID: <400A74A604718E46BC9EE95677BAFF31181919@wv-mailsrv2.strixsystems.com> Thread-Topic: Consensus Call on RADEXT WG re-charter Thread-Index: AcieMvy5gK3cLxReSdeE79BoIG25qwAryLSQ From: "Matt Holdrege" To: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C89EE3.BA9F6E73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm in favor of adding improved functionality to RADIUS. What that actually means appears to be of considerable debate. =20 As far as backwards compatibility is concerned, I hope everyone realizes that RADIUS is an extremely well installed *SERVICE* and a completely new *SERVICE* would be a waste of everyone's time. People can scream and yell about having to twiddle bits in their servers and proxies but I don't care. It is the clients that you should really be concerned with. =20 -Matt =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard_Aboba@hotmail.com Sent: Monday, April 14, 2008 3:20 PM To: radiusext@ops.ietf.org Subject: Consensus Call on RADEXT WG re-charter =20 This is a consensus call for acceptance of the RADEXT WG re-charter. The consensus call will last until April 28, 2008. Please send email to the list=20 stating whether you are in favor or opposed to the RADEXT WG re-charter proposal:=20 =20 =20 ------_=_NextPart_001_01C89EE3.BA9F6E73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m in favor of adding improved functionality to = RADIUS. What that actually means appears to be of considerable = debate.

 

As far as backwards compatibility is concerned, I hope = everyone realizes that RADIUS is an extremely well installed *SERVICE* and = a completely new *SERVICE* would be a waste of everyone’s = time. People can scream and yell about having to twiddle bits in their servers = and proxies but I don’t care. It is the clients that you should really = be concerned with.

 

-Matt

 

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On = Behalf Of Bernard_Aboba@hotmail.com
Sent: Monday, April 14, 2008 3:20 PM
To: radiusext@ops.ietf.org
Subject: Consensus Call on RADEXT WG = re-charter

 

This is a consensus call for acceptance of the RADEXT WG = re-charter.  The

consensus call will last until April 28, 2008.  Please send email to the = list

stating whether you are in favor or opposed to the RADEXT WG = re-charter

proposal:

 

 

------_=_NextPart_001_01C89EE3.BA9F6E73-- -- 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, 15 Apr 2008 08:50:35 +0000 Message-ID: <48046B45.20008@deployingradius.com> Date: Tue, 15 Apr 2008 10:45:57 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not be > the authoritative reference for "RADIUS *at all*". What is? I'd like > to read it... The authoritative reference for RADIUS is this WG. If the consensus is to add bells, whistles, or flying monkeys to RADIUS, then that is our perogative. The alternative is to worship at the holy shrine of the existing RFC's, which were handed down from on high by the holy priests of RADIUS. As mere mortals, we are incapable of changing holy writ, and must confess that the RFC's are perfect. I shall therefore submit a request to the RFC editor admitting that RFC 5080 is blasphemy, as it points out *errors* in the original RFC's. It should therefore be withdrawn immediately, before the holy priests of RADIUS burn me at the stake. 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: Tue, 15 Apr 2008 08:44:13 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" , radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 10:43:02 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5508601.2IVmT3lAKA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804151043.06858.stefan.winter@restena.lu> --nextPart5508601.2IVmT3lAKA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not be > the authoritative reference for "RADIUS *at all*". What is? I'd like > to read it... Okay, point taken. Since there's no source for RADIUS without entangled UDP= =20 transport, the RadSec I-D should have a section that states which parts of= =20 2865 are irrelevant when using a TCP transport. I.e. the draft should defin= e=20 the subset that matches the fuzzy expression of "RADIUS *at all*". I'll go through 2865 and list the spots. On a side note, 2865 has other hard-wired assumptions that aren't incredibl= y=20 valid today. Are we going to split hairs on every one of them? That would=20 mean making an update to 2865 though. Take for example 2. Operation [...] If the client is valid, the RADIUS server consults a database of user= s=20 to find the user whose name matches the request. The user entry in the=20 database contains a list of requirements which must be met to allow access= =20 for the user. This always includes verification of the password, but can also specify the client(s) or port(s) to which the user is allowed access. Enter EAP-TLS. Where's the database? What password?=20 I somehow wonder why the introduction of EAP-TLS went by silently without a= n=20 outcry that 2865 is too narrowly specified to allow this, by being hardwire= d=20 to a specific set of auth backends. Back then, an RFC updated 2865 for EAP,= =20 and that was it. The fuss argumentation would be and could have been in a=20 similar direction like the one we have here. It's a matter of personal liki= ng=20 or disliking a specific update I guess. 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 --nextPart5508601.2IVmT3lAKA 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) iD8DBQBIBGqa+jm90f8eFWYRArV6AJ9BM7YqTw7gSQbSr0skXVDLYAPI8QCgh64u 6NeQzFhZL/NS34TY0kT8254= =qANE -----END PGP SIGNATURE----- --nextPart5508601.2IVmT3lAKA-- -- 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, 15 Apr 2008 08:16:50 +0000 From: "Glen Zorn" To: "'Stefan Winter'" Cc: Subject: RE: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 15:15:06 +0700 Message-ID: <004001c89ed0$d8b0f100$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Index: AcievhQ0g2LKyBc2QjOnpd3eYXax3gAEgoJQ Stefan Winter scribbled on Tuesday, April 15, 2008 1:01 PM: ... > That makes it *different from RADIUS over UDP*, but not > substantially different from RADIUS *at all*. OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not be the authoritative reference for "RADIUS *at all*". What is? I'd like to read it... ... -- 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, 15 Apr 2008 07:59:36 +0000 From: "Glen Zorn" To: "'Stefan Winter'" Cc: Subject: RE: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 14:58:15 +0700 Message-ID: <003d01c89ece$7e11da90$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: Acievu7z/CgfZ8eaQwe9nPJgrt0D1wADlDUQ Stefan Winter scribbled on Tuesday, April 15, 2008 1:07 PM: > Hi, >=20 >> This is what you said: "...a RadSec to RADIUS gateway involves >> terminating TCP, TLS, and forwarding the contents to RADIUS. If this >> isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy >> isn't doing HTTP." A Diameter to RADIUS gateway involves terminating >> TCP (or SCTP), TLS, and forwarding the contents to RADIUS. >=20 > With the devil being in the detail: With RadSec to RADIUS, the > incoming packet is already a RADIUS packet as soon as it is decoded > from the TLS tunnel. There is no translation of the content. > With Diameter to RADIUS, non-trivial translations need to be > done, some of which can't even be done at all right now > (Accepts >4096 bytes payload, AVPs with >253 bytes). We have > yet to see a Diameter translation agent that can do bijective > translations from one to another and back again (which I > personally see as the holy grail of compatibility). I doubt we > will ever. With RadSec to RADIUS, this is a triviality. I don't know how we got started down this path of arguing about the complexity of building protocol gateways; my point is that if the only way for two protocols to interoperate is through a gateway, those protocols _are not_ compatible except in the most trivial of senses, like ATM & Ethernet or IPv4 & v6 or RADIUS and RadSec. Therefore, stop claiming backward compatibility if for no other reason that it's embarrassing to associated with such a nonsensical claim. >=20 > Greetings, >=20 > Stefan Winter >=20 >> If you really think >> that this is different from your HTTPS->HTTP example, perhaps it's >> because you are conveniently ignoring the fact that HTTP is only >> defined over TCP. However, one could just as easily argue that HTTP >> !=3D HTTPS, given the need for different port numbers... >>=20 >>>> I don't think that I said anything about good or evil :-), but you >>>> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & >>>> that's not a problem. The problem would arise if someone claimed >>>> that it was because, 'Well, you can build a gateway'. >>>=20 >>> The protocols being transported on IPv4 can also be transported on >>> IPv6. >>=20 >> I really don't know how that is relevant. Dropping down a layer or >> 2, the same protocols can be carried by both Ethernet & ATM. Are you >> going to claim that they are somehow compatible (backward, forward >> or upside-down)?=20 >>=20 >>> Similarly, UDP transport + RADIUS application protocol is... RADIUS. >>> TCP transport + RADIUS application protocol is... RADIUS. >>=20 >> I know that you have read RFC 2865 (probably more often than I), so >> you know that there is no such thing as a standard "RADIUS >> application protocol", defined w/o regard for the underlying >> transport.=20 >>=20 >>> The only way to call RadSec something other than RADIUS is if you >>> say that FTP over IPv6 is not FTP. After all, FTP was for IPv4, >>=20 >> I can't find any mention of IPv4 in RFC 959; it does mention TCP, >> however. Would FTPoUDP also be FTP? How would FTP & FTPoUDP >> interoperate? These questions seem much more to the point, I think. >>=20 >>> and IPv6 is a new-fangled transport... so FTP over >>> IPv6 is not FTP... it's "magic". >>=20 >> One more time: the version of IP being used is transparent & >> therefore irrelevant to FTP. UDP transport is forever enshrined in >> RFC 2865, however; maybe that's a bad thing, but it's true >> nonetheless.=20 >>=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: >>=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: >=20 >=20 >=20 > -- > Stefan WINTER >=20 > Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education > Nationale et de la Recherche Ingenieur Forschung & Entwicklung >=20 > 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 422473 -- 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, 15 Apr 2008 07:48:57 +0000 From: "Glen Zorn" To: "'Stefan Winter'" , Subject: RE: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 14:47:24 +0700 Message-ID: <003501c89ecc$f9fa5a30$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Thread-Index: AcievhQ0g2LKyBc2QjOnpd3eYXax3gADiF8w Stefan Winter scribbled on Tuesday, April 15, 2008 1:01 PM: > Hi, >=20 >> First, the WG would have to _define_ RADIUS "the application >> protocol", since it doesn't exist w/o reference to the underlying >> transport. Maybe you have your own reasons for not wanting to change >> the name, but I do wish that this charade of claiming "backward >> compatibility" would come to an end. Even the creators of RADSEC >> have conceded that it's not RADIUS, why can't you? >=20 > Well, in case you are referring to me in IETF-71, I admitted > that there are non-trivial operational differences between the > two transports, and that the characteristics of a stateful > transport need to taken into account properly. > That makes it *different from RADIUS over UDP*, but not > substantially different from RADIUS *at all*.=20 OK, one more time: you are making a distinction that doesn't exist.=20 > Even you > conceded to saying that the innermost PDU still remains as it > is, so if nothing else, there is a core of RADIUS embedded. No, there is something that has yet to be defined embedded because RADIUS simply doesn't exist over a non-UDP transport. > And I would be surprised if you don't see yourself that > backwards compatibility is considerably easier if this PDU can > be repackaged into a new transport without changing it (except > the changes that any RADIUS apcket undergoes anyway on a > RADIUS proxy, re-signing with its own shared secret). >=20 > In general, I see this discussion "is it different or not?" as > rather pointless in the real world. Whatever one's perceived > opinion or perceived outcome is, it doesn't change anything in the > protocol itself.=20 >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER >=20 > Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education > Nationale et de la Recherche Ingenieur Forschung & Entwicklung >=20 > 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 422473 -- 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, 15 Apr 2008 07:24:11 +0000 From: Mike McCauley To: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 17:23:19 +1000 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804151723.19576.mikem@open.com.au> > This is a consensus call for acceptance of the RADEXT WG re-charter. The > consensus call will last until April 28, 2008. Please send email to the > list stating whether you are in favor or opposed to the RADEXT WG > re-charter proposal: In favour. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 -- 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, 15 Apr 2008 07:00:23 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'radext mailing list'" , "'Alan DeKok'" Subject: RE: SNMP vs. RADIUS transport mappings Date: Tue, 15 Apr 2008 13:58:38 +0700 Message-ID: <002001c89ec6$2a0c6df0$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYAAAx2MsA== owner-radiusext@ops.ietf.org <> scribbled on Tuesday, April 15, 2008 12:26 PM: >> UDP transport is forever enshrined in RFC 2865, however; maybe >> that's a bad thing, but it's true nonetheless. > > How is this different from say, SNMP? Here is the difference: RFC 1067, section 3.2.4 paragraph 2 says "Consistent with the goal of minimizing complexity of the management agent, the exchange of SNMP messages requires only an unreliable datagram service, and every message is entirely and independently represented by a single transport datagram. While this document specifies the exchange of messages via the UDP protocol [8], the mechanisms of the SNMP are generally suitable for use with a wide variety of transport services." It would appear to me that SNMP was designed _from the beginning_ with a variety of transports in mind; the fact that all of the transports defined for the next 14 years or so were connectionless just says that the original choice was a good one. Leaving aside the apologetics in section 2.4 of RFC 2865, contrast the above quotation with section 3, paragraph 1 of that document: "Exactly one RADIUS packet is encapsulated in the UDP Data field [4], where the UDP Destination Port field indicates 1812 (decimal)." Where is the wiggle room, the opening for a flexible transport mapping in that statement? There is none, the statement is flat, inflexible and quite specific. > > The original transport mappings for SNMP (RFC 1089, 1906) were all > datagram transports. > > The logic for SNMP over UDP was quite well enshrined. For > example, see the following discussion, which has some > parallels with RFC 2865 Section 2.4: > http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm > > Yet, RFC 3430 defined SNMP over TCP: > http://www.ietf.org/rfc/rfc3430.txt > > Normative references included the following: > > Transport Mappings for SNMP: > http://www.ietf.org/rfc/rfc3417.txt > SNMP applications: > http://www.ietf.org/rfc/rfc3413.txt > An Architecture for Describing SNMP Management Frameworks: > http://www.ietf.org/rfc/rfc3411.txt > > > > > > > > > > > -- > 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: Tue, 15 Apr 2008 06:08:05 +0000 From: Stefan Winter Organization: Fondation RESTENA To: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 08:07:30 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3075395.GtWnT0v3Ms"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804150807.31206.stefan.winter@restena.lu> --nextPart3075395.GtWnT0v3Ms Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > This is a consensus call for acceptance of the RADEXT WG re-charter. The > consensus call will last until April 28, 2008. Please send email to the > list stating whether you are in favor or opposed to the RADEXT WG > re-charter proposal: In favour. 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 --nextPart3075395.GtWnT0v3Ms 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) iD8DBQBIBEYj+jm90f8eFWYRApvtAJ9D9nNJgdDTRZ70fcF4slhCEjzJfACggPZn VarwXR4w004UfqChnMWf0f4= =ECFg -----END PGP SIGNATURE----- --nextPart3075395.GtWnT0v3Ms-- -- 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, 15 Apr 2008 06:07:42 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" , radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 08:06:52 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3044730.cxfaSqzMlr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804150806.52923.stefan.winter@restena.lu> --nextPart3044730.cxfaSqzMlr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > This is what you said: "...a RadSec to RADIUS gateway involves > terminating TCP, TLS, and forwarding the contents to RADIUS. If this > isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't > doing HTTP." A Diameter to RADIUS gateway involves terminating TCP (or > SCTP), TLS, and forwarding the contents to RADIUS. With the devil being in the detail: With RadSec to RADIUS, the incoming pac= ket=20 is already a RADIUS packet as soon as it is decoded from the TLS tunnel.=20 There is no translation of the content. With Diameter to RADIUS, non-trivial translations need to be done, some of= =20 which can't even be done at all right now (Accepts >4096 bytes payload, AVP= s=20 with >253 bytes). We have yet to see a Diameter translation agent that can = do=20 bijective translations from one to another and back again (which I personal= ly=20 see as the holy grail of compatibility). I doubt we will ever. With RadSec = to=20 RADIUS, this is a triviality. Greetings, Stefan Winter > If you really think=20 > that this is different from your HTTPS->HTTP example, perhaps it's > because you are conveniently ignoring the fact that HTTP is only defined > over TCP. However, one could just as easily argue that HTTP !=3D HTTPS, > given the need for different port numbers... > > >> I don't think that I said anything about good or evil :-), but you > >> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & > >> that's not a problem. The problem would arise if someone claimed > >> that it was because, 'Well, you can build a gateway'. > > > > The protocols being transported on IPv4 can also be > > transported on IPv6. > > I really don't know how that is relevant. Dropping down a layer or 2, > the same protocols can be carried by both Ethernet & ATM. Are you going > to claim that they are somehow compatible (backward, forward or > upside-down)? > > > Similarly, UDP transport + RADIUS application > > protocol is... RADIUS. TCP transport + RADIUS application protocol > > is... RADIUS. > > I know that you have read RFC 2865 (probably more often than I), so you > know that there is no such thing as a standard "RADIUS application > protocol", defined w/o regard for the underlying transport. > > > The only way to call RadSec something other than RADIUS is > > if you say that FTP over IPv6 is not FTP. After all, FTP was > > for IPv4, > > I can't find any mention of IPv4 in RFC 959; it does mention TCP, > however. Would FTPoUDP also be FTP? How would FTP & FTPoUDP > interoperate? These questions seem much more to the point, I think. > > > and IPv6 is a new-fangled transport... so FTP over > > IPv6 is not FTP... it's "magic". > > One more time: the version of IP being used is transparent & therefore > irrelevant to FTP. UDP transport is forever enshrined in RFC 2865, > however; maybe that's a bad thing, but it's true nonetheless. > > > 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: > > -- > 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: =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 --nextPart3044730.cxfaSqzMlr 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) iD8DBQBIBEX8+jm90f8eFWYRAiRWAJ4tx5u20QrUiX8Gu25TC66V+KP1GQCeOWd8 VE3clo7O85Ce2I4ozl3eaEg= =bxCQ -----END PGP SIGNATURE----- --nextPart3044730.cxfaSqzMlr-- -- 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, 15 Apr 2008 06:01:49 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn" , radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Date: Tue, 15 Apr 2008 08:00:48 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2806951.UGRgC5AscT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804150800.53961.stefan.winter@restena.lu> --nextPart2806951.UGRgC5AscT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > First, the WG would have to _define_ RADIUS "the application protocol", > since it doesn't exist w/o reference to the underlying transport. Maybe > you have your own reasons for not wanting to change the name, but I do > wish that this charade of claiming "backward compatibility" would come > to an end. Even the creators of RADSEC have conceded that it's not > RADIUS, why can't you? Well, in case you are referring to me in IETF-71, I admitted that there are= =20 non-trivial operational differences between the two transports, and that th= e=20 characteristics of a stateful transport need to taken into account properly= =2E=20 That makes it *different from RADIUS over UDP*, but not substantially=20 different from RADIUS *at all*. Even you conceded to saying that the=20 innermost PDU still remains as it is, so if nothing else, there is a core o= f=20 RADIUS embedded. And I would be surprised if you don't see yourself that=20 backwards compatibility is considerably easier if this PDU can be repackage= d=20 into a new transport without changing it (except the changes that any RADIU= S=20 apcket undergoes anyway on a RADIUS proxy, re-signing with its own shared=20 secret). In general, I see this discussion "is it different or not?" as rather=20 pointless in the real world. Whatever one's perceived opinion or perceived= =20 outcome is, it doesn't change anything in the protocol itself. 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 --nextPart2806951.UGRgC5AscT 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) iD8DBQBIBESV+jm90f8eFWYRAv1KAJ0Wb+dFkige3SHBWJaG9EpxoBzNDQCfTwnz mHV2Nzdn3LQh+/L8EgEjLJY= =Fqpw -----END PGP SIGNATURE----- --nextPart2806951.UGRgC5AscT-- -- 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, 15 Apr 2008 05:26:51 +0000 Message-ID: From: "Bernard Aboba" To: "'Glen Zorn'" , "'Alan DeKok'" Cc: "'radext mailing list'" Subject: SNMP vs. RADIUS transport mappings Date: Mon, 14 Apr 2008 22:25:30 -0700 Message-ID: <000901c89eb9$1ee14fc0$5ca3ef40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQAAcJLYA= Content-Language: en-us >UDP transport is forever enshrined in RFC 2865, >however; maybe that's a bad thing, but it's true nonetheless. How is this different from say, SNMP? The original transport mappings for SNMP (RFC 1089, 1906) were all datagram transports. The logic for SNMP over UDP was quite well enshrined. For example, see the following discussion, which has some parallels with RFC 2865 Section 2.4: http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm Yet, RFC 3430 defined SNMP over TCP: http://www.ietf.org/rfc/rfc3430.txt Normative references included the following: Transport Mappings for SNMP: http://www.ietf.org/rfc/rfc3417.txt SNMP applications: http://www.ietf.org/rfc/rfc3413.txt An Architecture for Describing SNMP Management Frameworks: http://www.ietf.org/rfc/rfc3411.txt -- 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, 15 Apr 2008 02:48:56 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 19:47:27 -0700 Message-ID: <001601c89ea3$12f2f7b0$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Index: AcieYdv/Dve1K2oWRxuAKjN8MK5bawAAC1bQAA//hYA= owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 12:17 PM: ... > > However, if the WG decides that RADIUS (the application > protocol) can be transport-agnostic, I see no reason to get hung up > on "naming rights". First, the WG would have to _define_ RADIUS "the application protocol", since it doesn't exist w/o reference to the underlying transport. Maybe you have your own reasons for not wanting to change the name, but I do wish that this charade of claiming "backward compatibility" would come to an end. Even the creators of RADSEC have conceded that it's not RADIUS, why can't 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: -- 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, 15 Apr 2008 02:33:03 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'radext mailing list'" Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 19:30:45 -0700 Message-ID: <001501c89ea0$bdf89500$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Index: AcieYdo1mUVutwBWQMye45AmNLti0gAOM5SQ owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 11:50 AM: > Glen Zorn wrote: > ... >>> If this isn't RADIUS, then by the same standards, any HTTPS to HTTP >>> proxy isn't doing HTTP. >> >> Hmm. By that standard, it would seem that Diameter is RADIUS, too... > > No. I didn't mention an HTTPS to FTP proxy as being HTTP. This is what you said: "...a RadSec to RADIUS gateway involves terminating TCP, TLS, and forwarding the contents to RADIUS. If this isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't doing HTTP." A Diameter to RADIUS gateway involves terminating TCP (or SCTP), TLS, and forwarding the contents to RADIUS. If you really think that this is different from your HTTPS->HTTP example, perhaps it's because you are conveniently ignoring the fact that HTTP is only defined over TCP. However, one could just as easily argue that HTTP != HTTPS, given the need for different port numbers... > >> I don't think that I said anything about good or evil :-), but you >> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & >> that's not a problem. The problem would arise if someone claimed >> that it was because, 'Well, you can build a gateway'. > > The protocols being transported on IPv4 can also be > transported on IPv6. I really don't know how that is relevant. Dropping down a layer or 2, the same protocols can be carried by both Ethernet & ATM. Are you going to claim that they are somehow compatible (backward, forward or upside-down)? > Similarly, UDP transport + RADIUS application > protocol is... RADIUS. TCP transport + RADIUS application protocol > is... RADIUS. I know that you have read RFC 2865 (probably more often than I), so you know that there is no such thing as a standard "RADIUS application protocol", defined w/o regard for the underlying transport. > > The only way to call RadSec something other than RADIUS is > if you say that FTP over IPv6 is not FTP. After all, FTP was > for IPv4, I can't find any mention of IPv4 in RFC 959; it does mention TCP, however. Would FTPoUDP also be FTP? How would FTP & FTPoUDP interoperate? These questions seem much more to the point, I think. > and IPv6 is a new-fangled transport... so FTP over > IPv6 is not FTP... it's "magic". One more time: the version of IP being used is transparent & therefore irrelevant to FTP. UDP transport is forever enshrined in RFC 2865, however; maybe that's a bad thing, but it's true nonetheless. > > 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: -- 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, 14 Apr 2008 19:20:46 +0000 From: "David B. Nelson" To: Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 15:17:14 -0400 Organization: Elbrys Networks, Inc. Message-ID: <01c201c89e64$259ca440$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcieYdv/Dve1K2oWRxuAKjN8MK5bawAAC1bQ Alan DeKok writes... > The protocols being transported on IPv4 can also be transported on > IPv6. Similarly, UDP transport + RADIUS application protocol is... > RADIUS. TCP transport + RADIUS application protocol is... RADIUS. I can see both sides of this argument. It's a common and desirable practice that application layer protocols are designed to be transport-agnostic. Some are; some aren't. In the case of RADIUS, the original task was to document RADIUS pretty much "as implemented" by Livingston Enterprises, Merit Networks, and a few others. Use of the UDP transport got "hard-wired" into the RFC. Maybe UDP is "crucial" to RADIUS being RADIUS, maybe it's an artifact. > The only way to call RadSec something other than RADIUS is if you say > that FTP over IPv6 is not FTP. Well, FTP runs over TCP. The similar thing that runs over UDP is called TFTP. Maybe that example doesn't make your point as well you'd have liked. There may be good reasons to "hard-wire" an application layer protocol to a particular transport layer. There are also cases when that "hard-wiring" happens as a matter of default, convenience, or lack of explicit consideration, rather than as a matter of design or architecture. I think we could argue ad infinitum into which category we should slot RFC 2865 RADIUS. :-) However, if the WG decides that RADIUS (the application protocol) can be transport-agnostic, I see no reason to get hung up on "naming rights". -- 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, 14 Apr 2008 18:56:19 +0000 Message-ID: <4803A74D.1000708@nitros9.org> Date: Mon, 14 Apr 2008 20:49:49 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Glen Zorn CC: 'radext mailing list' Subject: Re: Consensus Call on RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: ... >> If this isn't RADIUS, then by the same standards, any HTTPS to HTTP >> proxy isn't doing HTTP. > > Hmm. By that standard, it would seem that Diameter is RADIUS, too... No. I didn't mention an HTTPS to FTP proxy as being HTTP. > I don't think that I said anything about good or evil :-), but you make > my point for me: IPv6 is hardly "backward compatible" w/IPv4 & that's > not a problem. The problem would arise if someone claimed that it was > because, 'Well, you can build a gateway'. The protocols being transported on IPv4 can also be transported on IPv6. Similarly, UDP transport + RADIUS application protocol is... RADIUS. TCP transport + RADIUS application protocol is... RADIUS. The only way to call RadSec something other than RADIUS is if you say that FTP over IPv6 is not FTP. After all, FTP was for IPv4, and IPv6 is a new-fangled transport... so FTP over IPv6 is not FTP... it's "magic". 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: Mon, 14 Apr 2008 18:27:02 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 11:25:10 -0700 Message-ID: <005b01c89e5c$e9822720$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcieT2EsgGme3+YNSZ+VU1+AdtaEzAAANuYA owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 11:39 PM: > Glen Zorn wrote: >> Given the Co-Chair's response to the question of the meaning of >> "backward compatibility", I think that it would show considerably >> more intellectual honesty to simply remove the first bullet: >> "compatibility" defined by the feasibility of implementing a >> protocol gateway is essentially meaningless, since by that measure >> there are no two protocols that are not "compatible". > > While that's true, a RadSec to RADIUS gateway involves > terminating TCP, TLS, and forwarding the contents to RADIUS. > If this isn't RADIUS, then by the same standards, any HTTPS to HTTP > proxy isn't doing HTTP. Hmm. By that standard, it would seem that Diameter is RADIUS, too... > > Similarly, any IPv4 to IPv6 gateway is evil, because it > involves changing the transport layers underneath the > application-layer protocol. I don't think that I said anything about good or evil :-), but you make my point for me: IPv6 is hardly "backward compatible" w/IPv4 & that's not a problem. The problem would arise if someone claimed that it was because, 'Well, you can build a gateway'. > > And finally, SIP allows for both UDP and TCP transports, > each with the option (or not) of using TLS. There would seem > to be obvious parallels between SIP and RADIUS here. Certainly, in that RADIUS (the RFC 2865 version, anyway) only allows UDP transport. How could I have missed that? ;-) > > 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: -- 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, 14 Apr 2008 17:34:20 +0000 From: "David B. Nelson" To: , "'Glen Zorn'" Cc: "'Joseph Salowey \(jsalowey\)'" , Subject: RE: RADEXT WG re-charter Date: Mon, 14 Apr 2008 13:29:10 -0400 Organization: Elbrys Networks, Inc. Message-ID: <01b201c89e55$0cab70b0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFAAAers8A== Glen Zorn writes... > 'Frankly, my dear, I don't give a damn.' Cute... > It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt > was posted ... for at least 3 years there have been at 2 (or more) > independent, interoperable implementations that were FIPS-certified. Given that there are implementations of this key-wrap scheme, presumably using VSAs, it might be well to publish an Information RFC, describing the actual implementations, using those VSAs. > But wait! Let's spend a little (lot) more time conjecturing about > another way, a way to solve "the general problem" (AKA "boiling the > ocean" if it's a proposal we don't care for). Well, gosh, no thanks, > but you guys go ahead & have fun! RADEXT has a chartered work item to address crypto-agility. We have requirements for this wok, and we now have an ID capturing those requirements. We don't have a requirement to specifically address key-wrap, as a separate problem. My questions is whether RADEXT really needs to create two drafts to satisfy the crypto-agility work item, one for key-wrap and one for general purpose encrypted attributes. The fact that solutions, and drafts, exist to address key-wrap and encrypted attributes separately is a point in favor of retaining the separation. I'm just questioning whether that's a sufficient basis on which to decide that we need such separation of concerns. If the consensus us of the WG is that we should proceed with separate documents for key-wrap and general crypto-agility, we can propose doing that in our revised charter. It would be nice, however, to have a reason beyond the existence of (4 year old) drafts that are structured that way. -- 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, 14 Apr 2008 16:49:35 +0000 From: "Glen Zorn" To: "'David B. Nelson'" , Cc: "'Joseph Salowey \(jsalowey\)'" , Subject: RE: RADEXT WG re-charter Date: Mon, 14 Apr 2008 23:47:52 +0700 Message-ID: <001d01c89e4f$53bed740$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQAAOwYFA= owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 9:48 PM: > Glen Zorn writes... > >> There was indeed discussion, but mostly in the form of various >> assertions by the radext Chairs that this would be a good idea; > > That much is largely true. > >> ... I don't recall anything like consensus around this topic. > > Unless I much mistake the poll questions and results that > Charles facilitated during the HOKEY meeting, there was > consensus in the room. I really appreciate your judgment of consensus in the hokey WG. Please drop by more often. > Of course, that is subject to > consensus on the list. I'm also aware that you think this it not a > good idea. See below. > >> I guess, then, that "gaining FIPS certification" is an unsatisfactory >> answer, since that was the one I (among others) gave. So what would >> be a satisfactory answer? > > Well, "gaining FIPS certification" for a product release is > likely a very fine thing indeed. I guess the question is > whether the only way to do that is to use the AES key-wrap as > described in draft-zorn-radius-keywrap-13.txt, or whether > another NIST-approved algorithm, designed for bulk data > encryption might also be used? > In the latter case we solve > the more general problem, without requiring separate attribute > formats for keys and general purpose data. 'Frankly, my dear, I don't give a damn.' I do find it quite fascinating to observe this whole thing happening in (very) slow motion. It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt was posted & in that period of time every trick in the book (& I'm sure some that were new additions) has been used to ignore, delay or kill it; furthermore, for at least 3 years there have been at 2 (or more) independent, interoperable implementations that were FIPS-certified. But wait! Let's spend a little (lot) more time conjecturing about another way, a way to solve "the general problem" (AKA "boiling the ocean" if it's a proposal we don't care for). Well, gosh, no thanks, but you guys go ahead & have fun! > > > > -- > 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: Mon, 14 Apr 2008 16:47:59 +0000 Message-ID: <480389AA.40600@nitros9.org> Date: Mon, 14 Apr 2008 18:43:22 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard_Aboba@hotmail.com wrote: > This is a consensus call for acceptance of the RADEXT WG re-charter. The > consensus call will last until April 28, 2008. Please send email to the > list > stating whether you are in favor or opposed to the RADEXT WG re-charter > proposal: I am in favor of the proposal. 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: Mon, 14 Apr 2008 16:44:19 +0000 Message-ID: <480388AF.7040904@nitros9.org> Date: Mon, 14 Apr 2008 18:39:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Glen Zorn CC: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: Consensus Call on RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Given the Co-Chair's response to the question of the meaning of > "backward compatibility", I think that it would show considerably more > intellectual honesty to simply remove the first bullet: "compatibility" > defined by the feasibility of implementing a protocol gateway is > essentially meaningless, since by that measure there are no two > protocols that are not "compatible". While that's true, a RadSec to RADIUS gateway involves terminating TCP, TLS, and forwarding the contents to RADIUS. If this isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't doing HTTP. Similarly, any IPv4 to IPv6 gateway is evil, because it involves changing the transport layers underneath the application-layer protocol. And finally, SIP allows for both UDP and TCP transports, each with the option (or not) of using TLS. There would seem to be obvious parallels between SIP and RADIUS here. 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: Mon, 14 Apr 2008 15:58:16 +0000 From: "Glen Zorn" To: , Subject: RE: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 22:56:26 +0700 Message-ID: <001c01c89e48$1f348a30$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcieMwe23/m5rnbXTe6Ve/6y3296vAAFAQBg owner-radiusext@ops.ietf.org <> scribbled on Monday, April 14, 2008 8:20 PM: > This is a consensus call for acceptance of the RADEXT WG > re-charter. The consensus call will last until April 28, > 2008. Please send email to the list stating whether you are > in favor or opposed to the RADEXT WG re-charter > proposal: Given the Co-Chair's response to the question of the meaning of "backward compatibility", I think that it would show considerably more intellectual honesty to simply remove the first bullet: "compatibility" defined by the feasibility of implementing a protocol gateway is essentially meaningless, since by that measure there are no two protocols that are not "compatible". > > > ======================================================= > Description of Working Group: > > The RADIUS Extensions Working Group will focus on extensions > to the RADIUS protocol required to define extensions to the > standard attribute space as well as to address cryptographic > algorithm agility and use over new secure transports. In > addition, RADEXT will work on RADIUS Design Guidelines and > define new attributes for particular applications of > authentication, authorization and accounting such as NAS > management and local area network (LAN) usage. > > In order to enable interoperation of heterogeneous > RADIUS/Diameter deployments, all RADEXT WG work items MUST > contain a Diameter compatibility section, outlining how > interoperability with Diameter will be maintained. > > Furthermore, to ensure backward compatibility with existing > RADIUS implementations, as well as compatibility between > RADIUS and Diameter, the following restrictions are imposed on > extensions considered by the RADEXT WG: > > - All RADIUS work MUST be backward compatible with existing > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, > 4668-4673, 4675, 5080, 5090 and 5176. > > - All RADIUS work MUST be compatible with equivalent > facilities in Diameter. Where possible, new attributes should > be defined so that the same attribute can be used in both > RADIUS and Diameter without translation. In other cases a > translation considerations section should be included in the > specification. > > > Work Items > > The immediate goals of the RADEXT working group are to address > the following issues: > > - RADIUS design guidelines. This document will provide > guidelines for design of RADIUS attributes. It will > specifically consider how complex data types may be introduced > in a robust manner, maintaining backwards compatibility with > existing RADIUS RFCs, across all the classes of attributes: > Standard, Vendor-Specific and SDO-Specific. > In addition, it will review RADIUS data types and associated > backwards compatibility issues. > > - RADIUS Management authorization. This document will define > the use of RADIUS for NAS management over IP. > > -RADIUS attribute space extension. The standard RADIUS > attribute space is currently being depleted. This document > will provide additional standard attribute space, while > maintaining backward compatibility with existing attributes. > > -RADIUS Cryptographic Algorithm Agility. RADIUS has > traditionally relied on MD5 for both per-packet integrity and > authentication as well as attribute confidentiality. Given the > increasingly successful attacks being mounted against MD5, the > ability to support alternative algorithms is required. This > work item will include documentation of RADIUS crypto-agility > requirements, as well as development of one or more > Experimental RFCs providing support for negotiation of > alternative cryptographic algorithms to protect RADIUS. > > - IEEE 802 attributes. New attributes have been proposed to > support IEEE 802 standards for wired and wireless LANs. This > work item will support authentication, authorization and > accounting attributes needed by IEEE 802 groups including IEEE > 802.1, IEEE 802.11 and IEEE 802.16. > > - New RADIUS transports. New secure transports for RADIUS will > be developed, including TCP/TLS (RADSEC) and UDP/DTLS. > > - Documentation of Status-Server usage. A document describing > usage of the Status-Server facility will be developed. > > Goals and Milestones: > Jun 2008 RADIUS Design Guidelines submitted as a Best Current > Practice RFC Jun 2008 RADIUS Management Authorization I-D > submitted as a Proposed Standard RFC Sep 2008 RADIUS > Crypto-agility Requirements submitted as an Informational RFC > Sep 2008 Extended Attributes I-D submitted as a Proposed > Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a > Proposed Standard RFC Mar 2009 Status-Server I-D submitted as > a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) > draft submitted as an Experimental RFC June 2009 RADIUS over > DTLS I-D submitted as an Experimental RFC June 2009 RADIUS > Cryptographic Algorithm Agility I-D submitted as an Experimental RFC -- 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, 14 Apr 2008 14:52:02 +0000 From: "David B. Nelson" To: Cc: "'Joseph Salowey \(jsalowey\)'" , , "'Glen Zorn'" Subject: RE: RADEXT WG re-charter Date: Mon, 14 Apr 2008 10:47:57 -0400 Organization: Elbrys Networks, Inc. Message-ID: <019e01c89e3e$87835030$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYAA/TUJQ Glen Zorn writes... > There was indeed discussion, but mostly in the form of various > assertions by the radext Chairs that this would be a good idea; That much is largely true. >... I don't recall anything like consensus around this topic. Unless I much mistake the poll questions and results that Charles facilitated during the HOKEY meeting, there was consensus in the room. Of course, that is subject to consensus on the list. I'm also aware that you think this it not a good idea. > I guess, then, that "gaining FIPS certification" is an unsatisfactory > answer, since that was the one I (among others) gave. So what would > be a satisfactory answer? Well, "gaining FIPS certification" for a product release is likely a very fine thing indeed. I guess the question is whether the only way to do that is to use the AES key-wrap as described in draft-zorn-radius-keywrap-13.txt, or whether another NIST-approved algorithm, designed for bulk data encryption might also be used? In the latter case we solve the more general problem, without requiring separate attribute formats for keys and general purpose data. -- 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, 14 Apr 2008 13:50:06 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: "'Joseph Salowey \(jsalowey\)'" , , Subject: RE: RADEXT WG re-charter Date: Mon, 14 Apr 2008 20:48:07 +0700 Message-ID: <001801c89e36$38856cf0$33da787c@arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnAARmUsYA== owner-radiusext@ops.ietf.org <> scribbled on Saturday, April 12, 2008 5:58 AM: > Joseph Salowey writes... > >> With respect to the key transport item, I don't recall this >> discussion on the HOKEY list. I might have missed it. In any case I >> don't think this is the right approach. Key transport is a general >> problem that can be solved with a general solution. > > The discussion in the HOKEY session at IETF-71, as I recall > it, centered around whether HOKEY ought to define a > non-protected RADIUS (Diameter) attribute for key transport (I > called this a key container attribute) that could utilize > various options for protection, one of which might be a > generalized Encrypted Attribute format, as described in a RADEXT > Crypto-Agility draft. There was indeed discussion, but mostly in the form of various assertions by the radext Chairs that this would be a good idea; I don't recall anything like consensus around this topic. > > Follow up discussion in the RADEXT WG session included the > issue of whether or not the cryptographic requirements for key > wrap (key transport) were sufficiently different from the > cryptographic requirements for transport of bulk data that a > separate protection mechanism needed to be defined. > > We leaned that special purpose key wrap mechanisms could be > "simpler" in some cryptographic sense because one can rely on > the property of keys that their content is highly random. The > question that I think was never satisfactorily answered is why > one would need to deploy special purpose key wrap mechanisms > in addition to general propose attribute encryption mechanisms. I guess, then, that "gaining FIPS certification" is an unsatisfactory answer, since that was the one I (among others) gave. So what would be a satisfactory answer? > > Having said that, it is true that the RADIUS community has > existing "special purpose" key wrap attributes (the MSPPE key > attributes) that do not meet the crypto-agility requirements. > We need to decide what to do about these. Can you say "deprecate"? :-) > They are widely deployed today, e.g. in 802.11. > > > > -- > 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: Mon, 14 Apr 2008 13:21:45 +0000 Message-ID: From: To: Subject: Consensus Call on RADEXT WG re-charter Date: Mon, 14 Apr 2008 06:19:57 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C89DF7.8F8BB5C0" This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C89DF7.8F8BB5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a consensus call for acceptance of the RADEXT WG re-charter. = The consensus call will last until April 28, 2008. Please send email to the = list=20 stating whether you are in favor or opposed to the RADEXT WG re-charter proposal:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for=20 particular applications of authentication, authorization and=20 accounting such as NAS management and local area network (LAN) usage.=20 In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. =20 Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. =20 - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP.=20 -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20 relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice = RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed = Standard RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an = Informational RFC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental = RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an = Experimental RFC ------=_NextPart_000_001C_01C89DF7.8F8BB5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a consensus call for acceptance = of the=20 RADEXT WG re-charter.  The
consensus call will last until = April 28,=20 2008.  Please send email to the list
stating whether you are in favor or = opposed to the=20 RADEXT WG re-charter
proposal:
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Description of Working Group:

The RADIUS Extensions Working Group will focus on = extensions=20 to the
RADIUS protocol required to define extensions to the=20 standard
attribute space as well as to address cryptographic=20 algorithm
agility and use over new secure transports. In addition, = RADEXT=20 will
work on RADIUS Design Guidelines and define new attributes for=20
particular applications of authentication, authorization and =
accounting=20 such as NAS management and local area network (LAN) usage.

In = order to=20 enable interoperation of heterogeneous RADIUS/Diameter
deployments, = all=20 RADEXT WG work items MUST contain a Diameter
compatibility section, = outlining=20 how interoperability with
Diameter will be = maintained.

Furthermore, to=20 ensure backward compatibility with existing RADIUS
implementations, = as well=20 as compatibility between RADIUS and Diameter,
the following = restrictions are=20 imposed on extensions considered by the
RADEXT WG:

- All = RADIUS work=20 MUST be backward compatible with existing RADIUS
RFCs, including RFCs = 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and=20 5176.

- All RADIUS work MUST be compatible with equivalent = facilities=20 in
Diameter. Where possible, new attributes should be defined so = that
the=20 same attribute can be used in both RADIUS and Diameter = without
translation.=20 In other cases a translation considerations
section should be = included in the=20 specification.
 

Work Items

The immediate goals of = the=20 RADEXT working group are to address the
following issues:

- = RADIUS=20 design guidelines. This document will provide guidelines for
design = of RADIUS=20 attributes. It will specifically consider how
complex data types may = be=20 introduced in a robust manner, maintaining
backwards compatibility = with=20 existing RADIUS RFCs, across all the
classes of attributes: Standard, = Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS = data=20 types and associated
backwards compatibility issues.
 
- = RADIUS=20 Management authorization. This document will define the
use of RADIUS = for NAS=20 management over IP.

-RADIUS attribute space extension. The = standard=20 RADIUS attribute
space is currently being depleted. This document = will=20 provide
additional standard attribute space, while maintaining=20 backward
compatibility with existing attributes.

-RADIUS = Cryptographic=20 Algorithm Agility. RADIUS has traditionally
relied on MD5 for both=20 per-packet integrity and authentication as well
as attribute = confidentiality.=20 Given the increasingly successful
attacks being mounted against MD5, = the=20 ability to support
alternative algorithms is required. This work item = will
include documentation of RADIUS crypto-agility = requirements,
as well=20 as development of one or more Experimental RFCs providing
support for = negotiation of alternative cryptographic algorithms
to protect=20 RADIUS.

- IEEE 802 attributes. New attributes have been proposed=20 to
support IEEE 802 standards for wired and wireless LANs. = This
work item=20 will support authentication, authorization and
accounting attributes = needed=20 by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE=20 802.16.

- New RADIUS transports. New secure transports for RADIUS = will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

-=20 Documentation of Status-Server usage. A document
describing usage of = the=20 Status-Server facility will be
developed.

Goals and = Milestones:
Jun=20 2008 RADIUS Design Guidelines submitted as a Best Current Practice = RFC
Jun=20 2008 RADIUS Management Authorization I-D submitted as a Proposed = Standard=20 RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an = Informational=20 RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard = RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard = RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard = RFC
Mar=20 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental = RFC
June=20 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 = RADIUS=20 Cryptographic Algorithm Agility I-D submitted as an Experimental=20 RFC
------=_NextPart_000_001C_01C89DF7.8F8BB5C0-- -- 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, 11 Apr 2008 23:01:38 +0000 From: "David B. Nelson" To: "'Joseph Salowey \(jsalowey\)'" , , Subject: RE: RADEXT WG re-charter Date: Fri, 11 Apr 2008 18:58:22 -0400 Organization: Elbrys Networks, Inc. Message-ID: <010001c89c27$8a6ff5f0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQAAAk0NnA= Joseph Salowey writes... > With respect to the key transport item, I don't recall this discussion > on the HOKEY list. I might have missed it. In any case I don't think > this is the right approach. Key transport is a general problem that can > be solved with a general solution. The discussion in the HOKEY session at IETF-71, as I recall it, centered around whether HOKEY ought to define a non-protected RADIUS (Diameter) attribute for key transport (I called this a key container attribute) that could utilize various options for protection, one of which might be a generalized Encrypted Attribute format, as described in a RADEXT Crypto-Agility draft. Follow up discussion in the RADEXT WG session included the issue of whether or not the cryptographic requirements for key wrap (key transport) were sufficiently different from the cryptographic requirements for transport of bulk data that a separate protection mechanism needed to be defined. We leaned that special purpose key wrap mechanisms could be "simpler" in some cryptographic sense because one can rely on the property of keys that their content is highly random. The question that I think was never satisfactorily answered is why one would need to deploy special purpose key wrap mechanisms in addition to general propose attribute encryption mechanisms. Having said that, it is true that the RADIUS community has existing "special purpose" key wrap attributes (the MSPPE key attributes) that do not meet the crypto-agility requirements. We need to decide what to do about these. They are widely deployed today, e.g. in 802.11. -- 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, 11 Apr 2008 22:38:44 +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: RADEXT WG re-charter Date: Fri, 11 Apr 2008 15:37:32 -0700 Message-ID: Thread-Topic: RADEXT WG re-charter Thread-Index: AcibKmpZgzQ6RN9kSDumURarkD8Q7QA1pQQA From: "Joseph Salowey (jsalowey)" To: , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9097; t=1207953403; x=1208817403; c=relaxed/simple; s=sjdkim2002; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=G8NbLvGSyQpqk7YpJ9ms3qz/gpwOvUmT9Sz4kBIMYOo=; b=voevJokygoeJLjO7eHZxL6SnQHFJC9NXMS1MLOyZgRuuYbCdUry46Yjao7 sY34YevGha6vTFE0UK3XjDSyuLPMoHBidLZEuVgT7bimz1sDXx495teoFRXr xqNCy9zCiG; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Hi Bernard, Thanks for the detailed explanation.=20 With respect to the key transport item, I don't recall this discussion on the HOKEY list. I might have missed it. In any case I don't think this is the right approach. Key transport is a general problem that can be solved with a general solution.=20 Joe > > What does it mean for a new transport to be backward compatible? >=20 > I think it means that it is possible to write a transport=20 > proxy that goes to/from RADIUS as it exists today (e.g. over=20 > UDP) and encapsulates it to/from the new transport, with=20 > minimal (ideally no) changes to the RADIUS packet. >=20 > > What are we trying to gain by including new transports,=20 > especially TCP? > > Is it just crypto agility or are there other goals as well? This=20 > > seems like a lot of work to gain crypto agility, it would=20 > be good to=20 > > understand what else we have to gain? >=20 > The contemplated work includes both DTLS/UDP and TLS/TCP > transports. The arguments for the former relate primarily to > security; the arguments for the later relate to both security > and transport considerations. The benefits in both areas > have been laid out in presentations to the RADEXT WG over the=20 > last year and a half. >=20 > Transport issues were examined in detail in the AAA WG, which=20 > described AAA requirements (including transport) in > RFC 2989. Reliable transport was chosen, as a result of > concerns over accounting reliability as well as experience=20 > with the drawbacks of the undefined transport behavior of=20 > RADIUS (discussed in RFC 5080 Section 2.2.1). >=20 > The behavior of AAA over reliable transport was analyzed in=20 > RFC 3539, which also develops a transport profile and=20 > suggests failover and load balancing algorithms. >=20 > Together, these documents provide a response to RFC 2865=20 > Section 2.4, which lays out four reasons why RADIUS uses UDP: >=20 > 1. If the request to a primary Authentication server fails, a > secondary server must be queried. > 2. The timing requirements of this particular protocol are > significantly different than TCP provides. > 3. The stateless nature of this protocol simplifies the use of UDP. > 4. UDP simplifies the server implementation. >=20 > RFC 3539 provides for failover and load balancing (1 & 2). > Since RADIUS was first standardized in the mid 1990s,=20 > implementations have grown in sophistication and the=20 > underlying hardware has increased by several orders of magnitude > in performance. As a result, considerations 3 and 4 have lessened > in importance. >=20 > > What is the intended status of this work? Experimental? Standards=20 > > track? >=20 > The transport documents are slated for Experimental status=20 > (as stated in the charter). >=20 > > Now that we have a separate item for secure transports=20 > shouldn't this=20 > > explicitly refer to attribute based encryption, message=20 > authentication=20 > > and key transport? >=20 > The detailed requirements are going to be developed in a=20 > separate document. However, as discussed in the HOKEY WG=20 > meeting, the focus of the RADEXT WG will be on providing a=20 > generic security solution, including confidentiality, and=20 > message integrity/authentication. > As discussed in the HOKEY WG meeting, key management=20 > attributes specific to ERX will be developed in HOKEY WG and=20 > will be independent of the specific RADIUS crypto-agility mechanism. >=20 > >> -----Original Message----- > >> From: owner-radiusext@ops.ietf.org > >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > >> Sent: Tuesday, April 01, 2008 12:41 PM > >> To: radiusext@ops.ietf.org > >> Subject: RADEXT WG re-charter > >> > >> As we discussed at IETF 71, the RADEXT WG is looking at a=20 > re-charter. =20 > >> A strawman re-charter proposal is enclosed below. > >> Once comments from WG participants have been incorporated, we will=20 > >> begin a formal WG consensus call on the proposed re-charter by the=20 > >> end of the month. > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> Description of Working Group: > >> The RADIUS Extensions Working Group will focus on=20 > extensions to the=20 > >> RADIUS protocol required to define extensions to the standard=20 > >> attribute space as well as to address cryptographic=20 > algorithm agility=20 > >> and use over new secure transports. In addition, RADEXT=20 > will work on=20 > >> RADIUS Design Guidelines and define new attributes for particular=20 > >> applications of authentication, authorization and=20 > accounting such as=20 > >> NAS management and local area network (LAN) usage. > >> > >> In order to enable interoperation of heterogeneous RADIUS/Diameter=20 > >> deployments, all RADEXT WG work items MUST contain a Diameter=20 > >> compatibility section, outlining how interoperability with=20 > Diameter=20 > >> will be maintained. > >> > >> > >> Furthermore, to ensure backward compatibility with existing RADIUS=20 > >> implementations, as well as compatibility between RADIUS and=20 > >> Diameter, the following restrictions are imposed on extensions=20 > >> considered by the RADEXT WG: > >> > >> > >> - All RADIUS work MUST be backward compatible with existing RADIUS=20 > >> RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,=20 > >> 4675, 5080, 5090 and 5176. > >> > >> > >> - All RADIUS work MUST be compatible with equivalent facilities in=20 > >> Diameter. Where possible, new attributes should be defined so that=20 > >> the same attribute can be used in both RADIUS and Diameter without=20 > >> translation. In other cases a translation considerations section=20 > >> should be included in the specification. > >> > >> > >> Work Items > >> > >> > >> The immediate goals of the RADEXT working group are to address the=20 > >> following issues: > >> > >> > >> - RADIUS design guidelines. This document will provide=20 > guidelines for=20 > >> design of RADIUS attributes. It will specifically consider how=20 > >> complex data types may be introduced in a robust manner,=20 > maintaining=20 > >> backwards compatibility with existing RADIUS RFCs, across all the=20 > >> classes of attributes: Standard, Vendor-Specific and SDO-Specific. > >> In addition, it will review RADIUS data types and associated=20 > >> backwards compatibility issues. > >> > >> - RADIUS Management authorization. This document will=20 > define the use=20 > >> of RADIUS for NAS management over IP. > >> > >> > >> -RADIUS attribute space extension. The standard RADIUS attribute=20 > >> space is currently being depleted. This document will provide=20 > >> additional standard attribute space, while maintaining backward=20 > >> compatibility with existing attributes. > >> > >> > >> -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20 > >> relied on MD5 for both per-packet integrity and authentication as=20 > >> well as attribute confidentiality. Given the increasingly=20 > successful=20 > >> attacks being mounted against MD5, the ability to support=20 > alternative=20 > >> algorithms is required. This work item will include=20 > documentation of=20 > >> RADIUS crypto-agility requirements, as well as development=20 > of one or=20 > >> more Experimental RFCs providing support for negotiation of=20 > >> alternative cryptographic algorithms to protect RADIUS. > >> > >> > >> - IEEE 802 attributes. New attributes have been proposed=20 > to support=20 > >> IEEE 802 standards for wired and wireless LANs. This work=20 > item will=20 > >> support authentication, authorization and accounting attributes=20 > >> needed by IEEE 802 groups including IEEE 802.1, IEEE=20 > 802.11 and IEEE=20 > >> 802.16. > >> > >> > >> - New RADIUS transports. New secure transports for RADIUS will be=20 > >> developed, including TCP/TLS (RADSEC) and UDP/DTLS. > >> > >> - Documentation of Status-Server usage. A document=20 > describing usage=20 > >> of the Status-Server facility will be developed. > >> > >> > >> Goals and Milestones: > >> Jun 2008 RADIUS Design Guidelines submitted as a Best Current=20 > >> Practice RFC Jun 2008 RADIUS Management Authorization I-D=20 > submitted=20 > >> as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility=20 > >> Requirements submitted as an Informational RFC Sep 2008 Extended=20 > >> Attributes I-D submitted as a Proposed Standard RC Dec=20 > 2008 IEEE 802=20 > >> Attributes I-D submitted as a Proposed Standard RFC Mar 2009=20 > >> Status-Server I-D submitted as a Proposed Standard RFC Mar 2009=20 > >> RADSEC draft submitted as an Experimental RFC June 2009=20 > RADIUS over=20 > >> DTLS I-D submitted as an Experimental RFC June 2009 RADIUS=20 > >> Cryptographic Algorithm Agility I-D submitted as an=20 > Experimental RFC > >> > >> > >=20 >=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: Fri, 11 Apr 2008 04:54:30 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_a791bdd9-2836-4b55-b5b7-ebd2aeb3c188_" From: Bernard Aboba To: Subject: Minutes from IETF 71 Date: Thu, 10 Apr 2008 21:53:33 -0700 MIME-Version: 1.0 --_a791bdd9-2836-4b55-b5b7-ebd2aeb3c188_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you took minutes at the RADEXT WG meeting at IETF 71, please send them = to Dave and myself.=20 --_a791bdd9-2836-4b55-b5b7-ebd2aeb3c188_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you took minutes at the RADEXT WG meeting at IETF  71, please send = them to Dave and myself.


= --_a791bdd9-2836-4b55-b5b7-ebd2aeb3c188_-- -- 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, 10 Apr 2008 16:47:05 +0000 Message-ID: From: To: "Joseph Salowey \(jsalowey\)" , Subject: Re: RADEXT WG re-charter Date: Thu, 10 Apr 2008 09:45:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > What does it mean for a new transport to be backward compatible? I think it means that it is possible to write a transport proxy that goes to/from RADIUS as it exists today (e.g. over UDP) and encapsulates it to/from the new transport, with minimal (ideally no) changes to the RADIUS packet. > What are we trying to gain by including new transports, especially TCP? > Is it just crypto agility or are there other goals as well? This seems > like a lot of work to gain crypto agility, it would be good to > understand what else we have to gain? The contemplated work includes both DTLS/UDP and TLS/TCP transports. The arguments for the former relate primarily to security; the arguments for the later relate to both security and transport considerations. The benefits in both areas have been laid out in presentations to the RADEXT WG over the last year and a half. Transport issues were examined in detail in the AAA WG, which described AAA requirements (including transport) in RFC 2989. Reliable transport was chosen, as a result of concerns over accounting reliability as well as experience with the drawbacks of the undefined transport behavior of RADIUS (discussed in RFC 5080 Section 2.2.1). The behavior of AAA over reliable transport was analyzed in RFC 3539, which also develops a transport profile and suggests failover and load balancing algorithms. Together, these documents provide a response to RFC 2865 Section 2.4, which lays out four reasons why RADIUS uses UDP: 1. If the request to a primary Authentication server fails, a secondary server must be queried. 2. The timing requirements of this particular protocol are significantly different than TCP provides. 3. The stateless nature of this protocol simplifies the use of UDP. 4. UDP simplifies the server implementation. RFC 3539 provides for failover and load balancing (1 & 2). Since RADIUS was first standardized in the mid 1990s, implementations have grown in sophistication and the underlying hardware has increased by several orders of magnitude in performance. As a result, considerations 3 and 4 have lessened in importance. > What is the intended status of this work? Experimental? Standards > track? The transport documents are slated for Experimental status (as stated in the charter). > Now that we have a separate item for secure transports shouldn't this > explicitly refer to attribute based encryption, message authentication > and key transport? The detailed requirements are going to be developed in a separate document. However, as discussed in the HOKEY WG meeting, the focus of the RADEXT WG will be on providing a generic security solution, including confidentiality, and message integrity/authentication. As discussed in the HOKEY WG meeting, key management attributes specific to ERX will be developed in HOKEY WG and will be independent of the specific RADIUS crypto-agility mechanism. >> -----Original Message----- >> From: owner-radiusext@ops.ietf.org >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >> Sent: Tuesday, April 01, 2008 12:41 PM >> To: radiusext@ops.ietf.org >> Subject: RADEXT WG re-charter >> >> As we discussed at IETF 71, the RADEXT WG is looking at a >> re-charter. A strawman re-charter proposal is enclosed below. >> Once comments from WG participants have been incorporated, we >> will begin a formal WG consensus call on the proposed >> re-charter by the end of the month. >> >> ================================== >> >> Description of Working Group: >> The RADIUS Extensions Working Group will focus on extensions >> to the RADIUS protocol required to define extensions to the >> standard attribute space as well as to address cryptographic >> algorithm agility and use over new secure transports. In >> addition, RADEXT will work on RADIUS Design Guidelines and >> define new attributes for particular applications of >> authentication, authorization and accounting such as NAS >> management and local area network (LAN) usage. >> >> In order to enable interoperation of heterogeneous >> RADIUS/Diameter deployments, all RADEXT WG work items MUST >> contain a Diameter compatibility section, outlining how >> interoperability with Diameter will be maintained. >> >> >> Furthermore, to ensure backward compatibility with existing >> RADIUS implementations, as well as compatibility between >> RADIUS and Diameter, the following restrictions are imposed >> on extensions considered by the RADEXT WG: >> >> >> - All RADIUS work MUST be backward compatible with existing >> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, >> 3580, 4668-4673, 4675, 5080, 5090 and 5176. >> >> >> - All RADIUS work MUST be compatible with equivalent >> facilities in Diameter. Where possible, new attributes should >> be defined so that the same attribute can be used in both >> RADIUS and Diameter without translation. In other cases a >> translation considerations section should be included in the >> specification. >> >> >> Work Items >> >> >> The immediate goals of the RADEXT working group are to >> address the following issues: >> >> >> - RADIUS design guidelines. This document will provide >> guidelines for design of RADIUS attributes. It will >> specifically consider how complex data types may be >> introduced in a robust manner, maintaining backwards >> compatibility with existing RADIUS RFCs, across all the >> classes of attributes: Standard, Vendor-Specific and SDO-Specific. >> In addition, it will review RADIUS data types and associated >> backwards compatibility issues. >> >> - RADIUS Management authorization. This document will define >> the use of RADIUS for NAS management over IP. >> >> >> -RADIUS attribute space extension. The standard RADIUS >> attribute space is currently being depleted. This document >> will provide additional standard attribute space, while >> maintaining backward compatibility with existing attributes. >> >> >> -RADIUS Cryptographic Algorithm Agility. RADIUS has >> traditionally relied on MD5 for both per-packet integrity and >> authentication as well as attribute confidentiality. Given >> the increasingly successful attacks being mounted against >> MD5, the ability to support alternative algorithms is >> required. This work item will include documentation of RADIUS >> crypto-agility requirements, as well as development of one or >> more Experimental RFCs providing support for negotiation of >> alternative cryptographic algorithms to protect RADIUS. >> >> >> - IEEE 802 attributes. New attributes have been proposed to >> support IEEE 802 standards for wired and wireless LANs. This >> work item will support authentication, authorization and >> accounting attributes needed by IEEE 802 groups including >> IEEE 802.1, IEEE 802.11 and IEEE 802.16. >> >> >> - New RADIUS transports. New secure transports for RADIUS will >> be developed, including TCP/TLS (RADSEC) and UDP/DTLS. >> >> - Documentation of Status-Server usage. A document >> describing usage of the Status-Server facility will be >> developed. >> >> >> Goals and Milestones: >> Jun 2008 RADIUS Design Guidelines submitted as a Best Current >> Practice RFC >> Jun 2008 RADIUS Management Authorization I-D submitted as a >> Proposed Standard RFC >> Sep 2008 RADIUS Crypto-agility Requirements submitted as an >> Informational RFC >> Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC >> Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC >> Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC >> Mar 2009 RADSEC draft submitted as an Experimental RFC >> June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC >> June 2009 RADIUS Cryptographic Algorithm Agility I-D >> submitted as an Experimental RFC >> >> > -- 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, 09 Apr 2008 04:22:29 +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: RADEXT WG re-charter Date: Tue, 8 Apr 2008 21:22:09 -0700 Message-ID: Thread-Topic: RADEXT WG re-charter Thread-Index: AciUMIh5HDfC0ApORCe0YwuFp/hp0wFxZR0Q From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6674; t=1207714880; x=1208578880; c=relaxed/simple; s=sjdkim3002; 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=20RADEXT=20WG=20re-charter |Sender:=20; bh=RDCrQnnRWS/e+O+zWm6jqKYXsiBrRvFsYhrjBxqF8Kc=; b=M9FdYSO9IhO6LCyLHliB+5Tm6WdDbDPjGfSn0BYYw2rES9jWWccqDi5iQI GBV0CKvvt1Tw02a+0hppEWHO0bI9ySwMHo3iFLV0K9BWAXIJgq7abLc1/gIg 5MLSSqPLSY; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Some questions on the proposed charter: >All RADIUS work MUST be backward compatible with existing=20 > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579,=20 > 3580, 4668-4673, 4675, 5080, 5090 and 5176. What does it mean for a new transport to be backward compatible? > - New RADIUS transports. New secure transports for RADIUS will > be developed, including TCP/TLS (RADSEC) and UDP/DTLS. What are we trying to gain by including new transports, especially TCP? Is it just crypto agility or are there other goals as well? This seems like a lot of work to gain crypto agility, it would be good to understand what else we have to gain. What is the intended status of this work? Experimental? Standards track? =20 > -RADIUS Cryptographic Algorithm Agility. RADIUS has=20 > traditionally relied on MD5 for both per-packet integrity and=20 > authentication as well as attribute confidentiality. Given=20 > the increasingly successful attacks being mounted against=20 > MD5, the ability to support alternative algorithms is=20 > required. This work item will include documentation of RADIUS=20 > crypto-agility requirements, as well as development of one or=20 > more Experimental RFCs providing support for negotiation of=20 > alternative cryptographic algorithms to protect RADIUS. > =20 Now that we have a separate item for secure transports shouldn't this explicitly refer to attribute based encryption, message authentication and key transport? =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, April 01, 2008 12:41 PM > To: radiusext@ops.ietf.org > Subject: RADEXT WG re-charter >=20 > As we discussed at IETF 71, the RADEXT WG is looking at a=20 > re-charter. A strawman re-charter proposal is enclosed below. =20 > Once comments from WG participants have been incorporated, we=20 > will begin a formal WG consensus call on the proposed=20 > re-charter by the end of the month.=20 > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > Description of Working Group: > The RADIUS Extensions Working Group will focus on extensions=20 > to the RADIUS protocol required to define extensions to the=20 > standard attribute space as well as to address cryptographic=20 > algorithm agility and use over new secure transports. In=20 > addition, RADEXT will work on RADIUS Design Guidelines and=20 > define new attributes for particular applications of=20 > authentication, authorization and accounting such as NAS=20 > management and local area network (LAN) usage.=20 >=20 > In order to enable interoperation of heterogeneous=20 > RADIUS/Diameter deployments, all RADEXT WG work items MUST=20 > contain a Diameter compatibility section, outlining how=20 > interoperability with Diameter will be maintained. > =20 >=20 > Furthermore, to ensure backward compatibility with existing=20 > RADIUS implementations, as well as compatibility between=20 > RADIUS and Diameter, the following restrictions are imposed=20 > on extensions considered by the RADEXT WG: > =20 >=20 > - All RADIUS work MUST be backward compatible with existing=20 > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579,=20 > 3580, 4668-4673, 4675, 5080, 5090 and 5176. > =20 >=20 > - All RADIUS work MUST be compatible with equivalent=20 > facilities in Diameter. Where possible, new attributes should=20 > be defined so that the same attribute can be used in both=20 > RADIUS and Diameter without translation. In other cases a=20 > translation considerations section should be included in the=20 > specification. > =20 >=20 > Work Items > =20 >=20 > The immediate goals of the RADEXT working group are to=20 > address the following issues: > =20 >=20 > - RADIUS design guidelines. This document will provide=20 > guidelines for design of RADIUS attributes. It will=20 > specifically consider how complex data types may be=20 > introduced in a robust manner, maintaining backwards=20 > compatibility with existing RADIUS RFCs, across all the=20 > classes of attributes: Standard, Vendor-Specific and SDO-Specific. > In addition, it will review RADIUS data types and associated=20 > backwards compatibility issues. > =20 > - RADIUS Management authorization. This document will define=20 > the use of RADIUS for NAS management over IP.=20 > =20 >=20 > -RADIUS attribute space extension. The standard RADIUS=20 > attribute space is currently being depleted. This document=20 > will provide additional standard attribute space, while=20 > maintaining backward compatibility with existing attributes. > =20 >=20 > -RADIUS Cryptographic Algorithm Agility. RADIUS has=20 > traditionally relied on MD5 for both per-packet integrity and=20 > authentication as well as attribute confidentiality. Given=20 > the increasingly successful attacks being mounted against=20 > MD5, the ability to support alternative algorithms is=20 > required. This work item will include documentation of RADIUS=20 > crypto-agility requirements, as well as development of one or=20 > more Experimental RFCs providing support for negotiation of=20 > alternative cryptographic algorithms to protect RADIUS. > =20 >=20 > - IEEE 802 attributes. New attributes have been proposed to > support IEEE 802 standards for wired and wireless LANs. This > work item will support authentication, authorization and > accounting attributes needed by IEEE 802 groups including > IEEE 802.1, IEEE 802.11 and IEEE 802.16. > =20 >=20 > - New RADIUS transports. New secure transports for RADIUS will > be developed, including TCP/TLS (RADSEC) and UDP/DTLS. >=20 > - Documentation of Status-Server usage. A document > describing usage of the Status-Server facility will be > developed. > =20 >=20 > Goals and Milestones: > Jun 2008 RADIUS Design Guidelines submitted as a Best Current=20 > Practice RFC > Jun 2008 RADIUS Management Authorization I-D submitted as a=20 > Proposed Standard RFC > Sep 2008 RADIUS Crypto-agility Requirements submitted as an=20 > Informational RFC > Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC > Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC > Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC > Mar 2009 RADSEC draft submitted as an Experimental RFC > June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC > June 2009 RADIUS Cryptographic Algorithm Agility I-D=20 > submitted as an Experimental RFC >=20 >=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: Fri, 04 Apr 2008 22:32:04 +0000 From: Mudit Goel To: Bernard Aboba , "radiusext@ops.ietf.org" Date: Fri, 4 Apr 2008 15:31:05 -0700 Subject: RE: RADEXT WG re-charter Thread-Topic: RADEXT WG re-charter Thread-Index: AciUMOKl93N4MjNVTAGZfkKjaBRf0QCcYLBQ Message-ID: <456A5146F9319946A179B523B9FC91D60D9E4E88F9@NA-EXMSG-C114.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_456A5146F9319946A179B523B9FC91D60D9E4E88F9NAEXMSGC114re_" MIME-Version: 1.0 --_000_456A5146F9319946A179B523B9FC91D60D9E4E88F9NAEXMSGC114re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nicely worded. I like the proposal for the charter. Mudit Goel From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Bernard Aboba Sent: Tuesday, April 01, 2008 3:41 PM To: radiusext@ops.ietf.org Subject: RADEXT WG re-charter As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. A st= rawman re-charter proposal is enclosed below. Once comments from WG participants have been incorporated, we will begin a = formal WG consensus call on the proposed re-charter by the end of the month. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC --_000_456A5146F9319946A179B523B9FC91D60D9E4E88F9NAEXMSGC114re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nicely worded. I like the proposal for the charter.

 

Mudit Goel

 

 

From: owner-radiuse= xt@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, April 01, 2008 3:41 PM
To: radiusext@ops.ietf.org
Subject: RADEXT WG re-charter

 

As we discussed at IETF 71, the RADEXT WG is looking at a re-charter.  A strawman re-charter proposal is enclosed below. 
Once comments from WG participants have been incorporated, we will begin a formal WG consensus call on the proposed
re-charter by the end of the month.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Description of Working Group:
The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage.

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.
 

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:
 

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.
 

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
 

Work Items
 

The immediate goals of the RADEXT working group are to address the
following issues:
 

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.
 

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.
 

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.
 

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.
 

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.
 

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC<= br> Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC draft submitted as an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

--_000_456A5146F9319946A179B523B9FC91D60D9E4E88F9NAEXMSGC114re_-- -- 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, 04 Apr 2008 19:00:08 +0000 From: "David B. Nelson" To: Subject: FW: [Isms] What granularity of attributes do we need for the secure transport? Date: Fri, 4 Apr 2008 14:57:53 -0400 Organization: Elbrys Networks, Inc. Message-ID: <002e01c89685$c9906780$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AciWhDpr2rSN4pDwTsGIDg8/QH3aEgAAW0kw > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, April 04, 2008 2:47 PM > To: David B. Nelson > Cc: isms@ietf.org > Subject: Re: [Isms] What granularity of attributes do we need for > the secure transport? > > On Fri, Apr 04, 2008 at 01:57:27PM -0400, David B. Nelson wrote: > > > What do others think about this decision point? > > > > -- Do we need only an abstract security level assertion? > > > > -- Do we need the transport protocol name? > > > > -- Do we need the transport protocol version? > > > > -- Do we need any further details of security parameters? > > As technical contributor, I like the abstract security level > assertion. More granular control can be achieved by means of > configuration of the SNMP engine or secure transport protocol. > > /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: Fri, 04 Apr 2008 18:59:20 +0000 From: "David B. Nelson" To: Subject: FW: [Isms] What granularity of attributes do we need for the secure transport? Date: Fri, 4 Apr 2008 14:56:49 -0400 Organization: Elbrys Networks, Inc. Message-ID: <002d01c89685$a3a649e0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AciWeRBg/P7z/v4TRjSCSwEE+iDxZAAAYdLwAAAep4AAAnla8A== There is a discussion going on currently in the ISMS WG with regard to authorization and/or provisioning of management access to a NAS, specifically with respect to the security properties of the transport protocol (for remote management). Some of this discussion has been specific to SNMP and the ISMS work, but some is more generally related to NAS management authorization. I'll forward (cross-post) those messages of general interest to RADEXT. You may also review the ISMS WG mailing list archives for additional information. > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of > David B. Nelson > Sent: Friday, April 04, 2008 1:57 PM > To: isms@ietf.org > Subject: Re: [Isms] What granularity of attributes do we need for the > secure transport? > > David Harrington writes... > > > I do not believe we need to provision the security protocol; ... > > Meaning we don't need to specify such things as the selection of optional > modes, cipher suite, authentication mechanism, certificate chains, and so > forth. Right? > > > I think we should allow an operator to decide which secure transport > > they want to require as a condition of granting access to the SNMP > > service. > > Just the transport protocol name? Or do you want to sub-specify versions, > e.g. SSHv2, TLSv1? If you want to specify IPsec as one of these, do you > need to specify such things as IKEv2? > > I think the devil is in the details. > > If I understand your position correctly, to want to augment the existing > Management-Protocol-Protection attribute, which specifies the level of > security in an abstract fashion, with a reinstated > Management-Transport-Protocol attribute which names the mandated protocol > (and maybe the protocol version). Right? Do you anticipate that there > could be only one of these attributes in a RADIUS Access-Accept message, > or could there be more than one (i.e. acceptable alternatives)? > > That seems to be a middle ground choice, between having only an abstract > assertion about the security level and having all the details and > parameters > related to a secure transport protocol. > > What do others think about this decision point? > > -- Do we need only an abstract security level assertion? > > -- Do we need the transport protocol name? > > -- Do we need the transport protocol version? > > -- Do we need any further details of security parameters? > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms -- 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, 04 Apr 2008 18:47:04 +0000 Message-ID: From: "Bernard Aboba" To: "'David B. Nelson'" , Cc: "'David Harrington'" , "'Jeffrey Hutzelman'" , Subject: RE: [Isms] What granularity of attributes do we need for the secure transport? Date: Fri, 4 Apr 2008 11:46:11 -0700 Message-ID: <000f01c89684$2704bad0$750e3070$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AciWXb72aIumfr7ySgavZNRm18UwfAABfApQAAGnR7AABiAO4A== Content-Language: en-us David Nelson spoke thusly: "My question is whether this sort of configuration of the secure transport protocol is something that needs to be checked by the NAS, using differing criteria, on each and every user authentication? I think that granularity of configuration is generally handled by, well... configuration, and not handled as part of user authorization." With respect to IEEE 802.11 access, there are no RADIUS attributes that specify whether a given user is allowed to do WEP/WPA/WPA2. It is assumed that security is negotiated between the AP and STA based on their configuration. This seems to work OK, particularly since separate SSIDs are typically provisioned for each supported security mechanism, so that user authorization can be handled based on the SSID (provided in the Called-Station-Id). A similar approach might well work here -- we assume that the NAS is set up to allow/require various security mechanisms. It might be useful for the NAS to tell the RADIUS server what security mechanism has been negotiated, and the RADIUS server might Accept/Reject the authentication based on that information as well as the user-name. But there is no notion that the RADIUS server can exercise *control* over what is negotiated -- it is "here is what I'm doing, take it or leave it". -- 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, 04 Apr 2008 10:31:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8963E.FC907E23" Subject: RE: RADEXT WG re-charter Date: Fri, 4 Apr 2008 06:30:24 -0400 Message-ID: Thread-Topic: RADEXT WG re-charter Thread-Index: AciUMMyP4/srMutaQdixNkO0vSekEACDJLtg From: "Stephen Hanna" To: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C8963E.FC907E23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for taking a few days to respond. This looks like a good proposal to me. =20 One nit. The milestone for Extended Attributes says "RC" instead of RFC. =20 Thanks, =20 Steve ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, April 01, 2008 3:41 PM To: radiusext@ops.ietf.org Subject: RADEXT WG re-charter As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. A strawman re-charter proposal is enclosed below. =20 Once comments from WG participants have been incorporated, we will begin a formal WG consensus call on the proposed re-charter by the end of the month.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for=20 particular applications of authentication, authorization and=20 accounting such as NAS management and local area network (LAN) usage.=20 In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. =20 Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: =20 - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. =20 - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. =20 Work Items =20 The immediate goals of the RADEXT working group are to address the following issues: =20 - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. =20 - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP.=20 =20 -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. =20 -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20 relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. =20 - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. =20 - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. =20 Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC ------_=_NextPart_001_01C8963E.FC907E23 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sorry for taking a few days to respond. This looks like = a good=20 proposal to me.
 
One nit. The milestone for Extended Attributes says "RC" = instead=20 of RFC.
 
Thanks,
 
Steve

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Tuesday, April 01, 2008 3:41 PM
To:=20 radiusext@ops.ietf.org
Subject: RADEXT WG=20 re-charter

As we discussed at IETF 71, the RADEXT WG is looking at a=20 re-charter.  A strawman re-charter proposal is enclosed = below. =20
Once comments from WG participants have been incorporated, we will = begin a=20 formal WG consensus call on the proposed
re-charter by the end of the = month.=20
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Description of Working Group:
The RADIUS Extensions Working = Group=20 will focus on extensions to the
RADIUS protocol required to define = extensions=20 to the standard
attribute space as well as to address cryptographic=20 algorithm
agility and use over new secure transports. In addition, = RADEXT=20 will
work on RADIUS Design Guidelines and define new attributes for=20
particular applications of authentication, authorization and =
accounting=20 such as NAS management and local area network (LAN) usage.

In = order to=20 enable interoperation of heterogeneous RADIUS/Diameter
deployments, = all=20 RADEXT WG work items MUST contain a Diameter
compatibility section, = outlining=20 how interoperability with
Diameter will be=20 maintained.
 

Furthermore, to ensure backward = compatibility with=20 existing RADIUS
implementations, as well as compatibility between = RADIUS and=20 Diameter,
the following restrictions are imposed on extensions = considered by=20 the
RADEXT WG:
 

- All RADIUS work MUST be backward = compatible=20 with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, = 3579, 3580,=20 4668-4673,
4675, 5080, 5090 and 5176.
 

- All RADIUS = work MUST=20 be compatible with equivalent facilities in
Diameter. Where possible, = new=20 attributes should be defined so that
the same attribute can be used = in both=20 RADIUS and Diameter without
translation. In other cases a translation = considerations
section should be included in the=20 specification.
 

Work Items
 

The = immediate goals=20 of the RADEXT working group are to address the
following=20 issues:
 

- RADIUS design guidelines. This document will = provide=20 guidelines for
design of RADIUS attributes. It will specifically = consider=20 how
complex data types may be introduced in a robust manner,=20 maintaining
backwards compatibility with existing RADIUS RFCs, across = all=20 the
classes of attributes: Standard, Vendor-Specific and = SDO-Specific.
In=20 addition, it will review RADIUS data types and associated
backwards=20 compatibility issues.
 
- RADIUS Management authorization. = This=20 document will define the
use of RADIUS for NAS management over IP.=20
 

-RADIUS attribute space extension. The standard RADIUS = attribute
space is currently being depleted. This document will=20 provide
additional standard attribute space, while maintaining=20 backward
compatibility with existing = attributes.
 

-RADIUS=20 Cryptographic Algorithm Agility. RADIUS has traditionally
relied on = MD5 for=20 both per-packet integrity and authentication as well
as attribute=20 confidentiality. Given the increasingly successful
attacks being = mounted=20 against MD5, the ability to support
alternative algorithms is = required. This=20 work item will
include documentation of RADIUS crypto-agility=20 requirements,
as well as development of one or more Experimental RFCs = providing
support for negotiation of alternative cryptographic=20 algorithms
to protect RADIUS.
 

- IEEE 802 attributes. = New=20 attributes have been proposed to
support IEEE 802 standards for wired = and=20 wireless LANs. This
work item will support authentication, = authorization=20 and
accounting attributes needed by IEEE 802 groups including
IEEE = 802.1,=20 IEEE 802.11 and IEEE 802.16.
 

- New RADIUS transports. = New=20 secure transports for RADIUS will
be developed, including TCP/TLS = (RADSEC)=20 and UDP/DTLS.

- Documentation of Status-Server usage. A=20 document
describing usage of the Status-Server facility will=20 be
developed.
 

Goals and Milestones:
Jun 2008 = RADIUS=20 Design Guidelines submitted as a Best Current Practice RFC
Jun 2008 = RADIUS=20 Management Authorization I-D submitted as a Proposed Standard RFC
Sep = 2008=20 RADIUS Crypto-agility Requirements submitted as an Informational = RFC
Sep 2008=20 Extended Attributes I-D submitted as a Proposed Standard RC
Dec 2008 = IEEE 802=20 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 = Status-Server=20 I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC draft = submitted as=20 an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an=20 Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D = submitted as an Experimental RFC
------_=_NextPart_001_01C8963E.FC907E23-- -- 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, 04 Apr 2008 07:41:17 +0000 Message-ID: <20080404094014.onnazg7rkc8g0cog@webmail.restena.lu> Date: Fri, 04 Apr 2008 09:40:14 +0200 From: stefan.winter@restena.lu To: radiusext@ops.ietf.org Subject: RE: RADEXT WG re-charter MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) Hi, > Wow. Silence. I have to wonder if the RADEXT WG mailing list server is > broken, or all the RADEXT WG members are on vacation. BTW, infer nothing > from the date on which this message was issued. This is a serious > proposal, not an April Fool's joke. :-) > > Discussion, please? I'm on vacation indeed :-) The proposed text surpasses my expectations. I would have been fine with just taking out the one dash about no new transports. This new text also "fixes" the questions like "Why is DTLS not against the charter, being a new security mechanism?", which have been asked in the past several times, including at IETF-71. The new text has more "truth in advertising" in that respect. The proposed time frame of March 2009 looks plausible to me. 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: Wed, 02 Apr 2008 15:26:49 +0000 Message-ID: <47F3A4BC.9000008@nitros9.org> Date: Wed, 02 Apr 2008 17:22:36 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: RADEXT WG re-charter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Discussion, please? The time frames look a little longer than "ideal". Given the past history of this WG, they should be fine. 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, 02 Apr 2008 14:57:21 +0000 From: "David B. Nelson" To: Subject: RE: RADEXT WG re-charter Date: Wed, 2 Apr 2008 10:55:49 -0400 Message-ID: <039f01c894d1$a4aebd50$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AciUMQZLt2JWXcmmTKuI+NRYeHPQawAn/gww Bernard Aboba writes... > As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. > A strawman re-charter proposal is enclosed below. Wow. Silence. I have to wonder if the RADEXT WG mailing list server is broken, or all the RADEXT WG members are on vacation. BTW, infer nothing from the date on which this message was issued. This is a serious proposal, not an April Fool's joke. :-) Discussion, please? -- 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, 01 Apr 2008 19:42:27 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_3c05b5f9-ef01-411b-bfe3-fc22b7897dd4_" From: Bernard Aboba To: Subject: RADEXT WG re-charter Date: Tue, 1 Apr 2008 12:40:58 -0700 MIME-Version: 1.0 --_3c05b5f9-ef01-411b-bfe3-fc22b7897dd4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. A st= rawman re-charter proposal is enclosed below. =20 Once comments from WG participants have been incorporated, we will begin a = formal WG consensus call on the proposed re-charter by the end of the month.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new secure transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for=20 particular applications of authentication, authorization and=20 accounting such as NAS management and local area network (LAN) usage.=20 In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. =20 Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: =20 - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090 and 5176. =20 - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. =20 Work Items =20 The immediate goals of the RADEXT working group are to address the following issues: =20 - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. =20 - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP.=20 =20 -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. =20 -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally=20 relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. =20 - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. =20 - New RADIUS transports. New secure transports for RADIUS will be developed, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. =20 Goals and Milestones: Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 RADSEC draft submitted as an Experimental RFC June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC= --_3c05b5f9-ef01-411b-bfe3-fc22b7897dd4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As we discussed at IETF 71, the RADEXT WG is looking at a re-charter. = A strawman re-charter proposal is enclosed below. 
Once comments from WG participants have been incorporated, we will begin a = formal WG consensus call on the proposed
re-charter by the end of the month.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Description of Working Group:
The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage.

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.
 

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:
 

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.
 

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
 

Work Items
 

The immediate goals of the RADEXT working group are to address the
following issues:
 

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.
 

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.
 

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.
 

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.
 

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.
 

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC<= BR> Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standa= rd RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational R= FC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC draft submitted as an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experi= mental RFC
 = --_3c05b5f9-ef01-411b-bfe3-fc22b7897dd4_-- -- 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: