Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 12 Dec 2006 21:15:10 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: FW: [IANA #46166] Request for allocation of NAS-Port-Type values Date: Tue, 12 Dec 2006 13:14:11 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >From: "Amanda Baber via RT" >Reply-To: iana-prot-param@icann.org >To: bernard_aboba@hotmail.com >Subject: [IANA #46166] Request for allocation of NAS-Port-Type values Date: >Tue, 12 Dec 2006 11:38:31 -0800 > >Dear Bernard, > >The following values for RADIUS Attribute 61, NAS-Port-Type, >have been added to the registry: > >27 Wireless - IEEE 802.16 >28 Wireless - IEEE 802.20 >29 Wireless - IEEE 802.22 > >Please see the following: > >http://www.iana.org/assignments/radius-types > >Best regards, > >Amanda Baber >IANA -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 10 Dec 2006 21:01:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [IANA #46166] Request for allocation of NAS-Port-Type values Date: Sun, 10 Dec 2006 16:03:01 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6029C8EB6@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [IANA #46166] Request for allocation of NAS-Port-Type values Thread-Index: AcccnNfk61kQNGEISOmHIsyFXc+n5AAAREog From: "Greg Weber \(gdweber\)" To: "Bernard Aboba" , Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1301; t=1165784432; x=1166648432; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gdweber@cisco.com; z=From:=20=22Greg=20Weber=20\(gdweber\)=22=20 |Subject:=20RE=3A=20[IANA=20#46166]=20Request=20for=20allocation=20of=20N AS-Port-Type=20values |Sender:=20; bh=5UOIEPV5fwW7NwXBjr5DRztmcTH4xqgM5tssSvwmD3c=; b=RsFcN+JMEWi5jmW0mE0ECxGlZ1Nfrj/P5VrGClsInmndRR5qLBoVt/TzZ0isGXqWcyuWWSnk fW7lbVRInoiwYI9z5YXC5o2tcp/21GYUZu2cv4f7kLUZ5O8aVMV3oKsf; Authentication-Results: sj-dkim-7; header.From=gdweber@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, December 10, 2006 3:49 PM > To: aland@nitros9.org > Cc: radiusext@ops.ietf.org > Subject: Re: [IANA #46166] Request for allocation of=20 > NAS-Port-Type values >=20 > RFC 4603 explicitly requested an allocation of values 30-34,=20 We started at 30 just to leave some open space in case anything was allocated between when we implemented & when we standardized, not because 27-29 were used. Greg > which makes me=20 > wonder whether a vendor isn't already using 27-29. >=20 >=20 > >From: "Alan DeKok" > >To: "Bernard Aboba" > >CC: radiusext@ops.ietf.org > >Subject: Re: [IANA #46166] Request for allocation of=20 > NAS-Port-Type values=20 > >Date: Sun, 10 Dec 2006 14:28:39 -0500 > > > >"Bernard Aboba" wrote: > > > Is there any existing usage of values 27-29? > > > > Not that I can see. > > > > Alan DeKok. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 10 Dec 2006 20:50:01 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org Cc: radiusext@ops.ietf.org Bcc: Subject: Re: [IANA #46166] Request for allocation of NAS-Port-Type values Date: Sun, 10 Dec 2006 12:49:17 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed RFC 4603 explicitly requested an allocation of values 30-34, which makes me wonder whether a vendor isn't already using 27-29. >From: "Alan DeKok" >To: "Bernard Aboba" >CC: radiusext@ops.ietf.org >Subject: Re: [IANA #46166] Request for allocation of NAS-Port-Type values >Date: Sun, 10 Dec 2006 14:28:39 -0500 > >"Bernard Aboba" wrote: > > Is there any existing usage of values 27-29? > > Not that I can see. > > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 10 Dec 2006 19:40:52 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: [IANA #46166] Request for allocation of NAS-Port-Type values cc: radiusext@ops.ietf.org Date: Sun, 10 Dec 2006 14:28:39 -0500 Message-Id: <20061210192839.3D9FA16CE0@mail.nitros9.org> "Bernard Aboba" wrote: > Is there any existing usage of values 27-29? Not that I can see. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 09 Dec 2006 00:30:43 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: [IANA #46166] Request for allocation of NAS-Port-Type values Date: Fri, 08 Dec 2006 16:29:47 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Is there any existing usage of values 27-29? >From: "Amanda Baber via RT" >Reply-To: iana-prot-param@icann.org >To: bernard_aboba@hotmail.com >Subject: [IANA #46166] Request for allocation of NAS-Port-Type values Date: >Fri, 08 Dec 2006 14:32:40 -0800 > >Dear Bernard, > >It appears that you're requesting three assignments: > >Value Description >------------------------------------------------- >TBD Wireless - IEEE 802.16 [802.16] >TBD Wireless - IEEE 802.20 [802.20] >TBD Wireless - IEEE 802.22 [802.22] > >In the registry, values 27-29 are listed as "unassigned." >Do you know of any reason why these values shouldn't be >used for these assignments? > >Thanks, > >Amanda Baber >IANA -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Dec 2006 18:25:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Minutes of the RADEXT WG session at IETF-67 Date: Fri, 8 Dec 2006 13:24:36 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4A0A@MABOSEVS2.ets.enterasys.com> Thread-Topic: Minutes of the RADEXT WG session at IETF-67 Thread-Index: Acca9h1Ox9K3XL03SDKuidHLsw05Yg== From: "Nelson, David" To: Here are the RADEXT minutes, as posted to the meeting material web site. Please review for any errors or omissions and comment back to the list. Thanks! ------------------------------------------------------------------------ IETF 67 RADEXT WG Minutes Harbor Island I 9:00 - 11:30 AM Tuesday, November 7, 2006 Note takers: Mauricio Sanchez, Madjid Nakhjiri Jabber scribe: Sharon Chisholm Minutes editor: Dave Nelson * Meeting started at 9:05am * Agenda bashing. No changes. Look for info in http://www.drizzle.com/~aboba/RADEXT/ Look for presentations at IETF meeting material page: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 7 * Bernard went through WG document status. ------------------------------------------ - 7 docs published as RFCs, 4 RADIUS IPv6 MIBs and 2 Dynamic RADIUS MIBs=20 - some comments on the MIBs came after RFC publications, but mostly editorial - Dave described comments made on the RADIUS MIB RFCs relating to structure and format; No substantive comments, just editorial. * Wolfgang Beck went through RFC 4590 errata issues. ---------------------------------------------------- - A week after the RFC publication, an implementer sent email about an error about an IANA type. - It seems to be easier to change the IANA website than to change the RFC. - Bernard asks whether WG feels that errata are severe enough to cause confusion - Alan DeKok (Infoblox) feels strongly that there are issues at hand and should be addressed; He ran into questions. - Bernard recommends that minor clarifications be made; IANA table updates. Feels that a quick spin of document is possible - Bernard moreover recommends that issues not be treated as errata; Indicates that a quick "bis" draft and WGLC would be advisable. * Mauricio Sanchez presented NAS-Filter-Rule and NAS-Traffic-Rule draft ----------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules- - A draft comparison slide was shown between the radext-filter-rules and radext-filter-05 - the filter-rule draft is simpler since it is based on Diameter,=20 - there are two attributes in the first draft and one attribute in the second draft. - NAS-filter-rule status - 5 new draft versions since IETF66 - resolved issues: attribute length and Diameter-READIUS GW behavior - open issues: concatenation/splitting - Base questions: how to split a long rule across multiple rules? - 6 proposals since IETF 65 - usage of tag field was favorite out of IETF 66. - It seems that a consensus is being reached quickly on this issue. - Plan to go to WG last call with 05 draft. - Bernard: Can we deal with the issue right now? What if Diameter sends both kinds of attribute?=20 - Implementers of Diameter come and say what use does it have in RADIUS and why? - Comment: - Bernard: Anybody has an objection to have a MUST not use both here? - Comment: - Bernard: OK, done.=20 - NAS-traffic-rule status - no new drafts since IETF 65 - Editor to go talk to individuals to get opinions - big variety of open issues existed: -- accounting issue mostly closed waiting for 3GPP insights -- NAS filter rule accounting - Diameter compatibility=20 - Bernard: There is a VLAN attribute draft that is not just for RADIUS but also for Diameter. - AD: Pointed the charter to Dave: All RADIUS functions must be compatible with=20 - Diameter and attributes must be reused as much as possible. - Next step: To close the issues to talk to issue owners in the next couple of weeks - new version 02 within a month * Alan DeKok presented RADIUS issues & fixes draft -------------------------------------------------- - A list of clarification (e.g. on EAP), a list of correction, question relatively little discussion or disagreement on list about the issues and fixes draft. - Alan asks the group how many have people have read the draft; Few people have - Dave suggests we take it to last call to force everyone to read it - Someone pointed out that this draft is not a WG item, yet is already being considered for last call. Bernard contends that this has been done in the past to take an individual submission and turn it into a WG item at the same time it went to last call. - Dave asks group whether anyone objects to taking document to working group last call. No one does. Dave and Bernard to confirm consensus on email list.=20 * Dave presented NAS-Port-Type attribute draft ---------------------------------------------- - Dave asks group whether to take document to WG last call - Pasi Eronen says that draft has five lines of technical content, just ship it. - Bernard points out that the RADIUS IANA Considerations in RRC 3575 says additional values for attributes can be approved by designated experts do not require a published specification.=20 - Bernard suggests that it not be published as an RFC to reduce IASA / RFC Editor publishing costs.=20 - Simply request the values from IANA. - WG chairs will provide IANA with an expert review contact. - AD: As long as we have regular get-togethers where people oversee these=20 assignments. * Bernard presented WLAN attributes draft ----------------------------------------- - Some attributes already assigned in RFC 4072 - Pre-auth support -- It was discussed in HOKEY BOF -- There is a use case in 802.11 and there are some tricky issues - SSID attribute - Pre-auth key lifetime attribute -- A STA pre-auths with an AP, but it does not know what the AP SSID is, and the AAA server does not know the diff between pre-auth and full auth. -- Situation, when the admin want to cache the keys just for a short time when it is pre-auth compared to longer time for regular auth. - Bernard asked group whether to make draft an official WG item - Dave questions whether to split document into attributes that are necessary now and those that need further definition. Draft is already behind from a milestone perspective. Bernard points out that IEEE 802.11r group may have requirements, but is busy with other issues at this point. - Dave asks group whether group has preference on what to do with document - Majid points out that HOKEY does have dependency on AAA pre-auth requirements that from a timeline perspective are further out. =20 - Majid asks about the process of getting comments from .11r group; Bernard explains the formal liaison process to request comments - Bernard suggests that we submit a liaison request to IEEE 802.11r to get them to review document. * Glen Zorn presented Extended RADIUS attributes draft ------------------------------------------------------ - Glen asks how many people have read it; Only a couple have - Alan DeKok points out that he has comments, but has separate presentation for his points.=20 - Dave asks Glen how extended attributes should be treated by servers not supporting extended attributes; Glen replies that servers that don't understand the attribute will ignore it, whether that's a problem is a different question. Glen expects all contemporary servers to support extended attributes. If ancient servers can't, then so be it.=20 - Dave asks whether having just an 8-bit type value for extended attributes is too small. An 8-bit value would only allow for 256 additional extended attributes. Glen believes this is good because it would force conservation and have a built-in penalty for creating new attributes willy-nilly. If the type space were once again exhausted, a new vendor-id would have to be allocated. =20 * Alan DeKok goes through his commentary of extended RADIUS ----------------------------------------------------------- - Glen agrees with the argument that a non-zero vendor-ID should be allocated; He went on to say that GEOPRIV should be given their own vendor-id; He argues that the value of 0 traditionally means IETF. - Dave points out that it's unclear of whether multiple vendor-id values can be registered to a singe entity; Someone in group says that it is possible. - Dave made comment on tag and feels that it is of value; It's not a con. Alan agrees that it's the most practical option available; Points out that EAP clients and servers are currently forced to mangle attributes. It would be useful just to do it once.=20 - Glen points out that Alan's presentation isn't as much a criticism as an exposition of issues; Questions whether there will be any short-term decision to make progress; Dave responds that a large block of time was allocated up front but asks opinion of group. Alan says he's fine with the state of the document other than vendor-id. Suggests that group pick a vendor-id value and have some preliminary interoperability testing. Bernard says that the extended attribute draft is necessary to be able to complete ongoing attribute work; Code space will run out based on proposed work and something must be done.=20 - Someone points out that granting control code space control to other groups=20 (other than RADEXT) needs to be considered. Bernard points out that there are already something like 12 different dialects of RADIUS. IESG needs to answer whether this is acceptable or not. - Glen suggests that allocation of vendor-id/type values be separated out from format issues. Bernard nodded in agreement. - Dave opens floor to ask group what should be done with document * Majid points out that other groups do need attributes, groups can't wait. Sees value in allowing groups control their own destiny and manage their own attribute space. * Glen recommends cutting to the chase and making document a WG item.=20 * Bernard recommends that a new version with local RADEXT issues be addressed, thereafter document should be open to other groups for review. * Glen points out that making document a WG item would force control of document by greater group than where it is as an individual submission. Glenn wants to be under the control of the chairs. * Group agrees to make a new version and distribute to greater community. * Dave presents RADIUS guidelines draft --------------------------------------- - Bernard comments that the objectionable part of the draft is to try to deprecate old RFC and say that current way RADIUS works/designed is bad. Objective of document should be limited to things that prevent deployment, such as those things that force server code change issues. Document should strive for architectural purity, since most don't force server code changes. - Bernard wishes that document be basis for other groups to define their own attributes that adhere to guidelines and not force groups to pass their attributes through RADEXT. Dave counters that MIB example is not a valid example. - Bernard suggests that document remove extended attribute discussion and other things people find objectionable. Take a look at the core and see whether enough remains to take on as official WG item. - Glen Z. and Hannes T. step forward to volunteer as co-editors of document * Dave presents crypto-agility work item ---------------------------------------- - Glen questions where security requirements are documented. Dave responds that Russ said to write security requirements as stated to point to SAAG=20 - Hannes T. asks whether this work item would provide end-to-end security between client and server. Dave and Bernard say no. This document only describes how new crypto algorithms can be used in the current protocol framework. Dave states that genesis is document is to address the security issues arising from the recent identified weaknesses in MD5. =20 - Someone comments that if addressing MD5 issues is really the problem at hand, then the document should state that as the scope. Feels current document has many general requirements. Bernard points out that there are probably two paragraphs that actually address the MD5 issue. Feels that document needs to be explicit in what it intends to fix. Bernard recommends title 'Crypto-Agility Goals in RADIUS' - Someone wanted confirmation that this work item was not undertaking a huge gap analysis. Bernard says emphatically no.=20 - Joe S. is concerned by 'negotiation'. Dave contends that there is already a very simple 'negotiation' present in RADIUS. The client proposes via hint attributes in the Access-Request. The server disposes via provisioning attributes in the Access-Accept. This work item would not upset the balance in RADIUS. - Glen concerned about the recommending MD5 as lowest common denominator when no other crypto supported. Feels like a security issue to him. * Hannes presented GEOPRIV cross-WG review item ----------------------------------------------- - Bernard asked about document status. - Hannes unsure and would need to look at the issue tracker. * Hannes presented RADIUS MIPv6 draft ------------------------------------- - Glen asks whether acceptance of extended radius attribute draft will have impact. Hannes says it depends. Glen feels that remaining radius standard code-space should be set aside for future use, a conservation measure - Dave says that RFC 3575 would need to be updated to ensure reservation of remaining code space. * Vidya presented handover key draft ------------------------------------ - Group discussed what to do with draft; Bernard and Jari agree that this draft conceivably create a new authentication method for RADIUS, just like digest authentication.=20 - Glen points out that an existing individual submission, key request, that presumably does some of the same things Vidya's draft provides. Questions arises on whether mechanics used by Glen's draft are similar to handover draft. Glen suggests that key request draft be reviewed for changes that would address handover draft.=20 - Bernard comments he doesn't understand how this draft has anything to do with keying. Vidya explains how key material is transferred as part of handover exchange. =20 - Bernard asks whether handshake is stateful or stateless. Vidya says it's stateless. Bernard now sees parallels to other authentication transactions, like http digest authentication.=20 - Bernard asks what is the question MIPSHOP desires RADEXT to answer. Is it the case that all options needs to be reviewed, just one? Jari says that there may be some of both. - Someone expresses concern of using RADIUS as a key server. Vidya points out that key material is not tied to the RADIUS server and can be logically separated from server. - Glen points out that this draft is shoehorning a function not serviced well by RADIUS; It's key exchange protocol that happens to use RADIUS. Glen doesn't feel this is the way to go. * Dave notes that we are over our allotted time, so remaining discussion, as well as the remaining agenda item will need to be discussed on the WG mailing list. Regards, =20 Dave =20 David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 Phone: (978) 684-1330 =20 E-mail: dnelson@enterasys.com =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Dec 2006 15:06:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Upcoming Diameter Interop Date: Fri, 8 Dec 2006 16:05:06 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC023C96FE@MCHP7R6A.ww002.siemens.net> Thread-Topic: Upcoming Diameter Interop Thread-Index: Acca2j7u63tLlaryShaGyMzXEIJBaQ== From: "Tschofenig, Hannes" To: , Hi all,=20 our interop event planning is finished. =20 WHAT? Diameter Interoperability Event Further information regarding agenda, test framework, venue and travel information as well as on-line registration are available at: http://www.diameterinterop.com =20 WHEN? January 29 - February 2, 2007=20 =20 WHERE? Orlando, Florida (hosted by IntelliNet Technologies) =20 WHO? Companies implementing Diameter, Diameter extensions and Diameter applications A copy-and-paste from the press announcement:=20 "=20 The Diameter Interoperability Event provides an excellent opportunity for vendors of the Diameter protocol and applications to test their implementations in a friendly setting and get a better understanding of the protocol behavior. Discussions with peers and the experts from DiME provide a forum to realize an industry leading implementation. We are expecting a substantial number of participating companies and products, including the base protocol from several vendors as well as a broad range of applications using the protocol. This offers you the opportunity to further refine your own products and assure their interoperability. " IMPORTANT: Please register at http://www.diameterinterop.com=20 (deadline: January 15, 2007)=20 Ciao Hannes & John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 07 Dec 2006 23:48:20 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'RADIUS Filter Rule Attribute' to Proposed Standard (draft-ietf-radext-filter) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Thu, 07 Dec 2006 18:47:36 -0500 The IESG has received a request from the RADIUS EXTensions WG to consider the following document: - 'RADIUS Filter Rule Attribute ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-12-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-06.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 21:19:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Document review request Date: Tue, 5 Dec 2006 16:18:22 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49F5@MABOSEVS2.ets.enterasys.com> Thread-Topic: Document review request Thread-Index: AccYsLOR0FxEg7QgQhip5ojm8f5C0QAAdu1Q From: "Nelson, David" To: At the risk of a duplicate posting, I'm forwarding this message again, as it seems to be "stuck" somewhere.... -----Original Message----- From: Nelson, David=20 Sent: Tuesday, December 05, 2006 4:03 PM To: radiusext@ops.ietf.org; dime@ietf.org Cc: 'mip4@ietf.org'; 'mip6@ietf.org'; 'mipshop@ietf.org' Subject: Consideration of draft-lior-radius-attribute-type-extension-01 in RADEXT WG The RADEXT WG has a charter deliverable for an extended form of RADIUS attribute. The apparent consensus in the WG is to solve a very simple set of problems in this space, including the pending exhaustion of the standard RADIUS attribute IDs, a consistent mechanism for application layer fragmentation and reassembly for Diameter interoperability, and a consistent mechanism for grouping of attributes for data structuring, also for Diameter interoperability. Given the list of proposed work in RADEXT and other IETF WGs with RADIUS extensions work on their charters, it is conceivable that we might exhaust the existing IANA RADIUS registry for Attribute Types fairly soon. Therefore, this work is considered to be of some urgency. The structure of the extended attribute format currently under consideration may require changes in various RADIUS extensions drafts in RADEXT and other working groups. This assumes that at least some of these documents will ultimately use the RADIUS extended attribute allocations. The RADEXT WG Chairs are requesting that the RADEXT WG and all other affected WGs please review the following document: http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext ension-01.txt Please comment as to whether this document is ready for adoption as a RADEXT WG work item, and provide comments as to suggested changes or improvements. Please use the RADEXT Issue Tracker format template, found at http://www.drizzle.com/~aboba/RADEXT/ and submit your comments to the RADEXT WG mailing list with the keyword "New Issue" in the subject header. radiusext@ops.ietf.org Please respond by December 22, 2006. Once all the resultant open issues have been resolved, the RADEXT WG Chairs expect that a WGLC will be issued on the revised draft soon thereafter, early in 2007. Thank you, in advance, for your timely review, especially during this busy holiday season. Regards, =20 Dave Nelson Bernard Aboba Co-Chairs, RADEXT WG -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 21:03:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Consideration of draft-lior-radius-attribute-type-extension-01 in RADEXT WG Date: Tue, 5 Dec 2006 16:02:41 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49F4@MABOSEVS2.ets.enterasys.com> Thread-Topic: Consideration of draft-lior-radius-attribute-type-extension-01 in RADEXT WG Thread-Index: AccYsLOR0FxEg7QgQhip5ojm8f5C0Q== From: "Nelson, David" To: , Cc: , , The RADEXT WG has a charter deliverable for an extended form of RADIUS attribute. The apparent consensus in the WG is to solve a very simple set of problems in this space, including the pending exhaustion of the standard RADIUS attribute IDs, a consistent mechanism for application layer fragmentation and reassembly for Diameter interoperability, and a consistent mechanism for grouping of attributes for data structuring, also for Diameter interoperability. Given the list of proposed work in RADEXT and other IETF WGs with RADIUS extensions work on their charters, it is conceivable that we might exhaust the existing IANA RADIUS registry for Attribute Types fairly soon. Therefore, this work is considered to be of some urgency. The structure of the extended attribute format currently under consideration may require changes in various RADIUS extensions drafts in RADEXT and other working groups. This assumes that at least some of these documents will ultimately use the RADIUS extended attribute allocations. The RADEXT WG Chairs are requesting that the RADEXT WG and all other affected WGs please review the following document: http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext ension-01.txt Please comment as to whether this document is ready for adoption as a RADEXT WG work item, and provide comments as to suggested changes or improvements. Please use the RADEXT Issue Tracker format template, found at http://www.drizzle.com/~aboba/RADEXT/ and submit your comments to the RADEXT WG mailing list with the keyword "New Issue" in the subject header. radiusext@ops.ietf.org Please respond by December 22, 2006. Once all the resultant open issues have been resolved, the RADEXT WG Chairs expect that a WGLC will be issued on the revised draft soon thereafter, early in 2007. Thank you, in advance, for your timely review, especially during this busy holiday season. Regards, =20 Dave Nelson Bernard Aboba Co-Chairs, RADEXT WG -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 20:51:41 +0000 Message-ID: From: "Bernard Aboba" To: bernard_aboba@hotmail.com, alper.yegin@yegin.org, dnelson@enterasys.com, yohba@tari.toshiba.com, radiusext@ops.ietf.org Bcc: Subject: RE: Status of draft-yan-radext-port-type-01.txt Date: Tue, 05 Dec 2006 12:50:59 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed I sent email to IANA, cc:'ing the document author, asking for the allocation to be approved. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 20:36:51 +0000 Message-ID: From: "Bernard Aboba" To: alper.yegin@yegin.org, dnelson@enterasys.com, yohba@tari.toshiba.com, radiusext@ops.ietf.org Bcc: Subject: RE: Status of draft-yan-radext-port-type-01.txt Date: Tue, 05 Dec 2006 12:35:50 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >WiMAX Forum needs IEEE 802.16 NAS port type assignment for Release 1 (which >is planned to be finalized within a month). It'd be appreciated if the IANA >assignment process can be expedited. As Dave noted, there is no problem with this request, which was discussed on the RADEXT WG list quite a while ago, as well as at IETF 67. Has a request been sent to IANA? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 16:18:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Status of draft-yan-radext-port-type-01.txt Date: Tue, 5 Dec 2006 11:17:45 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49EF@MABOSEVS2.ets.enterasys.com> Thread-Topic: Status of draft-yan-radext-port-type-01.txt Thread-Index: AccYhqv8oHxKoXNoSBGBtUAlcG3/5AAAJWag From: "Nelson, David" To: "CTO YAN Renxiang" Cc: I think the specific action item should be for the author of this I-D (copied on this e-mail) to extract the salient information from the I-D, and submit a written request to IANA for allocation within the RADIUS registry, as per the provisions of RFC 3575. The salient information would be a precise and concise description of the port types being requested, such that it will be self-documenting in the RADIUS IANA registry. For example: NAS-Port-Type Value This request is for new values for the RADIUS NAS-Port-Type=20 attribute from the RADIUS Types registry [], according to the allocation policy given in [RFC3575]. This request is for the following values: Value Description ------------------------------------------------- TBD Wireless - IEEE 802.16 [802.16] TBD Wireless - IEEE 802.20 [802.20] TBD Wireless - IEEE 802.22 [802.22] > It would be very much appreciated if NAS-Port-Type for 802.16 is > quickly assigned in the RADEXT chairs' recommended way, because IEEE > 802.21 specification has some dependency on NAS-Port-Type values. > > > > What is the status of this I-D? > > > > > > I think I-D is important because it defines NAS-Port-Type > > > for several new wireless technologies including 802.16. > > > > I'm still working on the minutes of the RADEXT WG session at IETF-67, > > however, the discussion of this document in the meeting can be > > summarized as follows: > > > > -- The proposal to register new code points for the NAS-Port-Type > > attribute in the RADIUS IANA registry is fine. > > > > -- This attribute does not require a published specification. We can > > save the cost of publishing an RFC. > > > > -- The recommendation of the WG Chairs was to submit a request to IANA > > for the assignment, and the RADEXT Chairs will work with IANA to see > > that any necessary expert review is provided. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 16:13:06 +0000 From: "Alper Yegin" To: "'Nelson, David'" , "'Yoshihiro Ohba'" , Subject: RE: Status of draft-yan-radext-port-type-01.txt Date: Tue, 5 Dec 2006 17:59:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AccYgH8ZZ/xmWJhJTPeaDlCgWU0hmgAAfBMgAADAhtA= Message-ID: <0MKoyl-1Grchr3aLX-0003zB@mrelay.perfora.net> WiMAX Forum needs IEEE 802.16 NAS port type assignment for Release 1 (which is planned to be finalized within a month). It'd be appreciated if the IANA assignment process can be expedited. Regards, Alper, on behalf of WiMAX Forum NWG Security team > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Nelson, David > Sent: Tuesday, December 05, 2006 5:36 PM > To: Yoshihiro Ohba; radiusext@ops.ietf.org > Subject: RE: Status of draft-yan-radext-port-type-01.txt > > Yoshihiro Ohba writes... > > > What is the status of this I-D? > > > > I think I-D is important because it defines NAS-Port-Type > > for several new wireless technologies including 802.16. > > I'm still working on the minutes of the RADEXT WG session at IETF-67, > however, the discussion of this document in the meeting can be > summarized as follows: > > -- The proposal to register new code points for the NAS-Port-Type > attribute in the RADIUS IANA registry is fine. > > -- This attribute does not require a published specification. We can > save the cost of publishing an RFC. > > -- The recommendation of the WG Chairs was to submit a request to IANA > for the assignment, and the RADEXT Chairs will work with IANA to see > that any necessary expert review is provided. > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 16:02:25 +0000 Date: Tue, 05 Dec 2006 11:01:13 -0500 From: Yoshihiro Ohba Subject: Re: Status of draft-yan-radext-port-type-01.txt To: "Nelson, David" Cc: Yoshihiro Ohba , radiusext@ops.ietf.org Message-id: <20061205160113.GF1824@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Thank you for the information. It would be very much appreciated if NAS-Port-Type for 802.16 is quickly assigned in the RADEXT chairs' recommended way, because IEEE 802.21 specification has some dependency on NAS-Port-Type values. Best Regards, Yoshihiro Ohba On Tue, Dec 05, 2006 at 10:36:21AM -0500, Nelson, David wrote: > Yoshihiro Ohba writes... > > > What is the status of this I-D? > > > > I think I-D is important because it defines NAS-Port-Type > > for several new wireless technologies including 802.16. > > I'm still working on the minutes of the RADEXT WG session at IETF-67, > however, the discussion of this document in the meeting can be > summarized as follows: > > -- The proposal to register new code points for the NAS-Port-Type > attribute in the RADIUS IANA registry is fine. > > -- This attribute does not require a published specification. We can > save the cost of publishing an RFC. > > -- The recommendation of the WG Chairs was to submit a request to IANA > for the assignment, and the RADEXT Chairs will work with IANA to see > that any necessary expert review is provided. > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 15:38:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Status of draft-yan-radext-port-type-01.txt Date: Tue, 5 Dec 2006 10:36:21 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49EC@MABOSEVS2.ets.enterasys.com> Thread-Topic: Status of draft-yan-radext-port-type-01.txt Thread-Index: AccYgH8ZZ/xmWJhJTPeaDlCgWU0hmgAAfBMg From: "Nelson, David" To: "Yoshihiro Ohba" , Yoshihiro Ohba writes... > What is the status of this I-D? >=20 > I think I-D is important because it defines NAS-Port-Type > for several new wireless technologies including 802.16. I'm still working on the minutes of the RADEXT WG session at IETF-67, however, the discussion of this document in the meeting can be summarized as follows: -- The proposal to register new code points for the NAS-Port-Type attribute in the RADIUS IANA registry is fine. -- This attribute does not require a published specification. We can save the cost of publishing an RFC. -- The recommendation of the WG Chairs was to submit a request to IANA for the assignment, and the RADEXT Chairs will work with IANA to see that any necessary expert review is provided. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 05 Dec 2006 15:17:05 +0000 Date: Tue, 05 Dec 2006 10:15:49 -0500 From: Yoshihiro Ohba Subject: Status of draft-yan-radext-port-type-01.txt To: radiusext@ops.ietf.org Message-id: <20061205151549.GC1824@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) What is the status of this I-D? I think I-D is important because it defines NAS-Port-Type for several new wireless technologies including 802.16. Regards, Yoshihiro Ohba -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Dec 2006 23:36:37 +0000 Message-ID: From: "Bernard Aboba" To: mauricio.sanchez@hp.com, radiusext@ops.ietf.org Bcc: Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs Date: Mon, 04 Dec 2006 15:35:13 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >What happens in the instance that a diameter->radius gateway can't >translate a packet? RFC 4005 Section 9 describes two situations in which translation may not be possible: " Although the Diameter protocol is in many ways a superset of RADIUS functions, a number of RADIUS representations are not allowed, so that new capabilities can be used without the old problems. There are primarily two different situations that must be handled: one in which a RADIUS request is received that must be forwarded as a Diameter request, and another in which the inverse is true. RADIUS does not support a peer-to-peer architecture, and server-initiated operations are generally not supported. See [RADDynAuth] for an alternative. Some RADIUS attributes are encrypted. RADIUS security and encryption techniques are applied on a hop-per-hop basis. A Diameter agent will have to decrypt RADIUS attribute data entering the Diameter system, and if that information is forwarded, the agent MUST secure it by using Diameter specific techniques." >There must be some exception path, right? My reading of RFC 4005 is that other than these situations, that RADIUS packets are expected to be translatable to Diameter. RADIUS does not have a mechanism to enable a NAS to indicate an error in response to an Access-Accept, so that if RADIUS packets are not translatable it would difficult to communicate this to a RADIUS server. If the NAS does a silent discard, then no Accounting-Request is generated. That's the only indication that a RADIUS server will have that the attributes sent were unacceptable. >If so, why couldn't we leave in the MUST NOT for mixture of filter-id and >nas-filter-rule >attributes and have the gateway generate an error to avoid wedging both >attributes into a radius >packet? On the Diameter side, behavior will depend on whether the gateway silently discards the RADIUS packet (in which case no error would be sent to the Diameter NAS) or whether it acts as though an Access-Reject were received (in which case the Diameter equivalent of the Reject would be sent to the NAS). BTW, here is what RFC 2119, Section 6 says about MUST and MUST NOT: " Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." In this particular case, there does not appear to be an interoperability issue (in fact, the MUST NOT might create an issue), so we are left with assessing the potential for causing harm. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Dec 2006 20:51:19 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-filter-06.txt Message-Id: Date: Mon, 04 Dec 2006 15:50:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Filter Rule Attribute Author(s) : P. Congdon, et al. Filename : draft-ietf-radext-filter-06.txt Pages : 10 Date : 2006-12-4 While RFC 2865 defines the Filter-Id attribute, this requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-filter-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-filter-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-4124749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-filter-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-filter-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-4124749.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 02 Dec 2006 01:26:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs Date: Fri, 1 Dec 2006 19:24:45 -0600 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0226_01C7156D.984C8A40" Message-ID: <2F2D38A4B8346F48A683750A46BAB211AAE4A0@G3W0072.americas.hpqcorp.net> Thread-Topic: Inclusion of Filter-Id and NAS-Filter-Rule AVPs Thread-Index: AccSVvr24gDHSIJyQlyfJVgpoK2K0wABw75AANRzaCA= From: "Sanchez, Mauricio (ProCurve)" To: This is a multi-part message in MIME format. ------=_NextPart_000_0226_01C7156D.984C8A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What happens in the instance that a diameter->radius gateway can't translate a packet? There must be some exception path, right? If so, why couldn't we leave in the MUST NOT for mixture of filter-id and nas-filter-rule attributes and have the gateway generate an error to avoid wedging both attributes into a radius packet? It just feels wrong to have to carry forward diameter sloppiness. MS > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, November 27, 2006 11:59 AM > To: radiusext@ops.ietf.org > Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs > > Bernard Aboba writes... > > > Perhaps the best solution is simply to say this in the document. > > That may, in fact, be the best we can do. > > > For example: > > > > "The NAS-Filter-Rule attribute is not intended to be used > concurrently > > with any other filter rule attribute, including Filter-Id (11) and > > NAS-Traffic-Rule [Traffic] attributes. > > NAS-Filter-Rule and NAS-Traffic-Rule attributes MUST NOT > appear in the > > same RADIUS packet. If a NAS-Traffic-Rule attribute is > present, a NAS > > implementing this specification MUST silently discard > NAS-Filter-Rule > > attributes, if present. Filter-Id and NAS-Filter-Rule attributes > > SHOULD NOT appear in the same RADIUS packet. > > > > Given the absence in [RFC4005] of well-defined precedence rules for > > combining Filter-Id and NAS-Filter-Rule attributes into a > single rule > > set, the behavior of NASes receiving both attributes is > undefined, and > > therefore a RADIUS server implementation cannot assume a consistent > > behavior." > > This seems OK to me. > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > ------=_NextPart_000_0226_01C7156D.984C8A40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MTIwMjAxMjQ0NVowIwYJ KoZIhvcNAQkEMRYEFAaNW91hzsL/CSabZ5jV1yk/0xcMMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgNQ5I/2mbHEp15+K0ZJPaRCtFwuC/tLSj+gxu3DG3/h5mkhTbWFil0BV3azYFqXm JzcllRd2whg5b+DBGt5EeardGbtwE760hWBvj91btsfU7/1eOACt9Hzdo2l0FW6+koOpo4cvsaLB gAjGbGzOQr/sVr5/MEjT/uWOwrUS1uC1AAAAAAAA ------=_NextPart_000_0226_01C7156D.984C8A40-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: