Hi Bernard,

=0A

I support adoption of this do= cument as a RADEXT WG work item.

=0A

Regards,<= /DIV>=0A

=0A

Behcet

=0A

=0AFrom: Bernard Aboba <bernard_aboba@hotmail.com&= gt;
To: "radiusext@ops.i= etf.org" <radiusext@ops.ietf.org>
Sent: Wednesday, April 1, 2009 3:14:49 PM
Subject: REMINDER: Call for Adoption of "= RADIUS attributes for IPv6 Access Networks" as a RADEXT WG work item

=0A=0AThis is a reminder of an ongoing call for review of th= e document "RADIUS attributes for IPv6 Access Networks" for adoption as a R= ADEXT WG work item. This document was discussed at IETF 73, and = is being targeted at Proposed Standard status.

The document i= s available for review here:
http://tools= ..ietf.org/html/draft-lourdelet-radext-ipv6-access

= The original call for review completed on March 30, 2009. = However, we only got one comment, so we are extending the review period un= til April 30, 2009.

Please send email to the RADEXT WG mailin= g list indicating whether you support adoption of this document as a RADEXT= WG work item. If you have comments on the document, please also send these to the list in the format described on the RADEXT WG Issue= s list:
http://www.drizzle= ..com/~aboba/RADEXT/

=0A=0A<= TBODY>=0A=0A

=0A=0A --0-586527109-1238625611=:93034-- -- to 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 2 02:19:51 2009 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 8AA523A6A60 for ; Thu, 2 Apr 2009 02:19:51 -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 a5SfK8jwpvOs for ; Thu, 2 Apr 2009 02:19:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C1D83A6A87 for ; Thu, 2 Apr 2009 02:19:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LpJ2C-000GDZ-HO for radiusext-data0@psg.com; Thu, 02 Apr 2009 09:16:28 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LpJ27-000GD6-J5 for radiusext@ops.ietf.org; Thu, 02 Apr 2009 09:16:26 +0000 Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id D3E8A12344BB; Thu, 2 Apr 2009 11:16:21 +0200 (CEST) Message-ID: <49D48265.4000003@deployingradius.com> Date: Thu, 02 Apr 2009 11:16:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: RADIUS over TCP Issues References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > *RADIUS over TCP**Issue Number* > *Status* *Type* *Description* *Owner* > Issue 291 Pending Technical UDP/TCP Translation > > Alan DeKok Resolved. Section 2.5 of the document discusses this. > Issue 292 Pending Technical Applicability > > Alan DeKok Resolved. Section 1.1 of the document contains the updated text. > Issue 293 Pending Technical Watchdog Timer > > Alan DeKok Resolved. Section 2.6.1 contains text about this issue. > Issue 294 No Discussion Technical Document Status > > Bernard Aboba Resolved. The document has been updated to be "experimental". (Modulo one typo) > Issue 295 Pending Technical Head of Line Blocking > > Alan DeKok Resolved. I've added some text to the document discussing this (see below), and will issue a new revision shortly. When using UDP as a transport for RADIUS, there is no ordering of packets. If a packet sent by a client is lost, that loss has no effect on subsequent packets sent by that client. Unlike UDP, TCP is subject to issues related to Head of Line (HoL) blocking. This occurs when when a TCP segment is lost and a subsequent TCP segment arrives out of order. While the RADIUS server can process RADIUS packets out of order, the semantics of TCP makes this impossible. This limitation can lower the maximum packet processing rate of RADIUS over TCP. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Apr 2 02:27:13 2009 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 078253A6931 for ; Thu, 2 Apr 2009 02:27:13 -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 kLIVkSsfUXXF for ; Thu, 2 Apr 2009 02:27:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BCF23A68E6 for ; Thu, 2 Apr 2009 02:27:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LpJAO-000Gd3-EN for radiusext-data0@psg.com; Thu, 02 Apr 2009 09:24:56 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LpJAJ-000Gcc-Gq for radiusext@ops.ietf.org; Thu, 02 Apr 2009 09:24:54 +0000 Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 4DBF612344BB; Thu, 2 Apr 2009 11:24:50 +0200 (CEST) Message-ID: <49D48462.10201@deployingradius.com> Date: Thu, 02 Apr 2009 11:24:50 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: Status Server Issues Update References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Currently the Issues list shows the following open issue on the Status > Server document: > > *Status Server* *Issue Number* > *Status* *Type* *Description* *Owner* > Issue 285 Pending Technical Question > > Alan DeKok Resolved. The CoA text has been removed from the document. > Issue 288 Pending Technical Review > > Stig Venaas The current document contains the suggested text from the discussion. > Issue 289 No Discussion Editorial Editorial Comments > > Stig Venaas The current document contains fixes for all of Stigs comments. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Apr 2 19:48:46 2009 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 6C51A3A6B83 for ; Thu, 2 Apr 2009 19:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.493 X-Spam-Level: X-Spam-Status: No, score=-1.493 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 X4RJY6HFXCgt for ; Thu, 2 Apr 2009 19:48:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 313803A685E for ; Thu, 2 Apr 2009 19:48:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LpZOx-000O9f-Ts for radiusext-data0@psg.com; Fri, 03 Apr 2009 02:45:03 +0000 Received: from [76.96.62.48] (helo=QMTA05.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LpZOs-000O8W-8z for radiusext@ops.ietf.org; Fri, 03 Apr 2009 02:45:00 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA05.westchester.pa.mail.comcast.net with comcast id ak5M1b00e0cZkys55qkxZm; Fri, 03 Apr 2009 02:44:57 +0000 Received: from gwzPC ([124.120.227.98]) by OMTA10.westchester.pa.mail.comcast.net with comcast id aqki1b00a280u4k3Wqkn21; Fri, 03 Apr 2009 02:44:55 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: References: In-Reply-To: Subject: RE: REMINDER: Call for Adoption of "RADIUS attributes for IPv6 Access Networks" as a RADEXT WG work item Date: Fri, 3 Apr 2009 09:44:02 +0700 Message-ID: <001701c9b406$14635f30$3d2a1d90$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C9B440.C0C23730" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcmzBtHuTumyt5qAT8G4IWa7ilaLLQA/yH7g Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. ------=_NextPart_000_0018_01C9B440.C0C23730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a reminder of an ongoing call for review of the document "RADIUS attributes for IPv6 Access Networks" for adoption as a RADEXT WG work item. This document was discussed at IETF 73, and is being targeted at Proposed Standard status. The document is available for review here: http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access The original call for review completed on March 30, 2009. However, we only got one comment, so we are extending the review period until April 30, 2009. Please send email to the RADEXT WG mailing list indicating whether you support adoption of this document as a RADEXT WG work item. OK w/me. If you have comments on the document, please also send these to the list in the format described on the RADEXT WG Issues list: http://www.drizzle.com/~aboba/RADEXT/ ------=_NextPart_000_0018_01C9B440.C0C23730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a reminder of an ongoing = call for review of the document "RADIUS attributes for IPv6 Access = Networks" for adoption as a RADEXT WG work item. This document = was discussed at IETF 73, and is being targeted at Proposed Standard status.

The document is available for review here:
http://tools.ietf.org/html/draft-lourdelet-radext= -ipv6-access

The original call for review completed on March 30, = 2009. However, we only got one comment, so we are extending the review period = until April 30, 2009.

Please send email to the RADEXT WG mailing list indicating whether you = support adoption of this document as a RADEXT WG work item.

OK = w/me.

If you have comments on the = document, please also send these to the list in the format described on the RADEXT = WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/<= o:p>

------=_NextPart_000_0018_01C9B440.C0C23730-- -- to 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 7 03:24:39 2009 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 482AD3A67EC for ; Tue, 7 Apr 2009 03:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.413 X-Spam-Level: X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=-0.919, 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 WzZG7QtacT2t for ; Tue, 7 Apr 2009 03:24:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FBF63A67D8 for ; Tue, 7 Apr 2009 03:24:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lr8PP-000E9S-HC for radiusext-data0@psg.com; Tue, 07 Apr 2009 10:19:59 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lr8P8-000E8D-Fo for radiusext@ops.ietf.org; Tue, 07 Apr 2009 10:19:46 +0000 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n37AJWCm006856; Tue, 7 Apr 2009 13:19:35 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 13:19:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 13:19:20 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 7 Apr 2009 12:19:19 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Tue, 7 Apr 2009 12:19:19 +0200 From: To: , Date: Tue, 7 Apr 2009 12:19:27 +0200 Subject: RE: Crypto-agility transition model Thread-Topic: Crypto-agility transition model Thread-Index: Acmy/7ZuddlUQH4xT5aFROkaDPhIkgEaiyFA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F22153B3@NOK-EUMSG-01.mgdnok.nokia.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_808FD6E27AD4884E94820BC333B2DB7727F22153B3NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2009 10:19:20.0246 (UTC) FILETIME=[508ACD60:01C9B76A] X-Nokia-AV: Clean Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_808FD6E27AD4884E94820BC333B2DB7727F22153B3NOKEUMSG01mgd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bernard, Items #1..#4 seem to provide one reasonable transition model, and in partic= ular, the assumptions in #2 would make my comment about "Compromise of lega= cy shared secret" largely moot. About #6: is this intended to be an assumption (we assume that administrato= rs never use shared secrets they can remember), a requirement for administrators (basically unenforceable, and putting admini= strator requirements in RFCs intended for implementors probably isn't very = effective anyway since the administrators won't read this), or a protocol r= equirement (given realistic assumptions about administrators, the protocol = must prevent brute-force attacks)? #7 certainly looks like an assumption or somewhat misplaced and unenforceab= le requirement (although in theory, we could require that management interf= aces enforce unique credentials -- but probably implementors would ignore t= hat requirement). Best regards, Pasi ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of ext Bernard Aboba Sent: 01 April, 2009 22:25 To: radiusext@ops.ietf.org Subject: Crypto-agility transition model At IETF 74, we discussed Pasi Eronen's review of the RADIUS Crypto-agility = requirements document. Several of the issues that arose related to the tra= nsition model. My proposal is that we explicitly discuss the envisaged tra= nsition model in the document. One proposal for a transition model is encl= osed below. Comments solicited. 1. The transition model for RADIUS crypto-agility issues that the RADIUS s= erver is upgraded first, and that RADIUS clients are then upgraded over tim= e. This implies that we can assume that the RADIUS server is crypto-agile = from day 1, and that there are a mixture of capable and non-capable RADIUS = clients until all RADIUS clients have been upgraded to support upgraded ope= ration. 2. Once all RADIUS clients have been upgraded, it is assumed that the RADIU= S server is set to require all RADIUS clients to utilize upgraded ciphersui= tes. Furthermore it is assumed that the transition is completed prior to t= he time at which MD5 security is compromised. For the purposes of the requ= irements document, such as breach would be considered to enable the forgery= of RADIUS packets protected by existing ciphersuites (e.g. MD5, HMAC-MD5).= Once such a forgery becomes possible, packets protected by legacy ciphers= uites can no longer be trusted and therefore it is no longer feasible to al= low use of legacy ciphersuites to integrity protect RADIUS packets. One co= rollary of this assumption is that the use of MD5/HMAC-MD5 to protect a cip= hersuite "negotiation" is acceptable during the transition period. 3. During the transition period, it is assumed that each RADIUS client util= izing legacy ciphersuites is provisioned with a unique legacy shared secret= . If this assumption holds true, then during the transition period, it is = possible for the RADIUS server to authenticate a legacy RADIUS client's ide= ntity and apply appropriate per-client policies (see #4 below). 4. During the transition period, the RADIUS server is required to support a= ccess both by legacy RADIUS clients as well as upgraded RADIUS clients. Se= cure operation during the transition period can be accomplished in one of t= wo ways: a. RADIUS server policy. If a RADIUS client is known to be upgraded, t= he RADIUS server can require that this RADIUS client operate in the upgrade= d mode. This assumes that an upgraded RADIUS client cannot masquerade as a= legacy RADIUS client so as to evade the policy (see the assumptions in #2 = and #3). Note that if an upgraded ciphersuite requires provisioning of new= pre-shared keys on the RADIUS server, then client-specific configuration w= ill probably be needed anyway. b. "Negotiation". If the administrator does not wish to keep track of = which specific RADIUS clients have been upgraded, then he/she can enable th= e RADIUS server to accept use of upgraded ciphersuites from RADIUS clients = that offer it as well as to accept use of legacy ciphersuites. Based on th= e assumptions in #2, it is acceptable for such an offer to only be protecte= d by a legacy shared secret during the transition period. 5. It is REQUIRED that compromise of the legacy shared secret not result i= n compromise of shared secrets or session keys used by any of the upgraded = ciphersuites. This is required since we need to assume that an attacker c= ould have captured previous RADIUS exchanges that could enable recovery of = the legacy shared secret in the future. Therefore even if legacy ciphersui= tes were no longer in use, compromise of upgraded RADIUS clients and server= s would be still be possible if compromise of legacy shared secrets could e= nable attacks on upgraded ciphersuites. 6. It is REQUIRED that keys utilized by upgraded ciphersuites be sufficient= ly strong to prevent attacks by brute force. If we don't make this assumpt= ion, then negotiation of upgraded cryptographic algorithms is pointless. 7. It is REQUIRED that administrators assign unique credentials to RADIUS = clients for use with upgraded ciphersuites. If this is not done then RADI= US servers may not be able to distinguish upgraded RADIUS clients from one = another. This could prevent RADIUS servers from correctly applying securit= y policies to upgraded RADIUS clients (e.g. RADIUS server wouldn't be able = to distinguish NAS A that supports Ciphersuite A and B from NAS B that only= supports Ciphersuite B). --_000_808FD6E27AD4884E94820BC333B2DB7727F22153B3NOKEUMSG01mgd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bernard,

Items #1..#4 seem to provide one reasonable transition mode= l, and=20 in particular, the assumptions in #2 would make my comment about "Compromis= e of=20 legacy shared secret" largely moot.

About #6: is this intended to be an assumption (we assume t= hat=20 administrators never use shared secrets they can remember), a
requiremen= t for=20 administrators (basically unenforceable, and putting administrator requirem= ents=20 in RFCs intended for implementors probably isn't very effective anyway sinc= e the=20 administrators won't read this), or a protocol requirement (given realistic= =20 assumptions about administrators, the protocol must prevent brute-force=20 attacks)?

#7 certainly looks like an assumption or somewhat misplaced= and=20 unenforceable requirement (although in theory, we could require that manage= ment=20 interfaces enforce unique credentials -- but probably implementors would ig= nore=20 that requirement).

Best regards,

Pasi

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of ext Bernard=20 Aboba
Sent: 01 April, 2009 22:25
To:=20 radiusext@ops.ietf.org
Subject: Crypto-agility transition=20 model

At IETF 74, we discussed Pasi Eronen's review of the RADIUS=20 Crypto-agility requirements document. Several of the issues that ar= ose=20 related to the transition model. My proposal is that we explicitly= =20 discuss the envisaged transition model in the document. One proposa= l for=20 a transition model is enclosed below. Comments solicited.=20

1. The transition model for RADIUS crypto-agility issues th= at=20 the RADIUS server is upgraded first, and that RADIUS clients are then upg= raded=20 over time. This implies that we can assume that the RADIUS server i= s=20 crypto-agile from day 1, and that there are a mixture of capable and=20 non-capable RADIUS clients until all RADIUS clients have been upgraded to= =20 support upgraded operation.

2. Once all RADIUS clients have= been=20 upgraded, it is assumed that the RADIUS server is set to require all RADI= US=20 clients to utilize upgraded ciphersuites. Furthermore it is assumed= that=20 the transition is completed prior to the time at which MD5 security is=20 compromised. For the purposes of the requirements document, such as= =20 breach would be considered to enable the forgery of RADIUS packets protec= ted=20 by existing ciphersuites (e.g. MD5, HMAC-MD5). Once such a forgery= =20 becomes possible, packets protected by legacy ciphersuites can no longer = be=20 trusted and therefore it is no longer feasible to allow use of legacy=20 ciphersuites to integrity protect RADIUS packets. One corollary of = this=20 assumption is that the use of MD5/HMAC-MD5 to protect a ciphersuite=20 "negotiation" is acceptable during the transition period.

3. Duri= ng=20 the transition period, it is assumed that each RADIUS client utilizing le= gacy=20 ciphersuites is provisioned with a unique legacy shared secret. If = this=20 assumption holds true, then during the transition period, it is possible = for=20 the RADIUS server to authenticate a legacy RADIUS client's identity and a= pply=20 appropriate per-client policies (see #4 below).

4. During the=20 transition period, the RADIUS server is required to support access both b= y=20 legacy RADIUS clients as well as upgraded RADIUS clients. Secure=20 operation during the transition period can be accomplished in one of two= =20 ways:
    a. RADIUS server policy. If a RADIUS cl= ient=20 is known to be upgraded, the RADIUS server can require that this RADIUS c= lient=20 operate in the upgraded mode. This assumes that an upgraded RADIUS= =20 client cannot masquerade as a legacy RADIUS client so as to evade the pol= icy=20 (see the assumptions in #2 and #3). Note that if an upgraded cipher= suite=20 requires provisioning of new pre-shared keys on the RADIUS server, then=20 client-specific configuration will probably be needed anyway.=20

    b. "Negotiation". If the administrator d= oes=20 not wish to keep track of which specific RADIUS clients have been upgrade= d,=20 then he/she can enable the RADIUS server to accept use of upgraded=20 ciphersuites from RADIUS clients that offer it as well as to accept use o= f=20 legacy ciphersuites. Based on the assumptions in #2, it is acceptab= le=20 for such an offer to only be protected by a legacy shared secret during t= he=20 transition period.

5. It is REQUIRED that compromise = of=20 the legacy shared secret not result in compromise of shared secrets or se= ssion=20 keys used by any of the upgraded ciphersuites.   This is requir= ed=20 since we need to assume that an attacker could have captured previous RAD= IUS=20 exchanges that could enable recovery of the legacy shared secret in the=20 future. Therefore even if legacy ciphersuites were no longer in use= ,=20 compromise of upgraded RADIUS clients and servers would be still be possi= ble=20 if compromise of legacy shared secrets could enable attacks on upgraded=20 ciphersuites.

6. It is REQUIRED that keys utilized by upgraded=20 ciphersuites be sufficiently strong to prevent attacks by brute force.&nb= sp;=20 If we don't make this assumption, then negotiation of upgraded cryptograp= hic=20 algorithms is pointless.

7. It is REQUIRED that administrat= ors=20 assign unique credentials to RADIUS clients for use with upgraded=20 ciphersuites.   If this is not done then RADIUS servers may not= be=20 able to distinguish upgraded RADIUS clients from one another. This = could=20 prevent RADIUS servers from correctly applying security policies to upgra= ded=20 RADIUS clients (e.g. RADIUS server wouldn't be able to distinguish NAS A = that=20 supports Ciphersuite A and B from NAS B that only supports Ciphersuite B)= .=20

--_000_808FD6E27AD4884E94820BC333B2DB7727F22153B3NOKEUMSG01mgd_-- -- to 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 7 09:26:03 2009 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 048B93A6832 for ; Tue, 7 Apr 2009 09:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=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 SO6uvlBQ7zYl for ; Tue, 7 Apr 2009 09:26:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B766A3A682D for ; Tue, 7 Apr 2009 09:26:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LrE3H-00092N-KW for radiusext-data0@psg.com; Tue, 07 Apr 2009 16:21:31 +0000 Received: from blu0-omc3-s29.blu0.hotmail.com ([65.55.116.104]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LrE39-00091x-Py for radiusext@ops.ietf.org; Tue, 07 Apr 2009 16:21:27 +0000 Received: from BLU137-W7 ([65.55.116.73]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 09:21:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b01649e3-698b-4060-b577-e96afbb353e6_" X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: , "radiusext@ops.ietf.org" Subject: RE: Crypto-agility transition model Date: Tue, 7 Apr 2009 09:21:19 -0700 Importance: Normal In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F22153B3@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F22153B3@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2009 16:21:19.0771 (UTC) FILETIME=[E2634EB0:01C9B79C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_b01649e3-698b-4060-b577-e96afbb353e6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable #7 is an assumption=2C albeit a somewhat optimistic one. Amazing how many o= perators actually deploy RADIUS with a single shared secret for all RADIUS = clients. RFC 2865 does refer to the possibility that a RADIUS client would= have the same shared secret with multiple servers in the same realm.=20 #6 would be a protocol requirement if the keys were derived. If the keys a= re chosen to the administrator=2C it is largely an assumption about adminis= trator behavior with some implications for implementers. As an example=2C = RFC 2865 Section 3 contains some advice relating to the strength of the leg= acy shared secret that would have implications for the minimum supported si= ze of the shared secret field: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- chosen password. It is preferred that the secret be at least 16 octets. This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged. From: Pasi.Eronen@nokia.com To: bernard_aboba@hotmail.com=3B radiusext@ops.ietf.org Date: Tue=2C 7 Apr 2009 12:19:27 +0200 Subject: RE: Crypto-agility transition model Hi Bernard=2C =20 Items #1..#4 seem to provide one reasonable transition model=2C and=20 in particular=2C the assumptions in #2 would make my comment about "Comprom= ise of=20 legacy shared secret" largely moot. =20 About #6: is this intended to be an assumption (we assume that=20 administrators never use shared secrets they can remember)=2C a requirement for=20 administrators (basically unenforceable=2C and putting administrator requir= ements=20 in RFCs intended for implementors probably isn't very effective anyway sinc= e the=20 administrators won't read this)=2C or a protocol requirement (given realist= ic=20 assumptions about administrators=2C the protocol must prevent brute-force=20 attacks)? =20 #7 certainly looks like an assumption or somewhat misplaced and=20 unenforceable requirement (although in theory=2C we could require that mana= gement=20 interfaces enforce unique credentials -- but probably implementors would ig= nore=20 that requirement). Best regards=2C Pasi =20 =20 From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of ext Bernard=20 Aboba Sent: 01 April=2C 2009 22:25 To:=20 radiusext@ops.ietf.org Subject: Crypto-agility transition=20 model At IETF 74=2C we discussed Pasi Eronen's review of the RADIUS=20 Crypto-agility requirements document. Several of the issues that arose=20 related to the transition model. My proposal is that we explicitly=20 discuss the envisaged transition model in the document. One proposal for= =20 a transition model is enclosed below. Comments solicited.=20 =20 1. The transition model for RADIUS crypto-agility issues that=20 the RADIUS server is upgraded first=2C and that RADIUS clients are then u= pgraded=20 over time. This implies that we can assume that the RADIUS server is=20 crypto-agile from day 1=2C and that there are a mixture of capable and=20 non-capable RADIUS clients until all RADIUS clients have been upgraded to= =20 support upgraded operation. =20 2. Once all RADIUS clients have been=20 upgraded=2C it is assumed that the RADIUS server is set to require all RA= DIUS=20 clients to utilize upgraded ciphersuites. Furthermore it is assumed that= =20 the transition is completed prior to the time at which MD5 security is=20 compromised. For the purposes of the requirements document=2C such as=20 breach would be considered to enable the forgery of RADIUS packets protec= ted=20 by existing ciphersuites (e.g. MD5=2C HMAC-MD5). Once such a forgery=20 becomes possible=2C packets protected by legacy ciphersuites can no longe= r be=20 trusted and therefore it is no longer feasible to allow use of legacy=20 ciphersuites to integrity protect RADIUS packets. One corollary of this= =20 assumption is that the use of MD5/HMAC-MD5 to protect a ciphersuite=20 "negotiation" is acceptable during the transition period.=20 3. During=20 the transition period=2C it is assumed that each RADIUS client utilizing = legacy=20 ciphersuites is provisioned with a unique legacy shared secret. If this= =20 assumption holds true=2C then during the transition period=2C it is possi= ble for=20 the RADIUS server to authenticate a legacy RADIUS client's identity and a= pply=20 appropriate per-client policies (see #4 below). 4. During the=20 transition period=2C the RADIUS server is required to support access both= by=20 legacy RADIUS clients as well as upgraded RADIUS clients. Secure=20 operation during the transition period can be accomplished in one of two= =20 ways: a. RADIUS server policy. If a RADIUS client=20 is known to be upgraded=2C the RADIUS server can require that this RADIUS= client=20 operate in the upgraded mode. This assumes that an upgraded RADIUS=20 client cannot masquerade as a legacy RADIUS client so as to evade the pol= icy=20 (see the assumptions in #2 and #3). Note that if an upgraded ciphersuite= =20 requires provisioning of new pre-shared keys on the RADIUS server=2C then= =20 client-specific configuration will probably be needed anyway.=20 =20 b. "Negotiation". If the administrator does=20 not wish to keep track of which specific RADIUS clients have been upgrade= d=2C=20 then he/she can enable the RADIUS server to accept use of upgraded=20 ciphersuites from RADIUS clients that offer it as well as to accept use o= f=20 legacy ciphersuites. Based on the assumptions in #2=2C it is acceptable= =20 for such an offer to only be protected by a legacy shared secret during t= he=20 transition period. =20 5. It is REQUIRED that compromise of=20 the legacy shared secret not result in compromise of shared secrets or se= ssion=20 keys used by any of the upgraded ciphersuites. This is required=20 since we need to assume that an attacker could have captured previous RAD= IUS=20 exchanges that could enable recovery of the legacy shared secret in the=20 future. Therefore even if legacy ciphersuites were no longer in use=2C=20 compromise of upgraded RADIUS clients and servers would be still be possi= ble=20 if compromise of legacy shared secrets could enable attacks on upgraded=20 ciphersuites.=20 6. It is REQUIRED that keys utilized by upgraded=20 ciphersuites be sufficiently strong to prevent attacks by brute force. =20 If we don't make this assumption=2C then negotiation of upgraded cryptogr= aphic=20 algorithms is pointless.=20 7. It is REQUIRED that administrators=20 assign unique credentials to RADIUS clients for use with upgraded=20 ciphersuites. If this is not done then RADIUS servers may not be=20 able to distinguish upgraded RADIUS clients from one another. This could= =20 prevent RADIUS servers from correctly applying security policies to upgra= ded=20 RADIUS clients (e.g. RADIUS server wouldn't be able to distinguish NAS A = that=20 supports Ciphersuite A and B from NAS B that only supports Ciphersuite B)= .=20 =20 =20 =20 =20 =20 --_b01649e3-698b-4060-b577-e96afbb353e6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable #7 is an assumption=2C albeit a somewhat optimistic one. Amazing how many o= perators actually deploy RADIUS with a single shared secret for all RADIUS = clients. =3B RFC 2865 does refer to the possibility that a RADIUS clien= t would have the same shared secret with multiple servers in the same realm= .

#6 would be a protocol requirement if the keys were derived. = =3B If the keys are chosen to the administrator=2C it is largely an assumpt= ion about administrator behavior with some implications for implementers.&n= bsp=3B As an example=2C RFC 2865 Section 3 contains some advice relating to= the strength of the legacy shared secret that would have implications for = the minimum supported size of the shared secret field:

      Th=
e secret (password shared between the client and the RADIUS
      server=
) SHOULD be at least as large and unguessable as a well-
      chosen pa=
ssword.  It is preferred that the secret be at least 16
      octets.  T=
his is to ensure a sufficiently large range for the
      secret to prov=
ide protection against exhaustive search attacks.
      The secret MUST =
NOT be empty (length 0) since this would allow
      packets to be trivi=
ally forged.

From: Pasi.Eronen@nok= ia.com
To: bernard_aboba@hotmail.com=3B radiusext@ops.ietf.org
Date: = Tue=2C 7 Apr 2009 12:19:27 +0200
Subject: RE: Crypto-agility transition = model

Hi Bernard=2C

=3B

Items #1..#4 seem to provide one reasonab= le transition model=2C and=20 in particular=2C the assumptions in #2 would make my comment about "Comprom= ise of=20 legacy shared secret" largely moot.

=3B

About #6: is this intended to be an assum= ption (we assume that=20 administrators never use shared secrets they can remember)=2C a
requirem= ent for=20 administrators (basically unenforceable=2C and putting administrator requir= ements=20 in RFCs intended for implementors probably isn't very effective anyway sinc= e the=20 administrators won't read this)=2C or a protocol requirement (given realist= ic=20 assumptions about administrators=2C the protocol must prevent brute-force=20 attacks)?

=3B

#7 certainly looks like an assumption or = somewhat misplaced and=20 unenforceable requirement (although in theory=2C we could require that mana= gement=20 interfaces enforce unique credentials -- but probably implementors would ig= nore=20 that requirement).

Best regards=2C

Pasi

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of ext Bernard=20 Aboba
Sent: 01 April=2C 2009 22:25
To:=20 radiusext@ops.ietf.org
Subject: Crypto-agility transition=20 model

At IETF 74=2C we discussed Pasi Eronen's review of the RADIUS= =20 Crypto-agility requirements document. =3B Several of the issues that = arose=20 related to the transition model. =3B My proposal is that we explicitl= y=20 discuss the envisaged transition model in the document. =3B One propo= sal for=20 a transition model is enclosed below. =3B Comments solicited.=20

1. =3B The transition model for RADIUS crypto-agility issues = that=20 the RADIUS server is upgraded first=2C and that RADIUS clients are then u= pgraded=20 over time. =3B This implies that we can assume that the RADIUS server= is=20 crypto-agile from day 1=2C and that there are a mixture of capable and=20 non-capable RADIUS clients until all RADIUS clients have been upgraded to= =20 support upgraded operation. =3B

2. Once all RADIUS clients ha= ve been=20 upgraded=2C it is assumed that the RADIUS server is set to require all RA= DIUS=20 clients to utilize upgraded ciphersuites. =3B Furthermore it is assum= ed that=20 the transition is completed prior to the time at which MD5 security is=20 compromised. =3B For the purposes of the requirements document=2C suc= h as=20 breach would be considered to enable the forgery of RADIUS packets protec= ted=20 by existing ciphersuites (e.g. MD5=2C HMAC-MD5). =3B Once such a forg= ery=20 becomes possible=2C packets protected by legacy ciphersuites can no longe= r be=20 trusted and therefore it is no longer feasible to allow use of legacy=20 ciphersuites to integrity protect RADIUS packets. =3B One corollary o= f this=20 assumption is that the use of MD5/HMAC-MD5 to protect a ciphersuite=20 "negotiation" is acceptable during the transition period.

3. Duri= ng=20 the transition period=2C it is assumed that each RADIUS client utilizing = legacy=20 ciphersuites is provisioned with a unique legacy shared secret. =3B I= f this=20 assumption holds true=2C then during the transition period=2C it is possi= ble for=20 the RADIUS server to authenticate a legacy RADIUS client's identity and a= pply=20 appropriate per-client policies (see #4 below).

4. During the=20 transition period=2C the RADIUS server is required to support access both= by=20 legacy RADIUS clients as well as upgraded RADIUS clients. =3B Secure= =20 operation during the transition period can be accomplished in one of two= =20 ways:
=3B =3B =3B a. RADIUS server policy. =3B If a R= ADIUS client=20 is known to be upgraded=2C the RADIUS server can require that this RADIUS= client=20 operate in the upgraded mode. =3B This assumes that an upgraded RADIU= S=20 client cannot masquerade as a legacy RADIUS client so as to evade the pol= icy=20 (see the assumptions in #2 and #3). =3B Note that if an upgraded ciph= ersuite=20 requires provisioning of new pre-shared keys on the RADIUS server=2C then= =20 client-specific configuration will probably be needed anyway.=20

=3B =3B =3B b. "Negotiation". =3B If the adminis= trator does=20 not wish to keep track of which specific RADIUS clients have been upgrade= d=2C=20 then he/she can enable the RADIUS server to accept use of upgraded=20 ciphersuites from RADIUS clients that offer it as well as to accept use o= f=20 legacy ciphersuites. =3B Based on the assumptions in #2=2C it is acce= ptable=20 for such an offer to only be protected by a legacy shared secret during t= he=20 transition period. =3B

5. =3B It is REQUIRED that comprom= ise of=20 the legacy shared secret not result in compromise of shared secrets or se= ssion=20 keys used by any of the upgraded ciphersuites. =3B =3B This is re= quired=20 since we need to assume that an attacker could have captured previous RAD= IUS=20 exchanges that could enable recovery of the legacy shared secret in the=20 future. =3B Therefore even if legacy ciphersuites were no longer in u= se=2C=20 compromise of upgraded RADIUS clients and servers would be still be possi= ble=20 if compromise of legacy shared secrets could enable attacks on upgraded=20 ciphersuites.

6. It is REQUIRED that keys utilized by upgraded=20 ciphersuites be sufficiently strong to prevent attacks by brute force.&nb= sp=3B=20 If we don't make this assumption=2C then negotiation of upgraded cryptogr= aphic=20 algorithms is pointless.

7. =3B It is REQUIRED that administr= ators=20 assign unique credentials to RADIUS clients for use with upgraded=20 ciphersuites. =3B =3B If this is not done then RADIUS servers may= not be=20 able to distinguish upgraded RADIUS clients from one another. =3B Thi= s could=20 prevent RADIUS servers from correctly applying security policies to upgra= ded=20 RADIUS clients (e.g. RADIUS server wouldn't be able to distinguish NAS A = that=20 supports Ciphersuite A and B from NAS B that only supports Ciphersuite B)= .=20

= --_b01649e3-698b-4060-b577-e96afbb353e6_-- -- to 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 7 22:02:02 2009 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 362443A6A3F for ; Tue, 7 Apr 2009 22:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.751 X-Spam-Level: X-Spam-Status: No, score=-7.751 tagged_above=-999 required=5 tests=[AWL=-1.334, 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, SUBJ_ALL_CAPS=2.077] 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 OBzkD1TmnA9q for ; Tue, 7 Apr 2009 22:01:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08FDA3A67CC for ; Tue, 7 Apr 2009 22:01:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LrPpb-000MRu-Ob for radiusext-data0@psg.com; Wed, 08 Apr 2009 04:56:11 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LrPpT-000MRH-Hl for radiusext@ops.ietf.org; Wed, 08 Apr 2009 04:56:07 +0000 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 7 Apr 2009 21:56:03 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.2.99.4; Tue, 7 Apr 2009 21:56:03 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Tue, 7 Apr 2009 21:58:53 -0700 From: Anthony Leibovitz To: "radiusext@ops.ietf.org" Date: Tue, 7 Apr 2009 21:56:01 -0700 Subject: RE: DRAFT-IETF-GEOPRIV-RADIUS-LO-23 Thread-Topic: DRAFT-IETF-GEOPRIV-RADIUS-LO-23 Thread-Index: Acm4BdFGtpXH/5Z/TsyC/9LcCJX+WwAAHQcg Message-ID: <180B3E3BF11C4B4581E20A837620FAF0176FEF246C@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> 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_180B3E3BF11C4B4581E20A837620FAF0176FEF246CNAEXMSGW601wi_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_180B3E3BF11C4B4581E20A837620FAF0176FEF246CNAEXMSGW601wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TO WHOM IT MAY CONCERN: I have read draft-ietf-geopriv-radius-lo-23 and have the following concerns= about it: a. Confusion with existing functionality. As defined in RFC 2865, t= he RADIUS protocol REQUIRES that NAS identification attributes be present i= n a RADIUS Access-Request. When combined with a wiremap, these attributes = (such as NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address) provide infor= mation on the NAS location, which can be used to infer the user location in= a number of common scenarios (e.g. IEEE 802 network access as envisaged in= RFC 3580). Given this pre-existing support for location, it was surprisi= ng for me to read Section 1, which presents the functionality of this docum= ent as though it were new (e.g. "This document defines attributes... that c= an be used to convey location-related information..."). At a minimum, Sec= tion 1 needs to describe the existing RADIUS location functionality, and cl= early delineate the additional value provided by the attributes described i= n the document. b. Confusion about privacy requirements. Given that RADIUS has always= supported transmission of information relating to user location, and indee= d, the transmission of this information is REQUIRED in every access request= , there are a number of statements in the document which appear to represen= t major changes to RFC 2865, even though this document does not indicate th= at it updates RFC 2865. As an example, Section 1 states that "location inf= ormation needs to be protected against unauthorized access and distribution= ", yet nowhere in the document are the implications of this statement for t= he RADIUS protocol laid out. Does this statement apply only to the attribut= es defined in the document, or does it apply to the NAS Identification attr= ibutes defined in RFC 2865? Do the security requirements outlined in Secti= on 7 apply to any use of RADIUS, or just to the attributes in this document= ? The document is unclear on this point; it needs to state clearly whether= the privacy requirements and rules functionality applies only to uses of t= he attributes defined in this document, or to any use of RADIUS. c. Confusion about the meaning of "retransmission allowed". As note= d in draft-ietf-geopriv-sip-lo-retransmission as well as in recent discussi= ons on the GEOPRIV WG mailing list, there is confusion about the meaning of= "retransmission allowed". Since RFC 2865 requires the inclusion of NAS i= dentification in a RADIUS Access-Request, re-transmission of information re= lated to user-location is an integral part of the network access authentica= tion and authorization process. As a result, restrictions on the ability = of a RADIUS proxy to retransmit location information to a RADIUS server are= inherently non-deployable. In addition, many RADIUS proxies will treat at= tributes they do not understand as opaque blobs, and so are inherently unab= le to parse or act upon privacy policies. However, on reading this docume= nt, I had many of the same questions as were raised in draft-ietf-geopriv-l= o-retransmission with respect to SIP conveyance, as to whether privacy poli= cies applied to RADIUS conveyance. Some of this confusion was enhanced by= Section A.2, entitled "Distribution of location information at the Visited= Network". Is the issue really distribution of location information within= the RADIUS realms on the roaming relationship path, or is it retransmissio= n of location information outside those entities? This is a critical poin= t - but one that the document leaves unclear. d. Consistency with RADIUS architecture. With respect to privacy poli= cies, it is unclear whether draft-ietf-geopriv-radius-lo-23 requires RADIUS= proxies to inspect RADIUS attributes prior to re-transmission, to understa= nd that certain RADIUS attributes contain location information and to imple= ment policies encoded within those attributes. If so, this would be an omin= ous and undesirable requirement to place on RADIUS implementations because = RADIUS servers need not have explicit knowledge of the all attributes they = transmit or re-transmit. Such a requirement would be even more undesirable = in multi-vendor deployments where RADIUS interoperability is required. e. Implications for RADIUS accounting and billing. RADIUS accounting = data - which includes location-related information - is commonly made avail= able to RADIUS proxies and servers today. In some cases, RADIUS accounting= data is stored on the visited network proxy and in other cases, the RADIUS= accounting data is forwarded to an intermediate or home realm for storage = in a database. When 're-transmission allowed' is set to 0 (the default), d= oes this mean that RADIUS accounting data that includes location informatio= n cannot be re-transmitted to another realm? If so, then this document wou= ld disrupt the transmission of accounting data which is legally required to= be maintained by statues such as Sarbanes Oxley. Thanks, Anthony Leibovitz Principal Program Manager Microsoft Corporation --_000_180B3E3BF11C4B4581E20A837620FAF0176FEF246CNAEXMSGW601wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TO WHOM IT MAY CONCERN:

I have read draft-ietf-geopriv-radius-lo-23 and have th= e following concerns about it:

<= ![if !supportLists]>a.&n= bsp; Confusion with existing functionality. As defined in RFC 2865, the RADIUS protocol REQUIRES that NAS identification attributes be present in a RADIUS Access-Request. When combined with = a wiremap, these attributes (such as NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address) provide information on the NAS location, which can be use= d to infer the user location in a number of common scenarios (e.g. IEEE 802 netw= ork access as envisaged in RFC 3580). Given this pre-existing suppo= rt for location, it was surprising for me to read Section 1, which presents th= e functionality of this document as though it were new (e.g. “This docu= ment defines attributes… that can be used to convey location-related information…”). At a minimum, Section 1 needs to de= scribe the existing RADIUS location functionality, and clearly delineate the additiona= l value provided by the attributes described in the document.

<= ![if !supportLists]>b.&n= bsp; Confusion about privacy requirements. Given that RADIUS has always supported transmission of information relating to user location, and indeed, the transmission of this information is REQUIRED in e= very access request, there are a number of statements in the document which appe= ar to represent major changes to RFC 2865, even though this document does not indicate that it updates RFC 2865. As an example, Section 1 states th= at “location information needs to be protected against unauthorized acce= ss and distribution”, yet nowhere in the document are the implications of th= is statement for the RADIUS protocol laid out. Does this statement apply = only to the attributes defined in the document, or does it apply to the NAS Identification attributes defined in RFC 2865? Do the security requirements outlined in Section 7 apply to any use of RADIUS, or just to t= he attributes in this document? The document is unclear on this point; i= t needs to state clearly whether the privacy requirements and rules functiona= lity applies only to uses of the attributes defined in this document, or to any = use of RADIUS.

<= ![if !supportLists]>c.&n= bsp; Confusion about the meaning of “retransmission allowed”. As noted in draft-ietf-geopriv-sip-lo-retransmi= ssion as well as in recent discussions on the GEOPRIV WG mailing list, there is confusion about the meaning of “retransmission allowed”. &= nbsp; Since RFC 2865 requires the inclusion of NAS identification in a RADIUS Access-Reques= t, re-transmission of information related to user-location is an integral part= of the network access authentication and authorization process. As= a result, restrictions on the ability of a RADIUS proxy to retransmit locatio= n information to a RADIUS server are inherently non-deployable. In addi= tion, many RADIUS proxies will treat attributes they do not understand as opaque blobs, and so are inherently unable to parse or act upon privacy policies. However, on reading this document, I had many of the = same questions as were raised in draft-ietf-geopriv-lo-retransmission with respe= ct to SIP conveyance, as to whether privacy policies applied to RADIUS conveyance. Some of this confusion was enhanced by Section A.2, entitled “Distribution of location information at the Visited Network= ”. Is the issue really distribution of location information within the RADIUS rea= lms on the roaming relationship path, or is it retransmission of location information outside those entities? This is a critical point &#= 8211; but one that the document leaves unclear.

<= ![if !supportLists]>d.&n= bsp; Consistency with RADIUS architecture. With respec= t to privacy policies, it is unclear whether draft-ietf-geopriv-radius-lo-23 requires RADIUS proxies to inspect RADIUS attributes prior to re-transmissi= on, to understand that certain RADIUS attributes contain location information a= nd to implement policies encoded within those attributes. If so, this would be= an ominous and undesirable requirement to place on RADIUS implementations beca= use RADIUS servers need not have explicit knowledge of the all attributes they = transmit or re-transmit. Such a requirement would be even more undesirable in multi-vendor deployments where RADIUS interoperability is required.

<= ![if !supportLists]>e.&n= bsp; Implications for RADIUS accounting and billing. RADIUS accounting data – which includes location-related information = - is commonly made available to RADIUS proxies and servers today. In some cases, RADIUS accounting data is stored on the visited network proxy and in other cases, the RADIUS accounting data is forwarded to an intermediate or = home realm for storage in a database. When ‘re-transmission allowed&= #8217; is set to 0 (the default), does this mean that RADIUS accounting data that includes location information cannot be re-transmitted to another realm? If so= , then this document would disrupt the transmission of accounting data which = is legally required to be maintained by statues such as Sarbanes Oxley.=

Thanks,

Anthony Leibovitz

Principal Program Manager

Microsoft Corporation

TO WHOM IT MAY CONCERN:

I have read draft-ietf-geopriv-radius-lo-23 and have th= e following concerns about it:

<= ![if !supportLists]>a.&n= bsp; Confusion with existing functionality. As defined in RFC 2865, the RADIUS protocol REQUIRES that NAS identification attributes be present in a RADIUS Access-Request. When combined with = a wiremap, these attributes (such as NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address) provide information on the NAS location, which can be use= d to infer the user location in a number of common scenarios (e.g. IEEE 802 netw= ork access as envisaged in RFC 3580). Given this pre-existing suppo= rt for location, it was surprising for me to read Section 1, which presents th= e functionality of this document as though it were new (e.g. “This docu= ment defines attributes… that can be used to convey location-related information…”). At a minimum, Section 1 needs to de= scribe the existing RADIUS location functionality, and clearly delineate the additiona= l value provided by the attributes described in the document.

<= ![if !supportLists]>b.&n= bsp; Confusion about privacy requirements. Given that RADIUS has always supported transmission of information relating to user location, and indeed, the transmission of this information is REQUIRED in e= very access request, there are a number of statements in the document which appe= ar to represent major changes to RFC 2865, even though this document does not indicate that it updates RFC 2865. As an example, Section 1 states th= at “location information needs to be protected against unauthorized acce= ss and distribution”, yet nowhere in the document are the implications of th= is statement for the RADIUS protocol laid out. Does this statement apply = only to the attributes defined in the document, or does it apply to the NAS Identification attributes defined in RFC 2865? Do the security requirements outlined in Section 7 apply to any use of RADIUS, or just to t= he attributes in this document? The document is unclear on this point; i= t needs to state clearly whether the privacy requirements and rules functiona= lity applies only to uses of the attributes defined in this document, or to any = use of RADIUS.

<= ![if !supportLists]>c.&n= bsp; Confusion about the meaning of “retransmission allowed”. As noted in draft-ietf-geopriv-sip-lo-retransmi= ssion as well as in recent discussions on the GEOPRIV WG mailing list, there is confusion about the meaning of “retransmission allowed”. &= nbsp; Since RFC 2865 requires the inclusion of NAS identification in a RADIUS Access-Reques= t, re-transmission of information related to user-location is an integral part= of the network access authentication and authorization process. As= a result, restrictions on the ability of a RADIUS proxy to retransmit locatio= n information to a RADIUS server are inherently non-deployable. In addi= tion, many RADIUS proxies will treat attributes they do not understand as opaque blobs, and so are inherently unable to parse or act upon privacy policies. However, on reading this document, I had many of the = same questions as were raised in draft-ietf-geopriv-lo-retransmission with respe= ct to SIP conveyance, as to whether privacy policies applied to RADIUS conveyance. Some of this confusion was enhanced by Section A.2, entitled “Distribution of location information at the Visited Network= ”. Is the issue really distribution of location information within the RADIUS rea= lms on the roaming relationship path, or is it retransmission of location information outside those entities? This is a critical point &#= 8211; but one that the document leaves unclear.

<= ![if !supportLists]>d.&n= bsp; Consistency with RADIUS architecture. With respec= t to privacy policies, it is unclear whether draft-ietf-geopriv-radius-lo-23 requires RADIUS proxies to inspect RADIUS attributes prior to re-transmissi= on, to understand that certain RADIUS attributes contain location information a= nd to implement policies encoded within those attributes. If so, this would be= an ominous and undesirable requirement to place on RADIUS implementations beca= use RADIUS servers need not have explicit knowledge of the all attributes they = transmit or re-transmit. Such a requirement would be even more undesirable in multi-vendor deployments where RADIUS interoperability is required.

<= ![if !supportLists]>e.&n= bsp; Implications for RADIUS accounting and billing. RADIUS accounting data – which includes location-related information = - is commonly made available to RADIUS proxies and servers today. In some cases, RADIUS accounting data is stored on the visited network proxy and in other cases, the RADIUS accounting data is forwarded to an intermediate or = home realm for storage in a database. When ‘re-transmission allowed&= #8217; is set to 0 (the default), does this mean that RADIUS accounting data that includes location information cannot be re-transmitted to another realm? If so= , then this document would disrupt the transmission of accounting data which = is legally required to be maintained by statues such as Sarbanes Oxley.=

Thanks,

Anthony Leibovitz

Principal Program Manager

Microsoft Corporation

--_000_180B3E3BF11C4B4581E20A837620FAF0176FEF246CNAEXMSGW601wi_-- -- to 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 15 10:21:56 2009 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 373233A6BBE for ; Wed, 15 Apr 2009 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=-0.382, 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 Li0KFyj6qL5Q for ; Wed, 15 Apr 2009 10:21:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3764B3A6B95 for ; Wed, 15 Apr 2009 10:21:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu8li-000BdG-8F for radiusext-data0@psg.com; Wed, 15 Apr 2009 17:19:26 +0000 Received: from [76.96.62.56] (helo=QMTA06.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu8lV-000BcP-P4 for radiusext@ops.ietf.org; Wed, 15 Apr 2009 17:19:19 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA06.westchester.pa.mail.comcast.net with comcast id fmS21b0040cZkys56tJcGm; Wed, 15 Apr 2009 17:18:36 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA10.westchester.pa.mail.comcast.net with comcast id ftKD1b00T4H2mdz3WtKDfT; Wed, 15 Apr 2009 17:19:14 +0000 From: "Dave Nelson" To: Cc: , Subject: IESG review COMMENT on draft-ietf-radext-management-authorization-06.txt Date: Wed, 15 Apr 2009 13:19:16 -0400 Message-ID: <05E045F2660142B0995700A6F0E9A082@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.5579 Thread-index: Acm97k2HeOzOIQh9TC+23DzEUarM6g== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: [IESG Evaluation COMMENT] from Lars Eggert > > | | |SHLD| MUST| | > > Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| > > Don't abbreviate RC2119 terms: s/SHLD/SHOULD/. OK. We'll find a way to shoe-horn in the full key word. -- to 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 15 10:26:38 2009 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 578A03A6B82 for ; Wed, 15 Apr 2009 10:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=-0.399, 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 CxDTLMGOOK1t for ; Wed, 15 Apr 2009 10:26:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 773E13A6950 for ; Wed, 15 Apr 2009 10:26:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu8qS-000BvQ-FR for radiusext-data0@psg.com; Wed, 15 Apr 2009 17:24:20 +0000 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu8qF-000BuO-VM for radiusext@ops.ietf.org; Wed, 15 Apr 2009 17:24:14 +0000 Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA08.westchester.pa.mail.comcast.net with comcast id fn1M1b0070SCNGk58tPjJL; Wed, 15 Apr 2009 17:23:43 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA09.westchester.pa.mail.comcast.net with comcast id ftQ71b00e4H2mdz3VtQ8Ap; Wed, 15 Apr 2009 17:24:08 +0000 From: "Dave Nelson" To: "'Russ Housley'" Cc: , Subject: IESG review COMMENT on draft-ietf-radext-management-authroization-06.txt Date: Wed, 15 Apr 2009 13:24:10 -0400 Message-ID: <6BD4C71B0D5C4CED8F442595780B0B74@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.5579 Thread-index: Acm97vzxYBfLiQ2USCS0eKBB2ggjWg== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: [IESG Evaluation COMMENT] by Russ Housley > In the Gen-ART Review by Vijay Gurbani on 11-Nov-2008, he asked a > question: > > S5.3: Below the figure, the Length is shown as ">= 3". However, > the Text field expects "one or more octets..." Should not the > Length then be ">= 1"? No, ">=3" is correct, as that field always includes its own two octets in the count. A "null" attribute in RADIUS (not allowed) would have a length of 2. No change to the draft is required. -- to 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 15 11:14:30 2009 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 B97EC3A69C8 for ; Wed, 15 Apr 2009 11:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.412, 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 lSgw3pihHtmI for ; Wed, 15 Apr 2009 11:14:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFE173A68DA for ; Wed, 15 Apr 2009 11:14:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9aG-000F6S-9D for radiusext-data0@psg.com; Wed, 15 Apr 2009 18:11:40 +0000 Received: from [76.96.59.211] (helo=QMTA11.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9a2-000F4s-Qa for radiusext@ops.ietf.org; Wed, 15 Apr 2009 18:11:32 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ftcJ1b0070QuhwU5BuBTSA; Wed, 15 Apr 2009 18:11:27 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA02.westchester.pa.mail.comcast.net with comcast id fuBS1b00C4H2mdz3NuBSwQ; Wed, 15 Apr 2009 18:11:27 +0000 From: "Dave Nelson" To: Cc: , Subject: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Date: Wed, 15 Apr 2009 14:11:29 -0400 Message-ID: <3498692FECE04F18828999C2C9EC3768@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.5579 Thread-index: Acm99ZkDZYLSzSguQIeMMkbDzXGaeQ== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: [IESG Evaluation DISCUSS] by Pasi Eronen > I have reviewed draft-ietf-radext-management-authorization-06. Overall, > the document looks good, but I have the following concerns that I'd like > to discuss before recommending approval of the document: > > The document recommends using Management-Privilege-Level only for > Service-Type 7 (not 6). However, when the NAS receives, for example, > an SSH connection, does it know whether the user is asking for full > privilege access, or less privileged management access? If it does > not know, what should it do? The NAS is not expected to know what level of access the user is "asking for", other than perhaps that an SSH sub-system is involved. That's purely a matter of implementation detail, BTW, and is not being standardized. The RADIUS server is expected to provision the appropriate level of access for the user, based on the user's authorization profile stored in the server's database (or otherwise obtained by the server). The server may use optional (recommended) hint attributes in the Access-Request message that identify the NAS in question and the type of interface used, e.g. a virtual terminal connection, in conjunction with the user's authorization profile, in making its access rights decision. After discussion on the RADEXT mailing list and at IETF-74, it does not appear that any change to the draft is required. > Another question: should the document recommend something about > Management-Privilege-Level values? For example, should bigger numbers > mean "more access" or "less access"? (The actual levels are of course > implementation dependent, but if vendors use opposite conventions, it > seems that would create unnecessary confusion.) There is no one convention used by all vendors, and in fact many implementations allow the mapping of the integer access level to specific access rights to be configured on the NAS by the user. After discussion on the RADEXT mailing list and at IETF-74, the recommendation is to clarify this issue by adding the following text to Section 5.4 of the draft: The mapping of integer values for this attribute to specific collections of management access rights or permissions on the NAS is vendor and implementation specific. Such mapping is often a user configurable feature. It's RECOMMENDED that greater numeric values imply greater privilege. However, it would be a mistake to assume that this recommendation always holds. > It seems that a NAS implementing e.g. NETCONF, FTP or web-based > management would often include the IP address (and perhaps port > number) where connection came from in the Access-Request message. > Should the document give some guidance on NAS-Port-ID (or perhaps > Calling-Station-ID) attributes? (It seems having at least a mild > recommendation about the attribute and formatting would be useful, > instead of every vendor doing things differently.) Discussion on this issue on the RADEXT mailing list and at IETF-74 yielded the following observations. These attributes are not required for use in management access by RFC 2865 and RFC 2869, and the authors don't think we want this draft to update those RFCs. The variation in the format of the NAS-Port and Calling-Station-Id attributes among different implementations has been an issue for a long time. It's probably an interesting topic for a separate work item, but likely doesn't belong in this draft. It does not appear that any change to the draft is required. -- to 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 15 11:20:28 2009 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 7779B3A6916 for ; Wed, 15 Apr 2009 11:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.423, 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 Ved+aOr+qaui for ; Wed, 15 Apr 2009 11:20:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7558E3A6E85 for ; Wed, 15 Apr 2009 11:20:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9fu-000FXZ-St for radiusext-data0@psg.com; Wed, 15 Apr 2009 18:17:30 +0000 Received: from [76.96.62.32] (helo=QMTA03.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9fi-000FWo-Kf for radiusext@ops.ietf.org; Wed, 15 Apr 2009 18:17:24 +0000 Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA03.westchester.pa.mail.comcast.net with comcast id fuE91b0030bG4ec53uGp3B; Wed, 15 Apr 2009 18:16:49 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA03.westchester.pa.mail.comcast.net with comcast id fuH81b00S4H2mdz3PuH8Ad; Wed, 15 Apr 2009 18:17:08 +0000 From: "Dave Nelson" To: "'Jari Arkko'" Cc: , Subject: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Date: Wed, 15 Apr 2009 14:17:20 -0400 Message-ID: <746136C932504B0CBF516C731066F9D5@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.5579 Thread-index: Acm99mq2KbbMBh7+SiWxIwW/gHJ8HQ== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: [IESG Evaluation DISCUSS] from Jari Arkko > This spec is overall in very good shape. However, I had the following > problems: > > Section 5.3 says on Management-Policy-Id attribute: > > The Text field is one or more octets, and its contents are > implementation dependent. It is intended to be human readable and > MUST NOT affect operation of the protocol. It is RECOMMENDED that > the message contain UTF-8 encoded 10646 [RFC3629] characters. > > The statement about not affecting the operation of the protocol is > at least misleading and confusing and likely also factually wrong. > Like the document states earlier: > > If the NAS supports this attribute, but the > policy name is unknown ... the NAS MUST treat > the Access-Accept packet as if it had been an Access-Reject. > > So the contents of the field can actually have an effect even > at the RADIUS level. I would suggest saying something else, e.g., > > It is intended to be human readable and the contents MUST NOT be > parsed by the receiver; the contents can only be used to look up > locally defined policies. We will revise the draft to use the above suggested text. -- to 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 15 11:21:35 2009 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 C23063A6BF1 for ; Wed, 15 Apr 2009 11:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, 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 yAifdlx2EKor for ; Wed, 15 Apr 2009 11:21:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D30EF3A6916 for ; Wed, 15 Apr 2009 11:21:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9iD-000Fg6-3u for radiusext-data0@psg.com; Wed, 15 Apr 2009 18:19:53 +0000 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9hz-000Ff7-KR for radiusext@ops.ietf.org; Wed, 15 Apr 2009 18:19:45 +0000 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 301091986EE; Wed, 15 Apr 2009 21:19:38 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id D216A198665; Wed, 15 Apr 2009 21:19:37 +0300 (EEST) Message-ID: <49E6252F.8090208@piuha.net> Date: Wed, 15 Apr 2009 21:19:27 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dave Nelson CC: iesg@ietf.org, radiusext@ops.ietf.org Subject: Re: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt References: <746136C932504B0CBF516C731066F9D5@NEWTON603> In-Reply-To: <746136C932504B0CBF516C731066F9D5@NEWTON603> 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 List-ID: Good -- thanks. Jari Dave Nelson wrote: > [IESG Evaluation DISCUSS] from Jari Arkko > > >> This spec is overall in very good shape. However, I had the following >> problems: >> >> Section 5.3 says on Management-Policy-Id attribute: >> >> The Text field is one or more octets, and its contents are >> implementation dependent. It is intended to be human readable and >> MUST NOT affect operation of the protocol. It is RECOMMENDED that >> the message contain UTF-8 encoded 10646 [RFC3629] characters. >> >> The statement about not affecting the operation of the protocol is >> at least misleading and confusing and likely also factually wrong. >> Like the document states earlier: >> >> If the NAS supports this attribute, but the >> policy name is unknown ... the NAS MUST treat >> the Access-Accept packet as if it had been an Access-Reject. >> >> So the contents of the field can actually have an effect even >> at the RADIUS level. I would suggest saying something else, e.g., >> >> It is intended to be human readable and the contents MUST NOT be >> parsed by the receiver; the contents can only be used to look up >> locally defined policies. >> > > We will revise the draft to use the above suggested text. > > > > -- to 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 15 11:26:29 2009 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 E752B3A69F7 for ; Wed, 15 Apr 2009 11:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 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 OEoCTYoLnvOX for ; Wed, 15 Apr 2009 11:26:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31A4F3A6F2F for ; Wed, 15 Apr 2009 11:26:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9mS-000G0k-EO for radiusext-data0@psg.com; Wed, 15 Apr 2009 18:24:16 +0000 Received: from [76.96.62.17] (helo=QMTA10.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9mC-000FzC-Mn for radiusext@ops.ietf.org; Wed, 15 Apr 2009 18:24:09 +0000 Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA10.westchester.pa.mail.comcast.net with comcast id ftl01b0030Fqzac5AuQ1mv; Wed, 15 Apr 2009 18:24:01 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA08.westchester.pa.mail.comcast.net with comcast id fuTq1b01Z4H2mdz3UuTrE7; Wed, 15 Apr 2009 18:27:51 +0000 From: "Dave Nelson" To: Cc: , Subject: IESG review DISCUSS on draft-ietf-radext-management-authroization-06.txt Date: Wed, 15 Apr 2009 14:24:03 -0400 Message-ID: <7D98956524184BCABD2F21C870913D38@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.5579 Thread-index: Acm991qm16NhKz0aSHqA6T6Gh/Tvcw== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: [IESG Evaluation DISCUSS] from Tim Polk > [Note that I am not requesting any changes at this time! I am > interested in discussing this issue (with authors, chairs, and other > ADs) to determine if it merits action...] > > The Management-Privilege-Level Attribute supports differentiated privilege > levels denoted by integer values. The specification notes that "specific > access rights conferred by each value are implementation dependent". > > Almost inevitably, implementations begin by assigning values in ascending > or descending order but find a need to assert a new privilege level in > the middle at a later date. That works fine with this specification, but > product vendors sometimes make an assumption that this will be ordered. > > I wonder if a brief addition to the security considerations noting that > vendors should not assume ordering for these values would be worthwhile? We have proposed adding the following text to Section 5.4 of the draft, to address a similar DISCUSS from Pasi Eronen: The mapping of integer values for this attribute to specific collections of management access rights or permissions on the NAS is vendor and implementation specific. Such mapping is often a user configurable feature. It's RECOMMENDED that greater numeric values imply greater privilege. However, it would be a mistake to assume that this recommendation always holds. -- to 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 15 11:34:14 2009 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 1B48B3A6B25 for ; Wed, 15 Apr 2009 11:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=-0.441, 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 pl9ebwbqS1r2 for ; Wed, 15 Apr 2009 11:34:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E5D73A68E0 for ; Wed, 15 Apr 2009 11:34:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9uV-000GXl-OG for radiusext-data0@psg.com; Wed, 15 Apr 2009 18:32:35 +0000 Received: from [76.96.62.96] (helo=QMTA09.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9uH-000GWZ-Su for radiusext@ops.ietf.org; Wed, 15 Apr 2009 18:32:27 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA09.westchester.pa.mail.comcast.net with comcast id fuQM1b00G0QuhwU59uYNTu; Wed, 15 Apr 2009 18:32:22 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA02.westchester.pa.mail.comcast.net with comcast id fuYM1b01r4H2mdz3NuYMGC; Wed, 15 Apr 2009 18:32:22 +0000 From: "Dave Nelson" To: "'Jari Arkko'" Cc: , Subject: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Date: Wed, 15 Apr 2009 14:32:24 -0400 Message-ID: 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.5579 Thread-index: Acm9+IVCBPcbRWVNThuYX1UxLQPDNQ== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: [IESG Evaluation COMMENT] from Jari Arkko > I find it unfortunate that the document does not define > an attribute to distinguish SSH and other forms of > command line protocols from each other. Or has such an > attribute already been defined somewhere else? That feature existed in previous revisions of the draft. It was taken out because the RADEXT WG and the ISMS WG agreed that it was "overkill" to specify the access mechanism that narrowly. The problem is that once you go down that path, there are lots and lots of properties of such secure transports that one may wish to specify, such as authentication methods, cipher-suites, key lengths, key lifetimes, certificate chains, etc. The WG thought it prudent to "just don't go there". After further discussion on the RADEXT mailing list and at IETF-74 the recommendation is to honor the WG consensus in this regard. For that reason, we believe that no change to the draft is required. -- to 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 15 11:48:18 2009 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 8817A3A6824 for ; Wed, 15 Apr 2009 11:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.448, 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 10gKRmAXvCZ5 for ; Wed, 15 Apr 2009 11:48:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C5C93A6A8C for ; Wed, 15 Apr 2009 11:48:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuA5K-000HH6-1N for radiusext-data0@psg.com; Wed, 15 Apr 2009 18:43:46 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuA57-000HGQ-Sv for radiusext@ops.ietf.org; Wed, 15 Apr 2009 18:43:39 +0000 Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA01.westchester.pa.mail.comcast.net with comcast id fu7v1b00J0Fqzac51ujatn; Wed, 15 Apr 2009 18:43:34 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA08.westchester.pa.mail.comcast.net with comcast id funQ1b0024H2mdz3UunQAq; Wed, 15 Apr 2009 18:47:24 +0000 From: "Dave Nelson" To: "'Jari Arkko'" Cc: , Subject: IESG review COMMENT on draft-ietf-radext-management-authorization-06.txt Date: Wed, 15 Apr 2009 14:43:36 -0400 Message-ID: <5D366D05988A4CFBA729D6F4C6AC2133@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.5579 Thread-index: Acm9+hXgGinG4+yfS46a4UkCTmK9aQ== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: [IESG Evaluation COMMENT] from Jari Arkko > The document is silent on exactly how authentication > from, say, SCP or is actually represented in RADIUS. That's true. Isn't that a matter for SCP (et. al.) to specify? Certainly we wouldn't attempt to do so in a RADIUS document. This document defines the format and syntax of RADIUS attributes. It does not act as an application guide, much as the companion document in the ISMS WG, "RADIUS Usage for SNMP Transport Models", does for SNMP. Maybe there is a need for additional companion documents that provide additional application advice for other areas such as NETCONF and for adaptation of specific transports such as SCP. > Perhaps that is obvious? (But aren't there non-trivial > details, depending on what kind of challenge or password > mechanism is in use?) Or is authorize-only used? Based on discussion of this issue on the RADEXT mailing list and at IETF-74, the authors suggest adding a new section, in the form of implementation notes, that reviews the existing forms of RADIUS credentials and points out that secure transport authentication methods would need to be compatible with one of the existing RADIUS authentication methods. This seems obvious, but it may be worth stating. n. Implementation Notes RADIUS currently supports the following user authentication methods, although others may be added in the future: * Password (RFC 2865) * CHAP (RFC 2865) * ARAP (RFC 2869) * EAP (RFC 2869, RFC 3579) * Digest (RFC 5090) The secure transport protocols selected for use the RADIUS remote NAS management sessions, for example those described in Section 5.1, obviously need to support user authentication methods that are compatible with those that exist in RADIUS. The integration of the user authentication mechanism of the secure transport with that of the RADIUS client is a matter of implementation. > I support Pasi's Discuss. Addressed in a separate email message. -- to 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 16 13:02:15 2009 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 CE2193A6F7B for ; Thu, 16 Apr 2009 13:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.416 X-Spam-Level: X-Spam-Status: No, score=-5.416 tagged_above=-999 required=5 tests=[AWL=-0.921, 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 3bCbNqOGcav6 for ; Thu, 16 Apr 2009 13:02:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 310193A6F88 for ; Thu, 16 Apr 2009 13:01:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuXhd-000IxD-1N for radiusext-data0@psg.com; Thu, 16 Apr 2009 19:56:53 +0000 Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuXhP-000IwI-Hr for radiusext@ops.ietf.org; Thu, 16 Apr 2009 19:56:46 +0000 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3GJu3ic020905; Thu, 16 Apr 2009 14:56:35 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 22:56:31 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 22:56:30 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 16 Apr 2009 21:56:30 +0200 From: To: CC: , Date: Thu, 16 Apr 2009 21:56:28 +0200 Subject: RE: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Thread-Topic: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Thread-Index: Acm99ZkDZYLSzSguQIeMMkbDzXGaeQA1dtGg Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F23568CA@NOK-EUMSG-01.mgdnok.nokia.com> References: <3498692FECE04F18828999C2C9EC3768@NEWTON603> In-Reply-To: <3498692FECE04F18828999C2C9EC3768@NEWTON603> 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 X-OriginalArrivalTime: 16 Apr 2009 19:56:30.0218 (UTC) FILETIME=[6F54EEA0:01C9BECD] X-Nokia-AV: Clean Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dave Nelson wrote: > > The document recommends using Management-Privilege-Level only for > > Service-Type 7 (not 6). However, when the NAS receives, for example, > > an SSH connection, does it know whether the user is asking for full > > privilege access, or less privileged management access? If it does > > not know, what should it do? >=20 > The NAS is not expected to know what level of access the user is > "asking for", other than perhaps that an SSH sub-system is involved. > That's purely a matter of implementation detail, BTW, and is not > being standardized. > > The RADIUS server is expected to provision the appropriate level of > access for the user, based on the user's authorization profile > stored in the server's database (or otherwise obtained by the > server). The server may use optional (recommended) hint attributes > in the Access-Request message that identify the NAS in question and > the type of interface used, e.g. a virtual terminal connection, in > conjunction with the user's authorization profile, in making its > access rights decision. >=20 > After discussion on the RADEXT mailing list and at IETF-74, it does > not appear that any change to the draft is required. The situation for Access-Accept (the important part) is clear, and=20 I guess for the hints in Access-Request, we can leave it implementation-specific... (like many other parts in RADIUS :-) > > Another question: should the document recommend something about > > Management-Privilege-Level values? For example, should bigger numbers > > mean "more access" or "less access"? (The actual levels are of course > > implementation dependent, but if vendors use opposite conventions, it > > seems that would create unnecessary confusion.) >=20 > There is no one convention used by all vendors, and in fact many > implementations allow the mapping of the integer access level to > specific access rights to be configured on the NAS by the user. >=20 > After discussion on the RADEXT mailing list and at IETF-74, the > recommendation is to clarify this issue by adding the following text to > Section 5.4 of the draft: >=20 > The mapping of integer values for this attribute to specific > collections of management access rights or permissions on the NAS > is vendor and implementation specific. Such mapping is often a > user configurable feature. It's RECOMMENDED that greater numeric > values imply greater privilege. However, it would be a mistake > to assume that this recommendation always holds. Looks good! > > It seems that a NAS implementing e.g. NETCONF, FTP or web-based > > management would often include the IP address (and perhaps port > > number) where connection came from in the Access-Request message. > > Should the document give some guidance on NAS-Port-ID (or perhaps > > Calling-Station-ID) attributes? (It seems having at least a mild > > recommendation about the attribute and formatting would be useful, > > instead of every vendor doing things differently.) >=20 > Discussion on this issue on the RADEXT mailing list and at IETF-74 > yielded the following observations. These attributes are not > required for use in management access by RFC 2865 and RFC 2869, and > the authors don't think we want this draft to update those RFCs. > The variation in the format of the NAS-Port and Calling-Station-Id > attributes among different implementations has been an issue for a > long time. It's probably an interesting topic for a separate work > item, but likely doesn't belong in this draft. It does not appear > that any change to the draft is required. Could you provide pointers to the RADEXT mailing list discussions? =20 I couldn't find anything in the archive, and the IETF74 minutes don't mention anything either. To the degree the source IP/port is just for human consumption (e.g. troubleshooting or forensics), it's probably OK to leave the contents implementation-specific.=20 But if they're used for something else, to me it seems that this draft would be the right place to make some recommendations (not necessarily requirements that would update 2865/2869) for the management=20 protocols listed here. (Not for any other use of RADIUS, of course.) Best regards, Pasi -- to 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 17 06:01:06 2009 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 663DF3A6863 for ; Fri, 17 Apr 2009 06:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[AWL=-0.454, 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 HThwEQkxofH0 for ; Fri, 17 Apr 2009 06:01:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F67228C0D7 for ; Fri, 17 Apr 2009 06:01:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lund7-000719-47 for radiusext-data0@psg.com; Fri, 17 Apr 2009 12:57:17 +0000 Received: from [76.96.62.64] (helo=QMTA07.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luncq-0006zl-Tt for radiusext@ops.ietf.org; Fri, 17 Apr 2009 12:57:10 +0000 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA07.westchester.pa.mail.comcast.net with comcast id gaJV1b0030mv7h057cwUTs; Fri, 17 Apr 2009 12:56:28 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.westchester.pa.mail.comcast.net with comcast id gcx01b0014H2mdz3Xcx0yE; Fri, 17 Apr 2009 12:57:01 +0000 From: "Dave Nelson" To: Cc: , References: <3498692FECE04F18828999C2C9EC3768@NEWTON603> <808FD6E27AD4884E94820BC333B2DB7727F23568CA@NOK-EUMSG-01.mgdnok.nokia.com> Subject: RE: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Date: Fri, 17 Apr 2009 08:57:05 -0400 Message-ID: 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.5579 Thread-index: Acm99ZkDZYLSzSguQIeMMkbDzXGaeQA1dtGgACNafSA= In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F23568CA@NOK-EUMSG-01.mgdnok.nokia.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Pasi Eronen writes... > > The NAS is not expected to know what level of access the user is > > "asking for", other than perhaps that an SSH sub-system is involved. > > That's purely a matter of implementation detail, BTW, and is not > > being standardized. > > > > The RADIUS server is expected to provision the appropriate level of > > access for the user, based on the user's authorization profile > > stored in the server's database (or otherwise obtained by the > > server). The server may use optional (recommended) hint attributes > > in the Access-Request message that identify the NAS in question and > > the type of interface used, e.g. a virtual terminal connection, in > > conjunction with the user's authorization profile, in making its > > access rights decision. > > > > After discussion on the RADEXT mailing list and at IETF-74, it does > > not appear that any change to the draft is required. > > The situation for Access-Accept (the important part) is clear, and > I guess for the hints in Access-Request, we can leave it > implementation-specific... (like many other parts in RADIUS :-) The use of appropriate hint attributes in the Access-Request is RECOMMENDED, but the NAS can only hint what it knows. It knows how the session "arrived" i.e. over what mechanism. It does not know the intent of the human at the other end of the connection. I think this is the best we can reasonably do. > > Discussion on this issue on the RADEXT mailing list and at IETF-74 > > yielded the following observations. These attributes are not > > required for use in management access by RFC 2865 and RFC 2869, and > > the authors don't think we want this draft to update those RFCs. > > The variation in the format of the NAS-Port and Calling-Station-Id > > attributes among different implementations has been an issue for a > > long time. It's probably an interesting topic for a separate work > > item, but likely doesn't belong in this draft. It does not appear > > that any change to the draft is required. > > Could you provide pointers to the RADEXT mailing list discussions? > I couldn't find anything in the archive, and the IETF74 minutes don't > mention anything either. I'll search for the mail message(s) when I get a bit more time. It was presented in the slide deck at IETF-74 the proposed resolution to this issue. No one suggested we do otherwise. > To the degree the source IP/port is just for human consumption > (e.g. troubleshooting or forensics), it's probably OK to leave the > contents implementation-specific. > > But if they're used for something else, to me it seems that this draft > would be the right place to make some recommendations (not necessarily > requirements that would update 2865/2869) for the management > protocols listed here. (Not for any other use of RADIUS, of course.) The attributes that have variability are the NAS-ID and NAS-Port-ID, which are basically as you have indicated -- human readable strings with no specific recommended format. I have to think that these attributes were (a) intended for use in accounting, where they are simply logged verbatim for humans to inspect later on or (b) were intended for use in authentication and/or or authorization decisions, in some vendor-specific fashion. The RFCs don't give us any guidance here. If there are (b) usages, it might be nice to standardize them someday. The point we were making was that it's not directly related to the NAS Management Authorization work, and it's something that may be very difficult to achieve consensus on, given the large diversity of implementations over a large number of years. In sort, the authors feel that it would be unreasonable to hold *this* draft accountable for solving that problem. Regards, Dave Nelson -- to 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 20 03:37:24 2009 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 AB7693A6F31 for ; Mon, 20 Apr 2009 03:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.412 X-Spam-Level: X-Spam-Status: No, score=-5.412 tagged_above=-999 required=5 tests=[AWL=-0.917, 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 vcl6EJrcfwou for ; Mon, 20 Apr 2009 03:37:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 78EF23A68AA for ; Mon, 20 Apr 2009 03:37:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvqo7-000EWD-HF for radiusext-data0@psg.com; Mon, 20 Apr 2009 10:32:59 +0000 Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvqnv-000EVH-DS for radiusext@ops.ietf.org; Mon, 20 Apr 2009 10:32:52 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3KAWDll018704; Mon, 20 Apr 2009 05:32:42 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 13:32:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 13:32:12 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 20 Apr 2009 12:32:11 +0200 From: To: CC: , Date: Mon, 20 Apr 2009 12:32:09 +0200 Subject: RE: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Thread-Topic: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Thread-Index: Acm99ZkDZYLSzSguQIeMMkbDzXGaeQA1dtGgACNafSAAklVFUA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F238B916@NOK-EUMSG-01.mgdnok.nokia.com> References: <3498692FECE04F18828999C2C9EC3768@NEWTON603> <808FD6E27AD4884E94820BC333B2DB7727F23568CA@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: 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 X-OriginalArrivalTime: 20 Apr 2009 10:32:12.0068 (UTC) FILETIME=[43F43E40:01C9C1A3] X-Nokia-AV: Clean Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dave Nelson wrote: > The attributes that have variability are the NAS-ID and NAS-Port-ID, > which are basically as you have indicated -- human readable strings > with no specific recommended format. I have to think that these > attributes were (a) intended for use in accounting, where they are > simply logged verbatim for humans to inspect later on or (b) were > intended for use in authentication and/or or authorization > decisions, in some vendor-specific fashion. The RFCs don't give us > any guidance here. >=20 > If there are (b) usages, it might be nice to standardize them > someday. The point we were making was that it's not directly > related to the NAS Management Authorization work, and it's something > that may be very difficult to achieve consensus on, given the large > diversity of implementations over a large number of years. In sort, > the authors feel that it would be unreasonable to hold *this* draft > accountable for solving that problem. I was not asking this draft to fully solve the problems about NAS-Port-Id. I was asking a very specific suggestion: given that many NASes implementing this specification will probably send the IP address=20 (and possibly port number) of the SSH/NETCONF/etc. client *somewhere*=20 in the Access-Request packet, should the document give some guidance =20 on what attribute/format could be used? Do I understand correctly that you think it's better to *not* give any guidance, leaving each vendor to do things differently?=20 (remembering that we're talking about new NASes that implement=20 the attributes from this draft, not old stuff) Best regards, Pasi -- to 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 20 04:26:43 2009 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 496453A69CB for ; Mon, 20 Apr 2009 04:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-0.971, 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 Q3j-RhULnOFl for ; Mon, 20 Apr 2009 04:26:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 518863A67A1 for ; Mon, 20 Apr 2009 04:26:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvrb2-000J40-R2 for radiusext-data0@psg.com; Mon, 20 Apr 2009 11:23:32 +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.69 (FreeBSD)) (envelope-from ) id 1Lvrap-000J2m-Qm for radiusext@ops.ietf.org; Mon, 20 Apr 2009 11:23:26 +0000 X-IronPort-AV: E=Sophos;i="4.40,217,1238990400"; d="scan'208";a="143531408" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Apr 2009 07:23:11 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Apr 2009 07:23:10 -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: IESG review DISCUSS ondraft-ietf-radext-management-authorization-06.txt Date: Mon, 20 Apr 2009 13:22:27 +0200 Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F238B916@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG review DISCUSS ondraft-ietf-radext-management-authorization-06.txt Thread-Index: Acm99ZkDZYLSzSguQIeMMkbDzXGaeQA1dtGgACNafSAAklVFUAAB6csQ References: <3498692FECE04F18828999C2C9EC3768@NEWTON603><808FD6E27AD4884E94820BC333B2DB7727F23568CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F238B916@NOK-EUMSG-01.mgdnok.nokia.com> From: "Romascanu, Dan (Dan)" To: , Cc: , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Pasi.Eronen@nokia.com > Sent: Monday, April 20, 2009 1:32 PM > To: d.b.nelson@comcast.net > Cc: iesg@ietf.org; radiusext@ops.ietf.org > Subject: RE: IESG review DISCUSS=20 > ondraft-ietf-radext-management-authorization-06.txt >=20 > Dave Nelson wrote: >=20 > > The attributes that have variability are the NAS-ID and=20 > NAS-Port-ID,=20 > > which are basically as you have indicated -- human readable strings=20 > > with no specific recommended format. I have to think that these=20 > > attributes were (a) intended for use in accounting, where they are=20 > > simply logged verbatim for humans to inspect later on or (b) were=20 > > intended for use in authentication and/or or authorization=20 > decisions,=20 > > in some vendor-specific fashion. The RFCs don't give us=20 > any guidance=20 > > here. > >=20 > > If there are (b) usages, it might be nice to standardize=20 > them someday. =20 > > The point we were making was that it's not directly related=20 > to the NAS=20 > > Management Authorization work, and it's something that may be very=20 > > difficult to achieve consensus on, given the large diversity of=20 > > implementations over a large number of years. In sort, the authors=20 > > feel that it would be unreasonable to hold *this* draft accountable=20 > > for solving that problem. >=20 > I was not asking this draft to fully solve the problems about=20 > NAS-Port-Id. >=20 > I was asking a very specific suggestion: given that many=20 > NASes implementing this specification will probably send the=20 > IP address (and possibly port number) of the SSH/NETCONF/etc.=20 > client *somewhere* in the Access-Request packet, should the=20 > document give some guidance on what attribute/format could be used? >=20 > Do I understand correctly that you think it's better to *not*=20 > give any guidance, leaving each vendor to do things differently?=20 > (remembering that we're talking about new NASes that=20 > implement the attributes from this draft, not old stuff) >=20 > Best regards, > Pasi >=20 My opinion is that it is better to not give any guidance in this document, for the reasons mentioned by David. A proper and complete solution would require long discussions and I am not certain is within the scope here, and in the absence of a complete solution I prefer to leave this implementation dependent at this point in time.=20 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 Mon Apr 20 04:43:24 2009 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 145323A6AE3 for ; Mon, 20 Apr 2009 04:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.407 X-Spam-Level: X-Spam-Status: No, score=-5.407 tagged_above=-999 required=5 tests=[AWL=-0.912, 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 m438bTUlSsAc for ; Mon, 20 Apr 2009 04:43:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A3823A6ACD for ; Mon, 20 Apr 2009 04:43:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvrry-000KTt-Cw for radiusext-data0@psg.com; Mon, 20 Apr 2009 11:41:02 +0000 Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvrrl-000KT0-CA for radiusext@ops.ietf.org; Mon, 20 Apr 2009 11:40:55 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3KBeEUV024935; Mon, 20 Apr 2009 14:40:34 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 14:39:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 14:39:47 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 20 Apr 2009 13:39:44 +0200 From: To: , CC: , Date: Mon, 20 Apr 2009 13:39:41 +0200 Subject: RE: IESG review DISCUSS ondraft-ietf-radext-management-authorization-06.txt Thread-Topic: IESG review DISCUSS ondraft-ietf-radext-management-authorization-06.txt Thread-Index: Acm99ZkDZYLSzSguQIeMMkbDzXGaeQA1dtGgACNafSAAklVFUAAB6csQAACAzfA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F238B9EE@NOK-EUMSG-01.mgdnok.nokia.com> References: <3498692FECE04F18828999C2C9EC3768@NEWTON603><808FD6E27AD4884E94820BC333B2DB7727F23568CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F238B916@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: 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 X-OriginalArrivalTime: 20 Apr 2009 11:39:47.0202 (UTC) FILETIME=[B5009620:01C9C1AC] X-Nokia-AV: Clean Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dan Romascanu wrote: > > I was not asking this draft to fully solve the problems about > > NAS-Port-Id. > > > > I was asking a very specific suggestion: given that many > > NASes implementing this specification will probably send the > > IP address (and possibly port number) of the SSH/NETCONF/etc. > > client *somewhere* in the Access-Request packet, should the > > document give some guidance on what attribute/format could be used? > > > > Do I understand correctly that you think it's better to *not* > > give any guidance, leaving each vendor to do things differently? > > (remembering that we're talking about new NASes that > > implement the attributes from this draft, not old stuff) > > > > Best regards, > > Pasi > > >=20 > My opinion is that it is better to not give any guidance in this > document, for the reasons mentioned by David. A proper and complete > solution would require long discussions and I am not certain is within > the scope here, and in the absence of a complete solution I prefer to > leave this implementation dependent at this point in time. We all know that proper and complete solution will never happen... but since so many other RADIUS details are vendor-dependent, I guess this one won't really change the overall interoperability situation. I'll clear when David's proposed text for Section 5.4 (email 2009-04-15, about management privilege levels) is there. An RFC editor note would work for me. Best regards, Pasi -- to 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 20 11:01:18 2009 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 CB3C63A6FBD for ; Mon, 20 Apr 2009 11:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[AWL=-0.245, 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 c5INYO2hD7ET for ; Mon, 20 Apr 2009 11:01:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F1683A6FD4 for ; Mon, 20 Apr 2009 11:01:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvxkJ-0003NK-QL for radiusext-data0@psg.com; Mon, 20 Apr 2009 17:57:31 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvxk6-0003LC-Fk for radiusext@ops.ietf.org; Mon, 20 Apr 2009 17:57:25 +0000 Received: (qmail 10339 invoked from network); 20 Apr 2009 13:57:09 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 20 Apr 2009 13:57:09 -0400 From: "David B. Nelson" To: Cc: , References: <3498692FECE04F18828999C2C9EC3768@NEWTON603> <808FD6E27AD4884E94820BC333B2DB7727F23568CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F238B916@NOK-EUMSG-01.mgdnok.nokia.com> Subject: RE: IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt Date: Mon, 20 Apr 2009 13:57:07 -0400 Organization: Elbrys Networks, Inc. Message-ID: <4A794E82B04D4EBD8241612B807693DC@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.5579 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F238B916@NOK-EUMSG-01.mgdnok.nokia.com> Thread-Index: Acm99ZkDZYLSzSguQIeMMkbDzXGaeQA1dtGgACNafSAAklVFUAAOy0VQ Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > I was asking a very specific suggestion: given that many NASes > implementing this specification will probably send the IP > address (and possibly port number) of the SSH/NETCONF/etc. > client *somewhere* in the Access-Request packet, should the > document give some guidance on what attribute/format could > be used? Actually, I don't think that this is a common practice. If I understand this correctly, you're asking that the NAS send the IP address and (source) TCP/UDP port number of the protocol *peer* as hints in an Access-Request packet. This is basically the protocol-domain identity of the remote host. That's how I interpret "client" as it appears in your message, quoted above. I presume that one use case for this would be a listing of client systems, maintained at the RADIUS server, from which such connections are allowed to be originated. Personally, I don't see any significant value in host-based authentication in addition to RADIUS user authentication. If this information *were* to be sent, we would need either a new attribute (or new attributes), or a further overloading of the Calling-Station-Id attribute. Calling-Station-Id was defined in RFC 2865 to be a phone number and overloaded in RFC 3580 to be an Ethernet MAC address. We *could* further overload this attribute to be an IPv4 or IPv6 address. I'm not sure that would be the best approach. Do you have a specific motivation for including remote host identity in the Access-Request packet? > Do I understand correctly that you think it's better to *not* > give any guidance, leaving each vendor to do things differently? No, not better. My question was whether this issue was in scope for this draft and whether there was currently sufficient consensus in the RADIUS community to standardize this usage, or if not, how long it might take to establish consensus. > (remembering that we're talking about new NASes that implement > the attributes from this draft, not old stuff) Yes, but if the solution overloads or redefines the content of existing attributes in any way, it's no longer a "green field" discussion. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Apr 20 11:06:10 2009 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 900073A6F7E for ; Mon, 20 Apr 2009 11:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 b7wWMsO6lv46 for ; Mon, 20 Apr 2009 11:06:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6EA8A3A68CB for ; Mon, 20 Apr 2009 11:06:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvxpY-00047b-PS for radiusext-data0@psg.com; Mon, 20 Apr 2009 18:02:56 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvxpA-00043S-7v for radiusext@ops.ietf.org; Mon, 20 Apr 2009 18:02:44 +0000 Received: (qmail 10547 invoked from network); 20 Apr 2009 14:02:29 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 20 Apr 2009 14:02:29 -0400 From: "David B. Nelson" To: , Cc: , References: <3498692FECE04F18828999C2C9EC3768@NEWTON603><808FD6E27AD4884E94820BC333B2DB7727F23568CA@NOK-EUMSG-01.mgdnok.nokia.com><808FD6E27AD4884E94820BC333B2DB7727F238B916@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F238B9EE@NOK-EUMSG-01.mgdnok.nokia.com> Subject: RE: IESG review DISCUSSondraft-ietf-radext-management-authorization-06.txt Date: Mon, 20 Apr 2009 14:02:26 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00CE0F8741464B3595F234B92C35576F@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.5579 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F238B9EE@NOK-EUMSG-01.mgdnok.nokia.com> Thread-Index: Acm99ZkDZYLSzSguQIeMMkbDzXGaeQA1dtGgACNafSAAklVFUAAB6csQAACAzfAADYAcgA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > I'll clear when David's proposed text for Section 5.4 (email > 2009-04-15, about management privilege levels) is there. An > RFC editor note would work for me. Dan had suggested that we issue a -07 revision once all the DISCUSS and COMMENT issues have been conceptually cleared. That should not take more than a day or so. -- to 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 20 15:06:07 2009 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 51A3528C1D1 for ; Mon, 20 Apr 2009 15:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=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 4YJR5u4gAGev for ; Mon, 20 Apr 2009 15:06:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FFBE28C18E for ; Mon, 20 Apr 2009 15:05:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw1YF-0001Lp-NR for radiusext-data0@psg.com; Mon, 20 Apr 2009 22:01:19 +0000 Received: from blu0-omc1-s3.blu0.hotmail.com ([65.55.116.14]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw1Y0-0001KD-8t for radiusext@ops.ietf.org; Mon, 20 Apr 2009 22:01:11 +0000 Received: from BLU137-W22 ([65.55.116.8]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 15:01:03 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_486848d4-5800-4626-812a-b7900f8ea44c_" X-Originating-IP: [131.107.0.114] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: FW: COMMENT: draft-ietf-radext-design Date: Mon, 20 Apr 2009 15:01:03 -0700 Importance: Normal In-Reply-To: <20090420212706.5A4C73A6B3E@core3.amsl.com> References: <20090420212706.5A4C73A6B3E@core3.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2009 22:01:03.0853 (UTC) FILETIME=[7F9E21D0:01C9C203] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_486848d4-5800-4626-812a-b7900f8ea44c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: housley@vigilsec.com > To: iesg@ietf.org > CC: radext-chairs@tools.ietf.org=3B draft-ietf-radext-design@tools.ietf.o= rg=3B gdweber@gmail.com=3B aland@freeradius.org > Date: Mon=2C 20 Apr 2009 14:27:06 -0700 > Subject: COMMENT: draft-ietf-radext-design=20 >=20 > Comment: >=20 > The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some > editorial suggestions. >=20 > ID nits complains that reference [8] appears in Appendix B.6 but not > in the References. >=20 > The Introduction Section should be a non-normative section. However=2C > Section 1.1 uses normative statements (RECOMMENDED and NOT > RECOMMENDED) before those terms are defined in Section 1.3. >=20 > The acronym AAA should be expanded. >=20 > When referring to the appendixes=2C I think the draft should talk about > appendixes=2C not about sections. For example=2C it should talk about > Appendix A.5=2C not about Section A.5. >=20 --_486848d4-5800-4626-812a-b7900f8ea44c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B From: housley@vigilsec.com
>=3B To: iesg@ietf.org
&g= t=3B CC: radext-chairs@tools.ietf.org=3B draft-ietf-radext-design@tools.iet= f.org=3B gdweber@gmail.com=3B aland@freeradius.org
>=3B Date: Mon=2C 2= 0 Apr 2009 14:27:06 -0700
>=3B Subject: COMMENT: draft-ietf-radext-des= ign
>=3B
>=3B Comment:
>=3B
>=3B The Gen-ART Revie= w by Gonzalo Camarillo on 8 April 2009 provides some
>=3B editorial = suggestions.
>=3B
>=3B ID nits complains that reference [8] ap= pears in Appendix B.6 but not
>=3B in the References.
>=3B
= >=3B The Introduction Section should be a non-normative section. Howeve= r=2C
>=3B Section 1.1 uses normative statements (RECOMMENDED and NOT=
>=3B RECOMMENDED) before those terms are defined in Section 1.3.>=3B
>=3B The acronym AAA should be expanded.
>=3B
>= =3B When referring to the appendixes=2C I think the draft should talk abo= ut
>=3B appendixes=2C not about sections. For example=2C it should t= alk about
>=3B Appendix A.5=2C not about Section A.5.
>=3B
= = --_486848d4-5800-4626-812a-b7900f8ea44c_-- -- to 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 20 22:04:48 2009 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 5A2223A6E45 for ; Mon, 20 Apr 2009 22:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-0.452, 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 LCRZ3FNvE1Rg for ; Mon, 20 Apr 2009 22:04:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C84E43A6857 for ; Mon, 20 Apr 2009 22:04:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw86s-0007L8-2n for radiusext-data0@psg.com; Tue, 21 Apr 2009 05:01:30 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw86f-0007KX-Co for radiusext@ops.ietf.org; Tue, 21 Apr 2009 05:01:23 +0000 Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 7024012344EE; Tue, 21 Apr 2009 07:01:13 +0200 (CEST) Message-ID: <49ED531A.9030907@deployingradius.com> Date: Tue, 21 Apr 2009 07:01:14 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: FW: COMMENT: draft-ietf-radext-design References: <20090420212706.5A4C73A6B3E@core3.amsl.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ... >> The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some >> editorial suggestions. Already responded to: http://www.ops.ietf.org/lists/radiusext/2009/msg00187.html -- to 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 22 09:29:25 2009 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 2203128C27C for ; Wed, 22 Apr 2009 09:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.404 X-Spam-Level: X-Spam-Status: No, score=-5.404 tagged_above=-999 required=5 tests=[AWL=-0.909, 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 sbntAt46REyT for ; Wed, 22 Apr 2009 09:29:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A0FD28C5BB for ; Wed, 22 Apr 2009 09:28:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwfH5-000MJp-7W for radiusext-data0@psg.com; Wed, 22 Apr 2009 16:26:15 +0000 Received: from [192.100.122.233] (helo=mgw-mx06.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwfGs-000MIx-GQ for radiusext@ops.ietf.org; Wed, 22 Apr 2009 16:26:08 +0000 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3MGPkee006239; Wed, 22 Apr 2009 19:25:49 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 19:25:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 19:25:46 +0300 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 22 Apr 2009 18:25:46 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Wed, 22 Apr 2009 18:25:45 +0200 From: To: CC: , , , , Date: Wed, 22 Apr 2009 18:25:44 +0200 Subject: RE: COMMENT: draft-ietf-radext-design Thread-Topic: COMMENT: draft-ietf-radext-design Thread-Index: AcnDWLPeVec5u9UGQNqaM0uxZp4ckQADOabQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F23F7FD6@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090422134846.E0ACF3A6C20@core3.amsl.com> <49EF2CFC.2090002@freeradius.org> In-Reply-To: <49EF2CFC.2090002@freeradius.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2009 16:25:46.0633 (UTC) FILETIME=[FDA57790:01C9C366] X-Nokia-AV: Clean Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: QWxhbiBUIERlS29rIHdyb3RlOg0KDQo+ICAgVGhlIGNvbW1lbnRzIGFyZSBOT1QgbGFyZ2VseSBl ZGl0b3JpYWwuICBUaGV5IGFyZSB0aGUgZGlyZWN0DQo+IHJlc3VsdCBvZiBtdWx0aXBsZSBhdHRl bXB0cyAoSS1EJ3MsIHZlbmRvcnMsIGV0Yy4pIHRvIGNyZWF0ZSBjb21wbGV4DQo+IGRhdGEgdHlw ZXMgd2hlcmUgbm9uZSBhcmUgbmVjZXNzYXJ5LiAgVGhlIHJlc3VsdCBpcyBpbmNyZWFzZWQNCj4g Y29tcGxleGl0eSBpbiB0aGUgcHJvdG9jb2wsIHRoZSBpbXBsZW1lbnRhdGlvbnMsIGFuZCBkZWNy ZWFzZWQNCj4gaW50ZXItb3BlcmFiaWxpdHkuDQo+IA0KPiAgIFJBRElVUyBpcyBhbiBhdXRob3Jp emF0aW9uIHByb3RvY29sIHRoYXQgcHJvdmlzaW9ucyBwcmUtZXhpc3RpbmcNCj4gc2VydmljZXMu ICBEZWZpbmluZyBuZXcgc2VydmljZXMgaW4gUkFESVVTIGlzIGV4cGxpY2l0bHkgb3V0IG9mDQo+ IHNjb3BlIG9mIHRoZSBwcm90b2NvbC4NCg0KWWVzLCBpdCdzIG91dHNpZGUgdGhlIHNjb3BlIG9m IFJBRElVUywgYnV0ICJzY29wZSBvZiBSQURJVVMiIGlzDQpub3QgdGhlIHNhbWUgdGhpbmcgYXMg InNjb3BlIG9mIHNvbWUgSW50ZXJuZXQtRHJhZnQiLg0KDQo+ICAgU2VjdGlvbiAyLjEuNSBzYXlz Og0KPiANCj4gCU5ldyBzZXJ2aWNlcyB1c2luZyBSQURJVVMgZm9yDQo+ICAgICAgICAgcHJvdmlz aW9uaW5nIFNIT1VMRCBiZSBkZWZpbmVkIGVsc2V3aGVyZSBhbmQgcmVmZXJlbmNlZCBpbiB0aGUN Cj4gICAgICAgICBSQURJVVMgc3BlY2lmaWNhdGlvbi4NCj4NCj4gICBTbyB5ZXMsIHdlIGFyZSBt YW5kYXRpbmcgdHdvIEktRCdzIGZvciBwcm92aXNpb25pbmcgbmV3IHNlcnZpY2VzDQo+IGluIFJB RElVUy4gIE9uZSBkb2N1bWVudCB0byBkZWZpbmUgdGhlIHNlcnZpY2UsIGFuZCBhbm90aGVyIHRv DQo+IGRlZmluZSBob3cgUkFESVVTIHByb3Zpc2lvbnMgdGhhdCBzZXJ2aWNlLiAgVGhpcyBpcyBu byBkaWZmZXJlbnQNCj4gdGhhbiBjcmVhdGluZyBNSUJzLiAgT25lIGRvY3VtZW50IGRlZmluZXMg dGhlIHByb3RvY29sIC8gc2VydmljZS4NCj4gQW5vdGhlciBvbmUgZGVmaW5lcyB0aGUgTUlCcy4N Cg0KVGhpcyBhcHByb2FjaCBpcyBub3QgYWx3YXlzIHVzZWQgZm9yIE1JQnMuIEZvciBleGFtcGxl LCB0aGUgSUVFRQ0KODAyLjExIHNwZWNpZmljYXRpb24gaW5jbHVkZXMgYm90aCB0aGUgcHJvdG9j b2wvc2VydmljZSAoODAyLjExKSBhbmQNCnRoZSBNSUIgaW4gdGhlIHNhbWUgZG9jdW1lbnQuDQoN CkFuZCBlLmcuIGRyYWZ0LWlldGYtaXNtcy1zZWNzaGVsbC0xNSBkZWZpbmVzIHRoZSBTU0ggdHJh bnNwb3J0IG1vZGVsDQppbiB0aGUgc2FtZSBJbnRlcm5ldC1EcmFmdCBhcyB0aGUgTUlCIGZvciBt YW5hZ2luZyBpdC4NCg0KQmVzdCByZWdhcmRzLA0KUGFzaQ0K -- to 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 22 09:45:29 2009 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 8565B28C25D for ; Wed, 22 Apr 2009 09:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-0.972, 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 Y9VVvFU6r8uA for ; Wed, 22 Apr 2009 09:45:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8976C3A6AFB for ; Wed, 22 Apr 2009 09:45:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwfXT-000NbA-Fs for radiusext-data0@psg.com; Wed, 22 Apr 2009 16:43:11 +0000 Received: from [198.152.13.100] (helo=co300216-co-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwfXH-000Na6-2w for radiusext@ops.ietf.org; Wed, 22 Apr 2009 16:43:05 +0000 X-IronPort-AV: E=Sophos;i="4.40,231,1238990400"; d="scan'208";a="168704185" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Apr 2009 12:42:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Apr 2009 12:42:50 -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: COMMENT: draft-ietf-radext-design Date: Wed, 22 Apr 2009 18:42:29 +0200 Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F23F7FD6@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMMENT: draft-ietf-radext-design Thread-Index: AcnDWLPeVec5u9UGQNqaM0uxZp4ckQADOabQAADGppA= References: <20090422134846.E0ACF3A6C20@core3.amsl.com> <49EF2CFC.2090002@freeradius.org> <808FD6E27AD4884E94820BC333B2DB7727F23F7FD6@NOK-EUMSG-01.mgdnok.nokia.com> From: "Romascanu, Dan (Dan)" To: , Cc: , , , , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of=20 > Pasi.Eronen@nokia.com >=20 > This approach is not always used for MIBs. For example, the IEEE > 802.11 specification includes both the protocol/service=20 > (802.11) and the MIB in the same document. >=20 The IEEE 802.11 MIB is not defined in an IETF document. Even in the case of the IEEE documents that define both the IEEE technology and management model as part of the same standard, these are separate sections at precise locations in the IEEE documents.=20 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 22 09:46:39 2009 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 B0C5E3A69BA for ; Wed, 22 Apr 2009 09:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-0.455, 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 M58ncJ-zPJcN for ; Wed, 22 Apr 2009 09:46:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 815BE28C291 for ; Wed, 22 Apr 2009 09:46:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwfZT-000Nlk-Tp for radiusext-data0@psg.com; Wed, 22 Apr 2009 16:45:15 +0000 Received: from [76.96.62.96] (helo=QMTA09.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwfZH-000NkM-OW for radiusext@ops.ietf.org; Wed, 22 Apr 2009 16:45:09 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA09.westchester.pa.mail.comcast.net with comcast id ifXU1b00B0cZkys59gl4mD; Wed, 22 Apr 2009 16:45:04 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA10.westchester.pa.mail.comcast.net with comcast id igl31b0074H2mdz3Wgl3u5; Wed, 22 Apr 2009 16:45:04 +0000 From: "Dave Nelson" To: , Cc: , , , , References: <20090422134846.E0ACF3A6C20@core3.amsl.com> <49EF2CFC.2090002@freeradius.org> <808FD6E27AD4884E94820BC333B2DB7727F23F7FD6@NOK-EUMSG-01.mgdnok.nokia.com> Subject: RE: COMMENT: draft-ietf-radext-design Date: Wed, 22 Apr 2009 12:45:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F23F7FD6@NOK-EUMSG-01.mgdnok.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnDWLPeVec5u9UGQNqaM0uxZp4ckQADOabQAACyCiA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi Pasi, > > RADIUS is an authorization protocol that provisions pre-existing > > services. Defining new services in RADIUS is explicitly out of > > scope of the protocol. > > Yes, it's outside the scope of RADIUS, but "scope of RADIUS" is > not the same thing as "scope of some Internet-Draft". If you look at my response in this thread, you'll note that I concur with Alan, but with a slightly different slant. In my view, this has less to do with document content, and more to do with separation of concerns. IF there is an existing (or emerging) service deployed in NASes and IF there is a need to authorize / provision that service with RADIUS, THEN write an RADIUS extension draft. > > So yes, we are mandating two I-D's for provisioning new services > > in RADIUS. One document to define the service, and another to > > define how RADIUS provisions that service. This is no different > > than creating MIBs. One document defines the protocol / service. > > Another one defines the MIBs. > > This approach is not always used for MIBs. For example, the IEEE > 802.11 specification includes both the protocol/service (802.11) and > the MIB in the same document. > > And e.g. draft-ietf-isms-secshell-15 defines the SSH transport model > in the same Internet-Draft as the MIB for managing it. I agree that the MIB Module example is not the best illustration of the concept. One would not expect the protocol being managed to be defined within the MIB Module. It's OK to include a MIB Module in the document that defines the protocols, but not the other way around. No? Regards, 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 Wed Apr 22 22:21:40 2009 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 F380F3A6B2F for ; Wed, 22 Apr 2009 22:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-0.969, 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 lgPEv9yGg9MD for ; Wed, 22 Apr 2009 22:21:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05A183A6CAF for ; Wed, 22 Apr 2009 22:21:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwrLL-00021x-ST for radiusext-data0@psg.com; Thu, 23 Apr 2009 05:19:27 +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.69 (FreeBSD)) (envelope-from ) id 1LwrL9-00020W-Ci for radiusext@ops.ietf.org; Thu, 23 Apr 2009 05:19:21 +0000 X-IronPort-AV: E=Sophos;i="4.40,234,1238990400"; d="scan'208";a="143876048" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Apr 2009 01:19:11 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Apr 2009 01:19:10 -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: draft-ietf-radext-design deferred for the 5/7 telechat Date: Thu, 23 Apr 2009 07:18:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-radext-design deferred for the 5/7 telechat Thread-Index: AcnD0wAchHQt8guvSfS8YujOiUjTCw== From: "Romascanu, Dan (Dan)" To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: The I-D was deferred by AD Cullen Jennings from the agenda of the IESG telechat today to 5/7.=20 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 Thu Apr 23 00:02:32 2009 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 330B628C6AA for ; Thu, 23 Apr 2009 00:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=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 IfH2h5dZ-h3F for ; Thu, 23 Apr 2009 00:02:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D94AE28C6B5 for ; Thu, 23 Apr 2009 00:01:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwsuR-0009Rc-Cn for radiusext-data0@psg.com; Thu, 23 Apr 2009 06:59:47 +0000 Received: from blu0-omc4-s24.blu0.hotmail.com ([65.55.111.163]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwsuE-0009Qz-4M for radiusext@ops.ietf.org; Thu, 23 Apr 2009 06:59:40 +0000 Received: from BLU137-W33 ([65.55.111.137]) by blu0-omc4-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 23:59:33 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c1c059b6-77d6-445f-a0dd-80b1d2ff3018_" X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: "David B. Nelson" , , CC: "iesg@ietf.org" , "radext-chairs@tools.ietf.org" , , , "radiusext@ops.ietf.org" Subject: RE: COMMENT: draft-ietf-radext-design Date: Wed, 22 Apr 2009 23:59:33 -0700 Importance: Normal In-Reply-To: References: <20090422134846.E0ACF3A6C20@core3.amsl.com> <49EF2CFC.2090002@freeradius.org> <808FD6E27AD4884E94820BC333B2DB7727F23F7FD6@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2009 06:59:33.0691 (UTC) FILETIME=[0E9BA8B0:01C9C3E1] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_c1c059b6-77d6-445f-a0dd-80b1d2ff3018_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > And e.g. draft-ietf-isms-secshell-15 defines the SSH transport model > > in the same Internet-Draft as the MIB for managing it. >=20 > I agree that the MIB Module example is not the best illustration of the > concept. One would not expect the protocol being managed to be defined > within the MIB Module. It's OK to include a MIB Module in the document t= hat > defines the protocols=2C but not the other way around. No? I'd agree with Pasi in the case where the service is defined (either within= the same document or elsewhere). In such a situation=2C it should be suff= icient for the RADIUS attribute document to either reference the service de= finition (if it is in another document) or to include it within the same do= cument. This is an editorial decision outside the scope of the Design Guid= elines document.=20 The issue that this text was attempting to address was a situation in which= there is no definition for the service=2C either within the document or el= sewhere. In this situation the Design Guidelines document is pointing out = that designing management attributes (or MIBs for that matter) for a servic= e that is undefined is not a "best current practice".=20 For example=2C while a "RADIUS Attributes for IPv8" document might meet all= the RADIUS Design guidelines=2C the fact that the document includes no ref= erence for IPv8 is a problem of a non-editorial nature. Believe it or not=2C this problem has actually come up in practice (more th= an once!). =20 --_c1c059b6-77d6-445f-a0dd-80b1d2ff3018_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B >=3B And e.g. draft-ietf-isms-secshell-15 defines the SSH transpor= t model
>=3B >=3B in the same Internet-Draft as the MIB for managing= it.
>=3B
>=3B I agree that the MIB Module example is not the be= st illustration of the
>=3B concept. One would not expect the protoco= l being managed to be defined
>=3B within the MIB Module. It's OK to = include a MIB Module in the document that
>=3B defines the protocols= =2C but not the other way around. No?

I'd agree with Pasi in the ca= se where the service is defined (either within the same document or elsewhe= re). =3B In such a situation=2C it should be sufficient for the RADIUS = attribute document to either reference the service definition (if it is in = another document) or to include it within the same document. =3B This i= s an editorial decision outside the scope of the Design Guidelines document= .

The issue that this text was attempting to address was a situatio= n in which there is no definition for the service=2C either within the docu= ment or elsewhere. =3B In this situation the Design Guidelines document= is pointing out that designing management attributes (or MIBs for that mat= ter) for a service that is undefined is not a "best current practice".
=
For example=2C while a "RADIUS Attributes for IPv8" document might meet= all the RADIUS Design guidelines=2C the fact that the document includes no= reference for IPv8 is a problem of a non-editorial nature.

Believe = it or not=2C this problem has actually come up in practice (more than once!= ). =3B

= --_c1c059b6-77d6-445f-a0dd-80b1d2ff3018_-- -- to 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 23 04:27:41 2009 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 0353528C286 for ; Thu, 23 Apr 2009 04:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.460, 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 h6g7N52UTOtv for ; Thu, 23 Apr 2009 04:27:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECEB828C0DB for ; Thu, 23 Apr 2009 04:27:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwx3o-0009Of-1T for radiusext-data0@psg.com; Thu, 23 Apr 2009 11:25:44 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwx3b-0009NS-4C for radiusext@ops.ietf.org; Thu, 23 Apr 2009 11:25:37 +0000 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA01.westchester.pa.mail.comcast.net with comcast id iyNo1b0050vyq2s51zRXJv; Thu, 23 Apr 2009 11:25:31 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA05.westchester.pa.mail.comcast.net with comcast id izRV1b00K4H2mdz3RzRVM1; Thu, 23 Apr 2009 11:25:31 +0000 From: "Dave Nelson" To: "'Bernard Aboba'" , , Cc: , , ,

Extended=20 Attributes=20 Issue Number	Status	Type	Description<= /b>	Owner
Issue 225	EXTENDED-08	Technical	Review	Alan=20 DeKok
Issue 251	Pending	Technical	Review	Bernard=20 Aboba
Issue 278	EXTENDED-08	Technical	Comments	Alan=20 DeKok
Issue 279	EXTENDED-08	Technical	Comments	Stefan=20 Winter
Issue 290	No Discussion	Technical	RFC=20 4005bis Dependency	Bernard=20 Aboba
Issue 298	No Discussion	Technical	Extended Attributes Restriction	Bernard=20 Aboba

Extended=20 Attributes=20 Issue Number	Status	Type	Description<= /b>	Owner
Issue 225	EXTENDED-08	Technical	Review	Alan=20 DeKok
Issue 251	Pending	Technical	Review	Bernard=20 Aboba
Issue 278	EXTENDED-08	Technical	Comments	Alan=20 DeKok
Issue 279	EXTENDED-08	Technical	Comments	Stefan=20 Winter
Issue 290	No Discussion	Technical	RFC=20 4005bis Dependency	Bernard=20 Aboba
Issue 298	No Discussion	Technical	Extended Attributes Restriction	Bernard=20 Aboba

Statu= s Server Issue Number	Status	Type	Description<= /b>	Owner
Issue 285	Pending	Technical	Question	Alan=20 DeKok
Issue 288	Pending	Technical	Review	Stig Venaas
Issue 289	No Discussion	Editorial	Editorial Comments	Stig Venaas

RADIUS = over TCPIssue Number	Status	Type	Description<= /b>	Owner
Issue 291	Pending	Technical	UDP/TCP Translation	Alan=20 DeKok
Issue 292	Pending	Technical	Applicability	Alan=20 DeKok
Issue 293	Pending	Technical	Watchdog Timer	Alan=20 DeKok
Issue 294	No Discussion	Technical	Document Status	Bernard=20 Aboba
Issue 295	Pending	Technical	Head of Line Blocking	Alan=20 DeKok