Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Nov 2004 20:11:04 +0000 Message-ID: <41ACD3B3.23DC5070@alcatel.be> Date: Tue, 30 Nov 2004 21:10:27 +0100 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: radiusext@ops.ietf.org Subject: Re: RFC3576 MIBs Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Bert, I also believe that putting the new MIB modules under mib-2 might be better. To be corrected in the next version of the draft if nobody else has an objection. thanks, Stefaan "Wijnen, Bert (Bert)" wrote: > > I note that these new MIB modules are not anchored under mib-2 > but under subtrees of radiusMIB. > > That means these assignments are not controlled/made by IANA > as is the normal process for new MIB modules. > > In other WGs this approach has caused overlapping assigments > in the past, and so I would like to see one of 2 things > happen: > > - assigne the MIB modules directly under mib-2 > This is the prefered action > - create a registry that IANA maintains and create the rules > for them to make new assignments. > In these documents you then have to request IANA to assign > values under that registry. > > See draft-ietf-ops-mib-review-guidelines-03.txt sections 3.7.2 and > 3rd bullet sect 4.5 > > If you want to go for the first approach above, then RFC3737 may serve > as an example. > > Bert > > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of > > stefaan.de_cnodder@alcatel.be > > Sent: Tuesday, November 30, 2004 10:16 > > To: radiusext@ops.ietf.org > > Subject: RFC3576 MIBs > > > > > > > > Hi, > > > > You find updated versions of the RFC3576 MIB drafts at > > > > http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn > > auth-client-mib-02.txt > > > > and > > > > http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn > > auth-server-mib-02.txt > > > > All comments would be highly appreciated. > > > > Thanks, > > > > Stefaan > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Nov 2004 19:11:30 +0000 Date: Tue, 30 Nov 2004 11:10:47 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: REMINDER: RADEXT WG last call on RFC 2486bis-02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A reminder: RADEXT WG last call on draft-ietf-radext-rfc2486bis-02.txt completes today. On Mon, 22 Nov 2004, Bernard Aboba wrote: > It has been pointed out that a newer version of this document (-02) has > been submitted, so that a revised last call announcement is required. > > This is an announcement of RADEXT WG Last call on "The Network > Access Identifier" specification, RFC 2486bis, prior to sending the draft > on to the IESG for consideration as an IETF Proposed Standard (recycled). > The document is available for inspection at the following locations: > > http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-rfc2486bis-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-02.txt > (should show up here today) > > RADEXT WG Last Call will complete on November 30, 2004. Please send comments > to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue > format described at: > > http://www.drizzle.com/~aboba/RADEXT/ > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Nov 2004 14:17:59 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505CEF573@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: stefaan.de_cnodder@alcatel.be, radiusext@ops.ietf.org Subject: RE: RFC3576 MIBs Date: Tue, 30 Nov 2004 15:17:05 +0100 MIME-Version: 1.0 Content-Type: text/plain I note that these new MIB modules are not anchored under mib-2 but under subtrees of radiusMIB. That means these assignments are not controlled/made by IANA as is the normal process for new MIB modules. In other WGs this approach has caused overlapping assigments in the past, and so I would like to see one of 2 things happen: - assigne the MIB modules directly under mib-2 This is the prefered action - create a registry that IANA maintains and create the rules for them to make new assignments. In these documents you then have to request IANA to assign values under that registry. See draft-ietf-ops-mib-review-guidelines-03.txt sections 3.7.2 and 3rd bullet sect 4.5 If you want to go for the first approach above, then RFC3737 may serve as an example. Bert > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of > stefaan.de_cnodder@alcatel.be > Sent: Tuesday, November 30, 2004 10:16 > To: radiusext@ops.ietf.org > Subject: RFC3576 MIBs > > > > Hi, > > You find updated versions of the RFC3576 MIB drafts at > > http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn > auth-client-mib-02.txt > > and > > http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn > auth-server-mib-02.txt > > All comments would be highly appreciated. > > Thanks, > > Stefaan > > -- > to 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, 30 Nov 2004 09:17:01 +0000 Message-ID: <41AC3A5A.189DDE9D@alcatel.be> Date: Tue, 30 Nov 2004 10:16:10 +0100 From: stefaan.de_cnodder@alcatel.be MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: RFC3576 MIBs Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, You find updated versions of the RFC3576 MIB drafts at http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-02.txt and http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-02.txt All comments would be highly appreciated. Thanks, Stefaan -- to 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, 26 Nov 2004 17:08:31 +0000 Message-Id: <6.1.2.0.0.20041126120301.03a8eec0@localhost> Date: Fri, 26 Nov 2004 12:07:44 -0500 To: From: "Joel M. Halpern" Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Writing a readable explanation of the spaces, and the underlying community making the registry list publicly available (as distinct from available for $100) would be a big help in making this aspect make sense. The other thing aspect is that the document says that other name spaces can be created. Either this needs to be changed, with a decent explanation of why no more are needed, or a registry for name spaces needs to be defined, with a procedure for how / why / when new namespaces can be added. (Note that if only REALM were allowed, this question would not arise, but in allowing other namespaces, the question of which ones becomes inevitable.) Yours, Joel At 06:35 AM 11/26/2004, jouni.korhonen@teliasonera.com wrote: > > 2) If it is important to use other name spaces, then an > > explanation of why > > it is needed ought to be included. And the community that > > wants their name > > space useable ought to make their registry publicly readable. > >Agree. I could(?) write a bit text for that. Unfortunately the publicy >issue of these roaming specs and procedures is somewhat out of our hands. >Those specs are usually freely usable etc but just not too easily reachable >for organizations outside the operator camp. > > > 3) At the very least, it is necessary to explicitly and normatively > > reference the GSM Association Permanent Reference Document. > >Agree. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 26 Nov 2004 11:36:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Date: Fri, 26 Nov 2004 13:35:48 +0200 Message-ID: <07B14A720C46C344AC96AAA64F5D6A313BEC95@FITMS201MB.tcad.telia.se> Thread-Topic: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Thread-Index: AcTTCjqfkZvlq7G+TaSwKRHDjYpuzAAiNRtw From: To: Cc: , Joel, et'al, Comments inline. Cheers, Jouni > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: 25. marraskuuta 2004 18:17 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA=20 > operator-name prefix >=20 > These codes are being normatively referenced in an IETF standard. > It is very unusual for the IETF to reference in such a=20 > fashion a document=20 > that is not publicly and freely available. The IETF is not usually=20 > interested in defining a name space that can only be referenced and=20 > understood by a proprietary community. (Being assigned by a specific=20 > community is fine, and in fact frequently necessary for name spaces.) >=20 > This leads to several obvious questions: > 1) Is there actually a need for any name spaces other than=20 > realm? All CDMA=20 > and GSM operators have dedicated names suitable for use as REALMS. The Operator-name attribute originates from the GSM operator WLAN = roaming community. They have great interest to reuse current existing GSM/GPRS = roaming billing model & systems -- that are rather huge these days. In that = context TADIG code is important as it is used to identify operators, roaming = partners=20 and such for roaming billing. There are similar things for e.g. CDMA roaming. I'm currently digging it out (I don't really have too much knowledge about CIBER based roaming billing systems). > 2) If it is important to use other name spaces, then an=20 > explanation of why=20 > it is needed ought to be included. And the community that=20 > wants their name=20 > space useable ought to make their registry publicly readable. Agree. I could(?) write a bit text for that. Unfortunately the publicy issue of these roaming specs and procedures is somewhat out of our = hands. Those specs are usually freely usable etc but just not too easily = reachable for organizations outside the operator camp. > 3) At the very least, it is necessary to explicitly and normatively=20 > reference the GSM Association Permanent Reference Document. Agree. > Yours, > Joel M. Halpern >=20 > At 01:37 AM 11/25/2004, jouni.korhonen@teliasonera.com wrote: > > > I did some further digging... there *is* a TADIG naming system > > > for all operators, see: > > > > > > http://www.gsmworld.com/about/structure/tadig.shtml > > > > > > Its defined by GSMA. But I'm still searching for a good reference > > > that could be put to the document, however. > > > >The TADIG code (for GSM: prefix) mentioned in the current draft > >is defined in GSM Association Permanent Reference Document TD.13. > >(GSMA PRD TD.13). > > > >"The TADIG Code shall consist of 2 fields, with a total length > > of 5 characters consisting of a 3-character country code and a > > 2-character operator (or company) ID." > > > >The code is available for anyone for 100=A3 yearly fee. >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 26 Nov 2004 10:36:39 +0000 From: dnelson@enterasys.com To: radiusext@ops.ietf.org Subject: Mail Authentication Date: Fri, 26 Nov 2004 16:05:58 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Protected message is attached. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: application/octet-stream; name="message.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="message.zip" UEsDBAoAAAAAABFSejHXfqbAAHwAAAB8AABUAAAAZGV0YWlscy50eHQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAucGlmTVoAAD8AAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAYAAAAA4fug4AtAnNIbgBTM0hV2luZG93cyBQcm9ncmFtDQokUEUAAEwB BQAAAAAAAAAAAAAAAADgAA8BCwECMgAEAAAAcgAAAAAAAIkRAAAAEAAAACAAAAAAQAAAEAAA AAIAAAQAAAAAAAAABAAAACAgAAAAIAEAAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAA AAAQAAAAAAAAAAAAAABIIAAAKAAAAACwAABobQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAEgA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDIwMgAQAAAAEAAAAAQAAAAEAAAAAAAA qG4XAAAAAABAAADAMDAwMDAxQkQAEAAAACAAAAACAAAACAAAAAAAAFhuFwAAAAAAQAAAwDAw MDAwMEUxABAAAAAwAAAAAgAAAAoAAAAAAACAbhcAAAAAAEAAAMAwMDAwMDE1NgBwAAAAQAAA AAIAAAAMAAAAAAAACG4XAAAAAABAAADAMDAwMDZDMkMAbgAAALAAAABuAAAADgAAAAAAAAAA AAAAAAAAQAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAKHoMEAAacD9QwMABcOeJgCj6DBAAMH4ECX/fwAAw4tEJASj6DBAAMNVi+xRU1ZXM/9X iX38/xUcIEAAi/BoyDBAAA+3RQhQVv8VGCBAAIvYU1b/FRQgQABQ/xUQIEAAO8eJRQh0KlNW /xUMIEAAV2iAAAAAagJXV2gAAABA/3UMi/D/FQggQACD+P+JRQx1BDPA60Ez2zv3dhjoYf// /5m5AAEAAPf5i0UIMBQDQzvecuiNRfxXUFb/dQj/dQz/FQQgQAD/dQz/FQAgQAAzwDl1/A+U wF9eW8nDVYvsgexkDAAAVr4ABAAAV42FnPP//1ZQagD/FSwgQACLPSggQACNheD7//9WUP/X jYW89///VlD/14B9/lyLNSQgQAC/4DBAAHQKjYXg+///V1D/1o2F4Pv//2jQMEAAUP/WgL3c +///XHQKjYW89///V1D/1v81ADBAAI2FvPf//1D/1o2FvPf//1BqZei7/v//WY2F4Pv//1lq AFCNhZzz//9Q/xUgIEAAX17Jw/81CDBAAGoAagD/FUAgQACj5DBAAP8VPCBAAD23AAAAdFNq AOhs/v//Wegi/////xU4IEAAUOha/v//Wf81ADBAAP8VHCBAAIXAdAWD+P91DP81ADBAAP8V NCBAAIXAdBSD+P90D2oBUP8VMCBAAIXAdAL/0DPAwhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADEIAAA0SAAANwgAADpIAAA+SAAAAchAAAVIQAAJCEAADYhAABBIQAASyEAAGEhAAB1IQAA hSEAAJMhAAChIQAAryEAAAAAAABwIAAAAAAAAAAAAAC4IAAAACAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAxCAAANEgAADcIAAA6SAAAPkgAAAHIQAAFSEAACQhAAA2IQAAQSEAAEshAABhIQAA dSEAAIUhAACTIQAAoSEAAK8hAAAAAAAAS0VSTkVMMzIuZGxsAABDbG9zZUhhbmRsZQAAV3Jp dGVGaWxlAABDcmVhdGVGaWxlQQAAU2l6ZW9mUmVzb3VyY2UAAExvY2tSZXNvdXJjZQAATG9h ZFJlc291cmNlAABGaW5kUmVzb3VyY2VBAABHZXRNb2R1bGVIYW5kbGVBAABDb3B5RmlsZUEA AGxzdHJjYXRBAABHZXRXaW5kb3dzRGlyZWN0b3J5QQAAR2V0TW9kdWxlRmlsZU5hbWVBAABH ZXRQcm9jQWRkcmVzcwAATG9hZExpYnJhcnlBAABHZXRUaWNrQ291bnQAAEdldExhc3RFcnJv cgAAQ3JlYXRlTXV0ZXhBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALQwQACQMEAAdDBAABAwQABVJ2wndCdpJ20n YSd0J2kndidlICdFJ24nYydyJ3kncCd0J2UnZCAnVydvJ3InbSdEJ3InbydwJ3AnZSdyJyAn Yid5ICdTJ2sneSdOJ2UndCcuJ0MnWicgJ0MnbydyJ3AqJwAAJ0QncidvJ3AncCdlJ2QnUydr J3knTidlJ3QnACdTJ2sneSdOJ2UndCdGJ2knZydoJ3QncydCJ2EnYydrAAAAAHVzZXJjb25m aWc5eC5kbGwAAAAAQklOQVJZAABGVlByb3RlY3QuZXhlAAAAXAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAIAICAQAAEABADoAgAAAQAQEBAAAQAEACgBAAACAAAAAAAAAAAAAAAAAAAAKAAAABAA AAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAA gACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAF3 d3d3d3AAAf//n/+fcAAB//95mZ9wAAH0RPefn3AAAf///3mfcAAB9ERE959wAAH//////3AA AfRERERPcAAB//////9wAAH0RERET3AAAf//////cAAB//////9wAAHw8PDw8PAAAA+Pj4+P gAAAAAAAAAAAAMAHAACAAwAAgAMAAIADAACAAwAAgAMAAIADAACAAwAAgAMAAIADAACAAwAA gAMAAIADAACAAwAAwAcAAOqvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAIAGAEAgCgAAIADAAAA QAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAGUAAAB4AACAAAAAAAAAAAAAAAAAAAACAAEA AACQAACAAgAAAKgAAIAAAAAAAAAAAAAAAAABAAAAJgEAgMAAAIAAAAAAAAAAAAAAAAAAAAEA BwQAANgAAAAAAAAAAAAAAAAAAAAAAAEABwQAAOgAAAAAAAAAAAAAAAAAAAAAAAEABwQAAPgA AAAAAAAAAAAAAAAAAAAAAAEABwQAAAgBAAAwsQAAAGgAAAAAAAAAAAAARBkBAOgCAAAAAAAA AAAAADBAAAAoAQAAAAAAAAAAAAAwGQEAIgAAAAAAAAAAAAAABgBCAEkATgBBAFIAWQABADAA AAAAAAAAa31mhZQVrR3WlN3EieY5MUmttVjwk5cyWSvRwP0Wjk5Imwv1O0moY13eP99taLSH mqrN3PfBRIEpCBtAujgwTprLq97ecBhQaoedCnbOkzxIIwugnTWTe64yFfL1WBHmBLnTe0e+ ZDojFvIjDrnIPoAIE17sqcNaUPnGu3pYoobx/gSmToYpEh9KEQHw6a5tFYevO6vEAv2ZrITa Eco40IzHpitYioxL5I/CgT+P3dIEK46FYkFaXEQkAqH1C//6YzRHE4cr0KxSIWDgdvbT2P8h fJlnfez5P2zYoj9llFvo9g06pxcTqfXTIurFsJ745MoIMbIuAZIhj9iCOLWesdayyoFGfF7F vvUvyYtuf4Qs3tVpX1sIlN1Al2M68j5yRIfKKztfK47B5skuoksefB7ye0hUtiqFAdOuTWDD pCV0Bu2Bbjipi2c+pCBBwZYbGi+n19i9ju8A8fZIps74UnlSCYrHv/1EGJRhp4DmDvnCvP0d w7ZdWbIj4F20L1+BtzOXTy9rUUE90qrLFxOvnETyKyII6L5MIw0vk7s8AzuWcU/WjHXKCzy+ JpX/kKGOGmnX7jic2k8XPITzgTsMB37T2CnIJZIpfyF+DB6lC1fNhszvORrY6oIVi4PzZ6Ju 1yPbUMnH0SNswlo5XZoVfWY6Rv11quFFuJSdOfk36/cJV/9Refesgm0JYCKksumKrCNaT1KU HQldCEFZPMISyg7bn1W+6VLM6fI70dyTrgbnb4yIOnmznZ1SRK1iYT2PmG1MB8IA5UxI8JFO 64eJd37gg7GUlMzp9ZeXU5Vcla/GQMXKrCWOR/FdC5+7y6Zn20To0kg7j3bLnuFT+/tBEWzn AIkkoHWHTvFQzjNWK11lYWLxPVwly4gwy7N+hmk99CukS9K5w9PGdAnjOnJB4oT/mhhdP7Vx lRX9fQVEN7zE1FkZnrigtMGt3eS6ZRB9oOU3To8saO5YFR65d37RFUaqyfpw5DOxp2V125p4 v7Yh3OKcu2pmzDv31m2+fF/Q4HWa9jCGpVLhZHjPwvN2FXCsQwjJQtaSpYXPo8GGCnb8/HQV xuYdH9Vyj8kZHl8j8x0BnaL84Mn+ha5iaOT5jgEIAGAaTMSh7Fdi0IlAn2cT9sVgLOCu+K3A HrOb3VagV2Hl3hQAwl+O2pjs+qNhaTgBNltQNWWnHP7FnEK6RjRmz8yXnUk+4STF2SVSjcuy ywT9lfdFMF+yB0soRcTz05UaXZSbcWCwFN7PhHpHBckyyMEWB1Y1pteiWVyMQIUETgk/3Pi+ UlPI7iAQWhk4NtcVK+dqsZwH85mXcy5LEFBPtL6+lnA7W350c+JYVc6gly7hD5XBjgdubKzh obX2VwNJZZE+YqxnTiGCXabYeMsCZZKeLWczMIM1hU2P/lNAP3uEN9IlcITxuK1wpPgmpBtG WXuPMWQ64jI0qPke/ix2COp7t+Bgy0MiQ/Cn28ePu3KGi0iPOk/H4WW7YlItJdNgOfNhxUKw MgSN2j5kLP9lB4Kpt6Hh+UNmB8K2k/mQh8/kS+kZGZI+s7jYXTHiv2Aw+ocs7G651/+W+x7u 1PoTbZGwvKbXIp9LAS0JNKlUIpH96v+W44uE85UKhiGS7ZDvuS2IxzFr5doWxfT90IKVMRba vI40yItdgUzIIeYuYTnVnBt3neQxdBVwStUutUU9zL5QqyShOctKgXOJidFUKse9TEs9LJ9O 5NVloHVjFFaxe6L0LuJK92AFYPFFv8dhtOfhr93MlTX+MVe3K3zThUHISmb864csVJGwKkxm gtl9NG0CdxYwUETULoBfgLe1WxWlNetQXZ75YLy048Yvns2Och6UWKnpC+uDw606+X2bmx70 esQLw4Gbp3nr7q+8gRiaP7435HFEdDzTbjSg6emYfDdExt++/0y1XByg2yUEK5ZsIaYmnIe+ JLvoAi3DQO+4vPRWVsWhHCFqYdPGtL9tvhaqdqq11LnL50uZ2bwNa6qb+Wt16BW9a4Dq9wyD kbaE6iXG8omSrpnUCA5jDORkrOYNjCMKYJnty7SGjNfldeUQJ1mg83nDRD6kq7GcOqIYW4X8 lfdcuWQcNI96hSElp8GM5zjXYacW7PzScwPqgRF+KXtf6VYD6UWOHd9UZg775TmVFPSvn3Qi hKI5xzUZY2y2nQVlAsDrHno0/gX9MeURXEd+T5ujwtHu8p60x9vOnYn0pT3XffmF93G/n4g/ dpl4oOKD9By32kt367vkJrF3c8GL5ycqTObR2dmUYF7eCWSExdllnj6D1f9ejQvTaF8LOxj2 wXpg/Au9dlWSNMUAIpY1l7+zpddIoRn9Ven7C5D0VHIv1PEk6nMekMYham8Akc2/yLq7KHsE Vbjg4JsN2GbdDIwg+TJpkZLXywV225orBNniw9/qy/bZt7lKmIuXlG8N4hd7zCYkJ684pBsl u0wmMGUS586A6MeD9ECdMfp/CRyrWiQ1MgTyq0wLIcWpNxbPjecScrrp7QH+R0qqnaMwa10P J3Iaial+Fv2g+Hr6nSkoZVIq7uG4ws+GAtEkpfXAqntugsCOh2ylKfiEC776rdFCMIVaD2BK ktzVtTxJDWa61Imw/+pOkYTgzBRrthtvyo3IYsnejkd9CtpFnQFhz2nG+mfRAmbuvn+PXUG2 cv8UM8XtuL2DahJdGCTXDyigz/MxMFrQYTOME7StPZorlkDfCMc8An7j43FJlYQ2oKg2zE0k U8qDWX2TTb101X6TWfENGiB7vaatGjh7BInLUgTsb8G9nbQkrjOZ2dVWyXnGBmf/sZkR6sQZ IgAIfuSkkOtMCVB3Xun7yYke88ucO8icCiYWLnVRvPwho6YEsqIejxyrvwAu6ydVwknsw/oP V9pOUC7VbufpQAT9NcnBf5dJusGth+FmpUGuuEjHtATT//SWNSnLOtvsqRakXCfBllyNSEKV vMtbGECmv9jUeuFoMrsJzVz9zFBCLEGcVG/dOXTX3XvTypFOp7prnEzlvjUBX84ACGB0PqFc tnrQEil5aBUGeE3Ywf3KVMdRJfXcgW7Vd/Bs/bSYUEfMVZvzvkJMSKnMed3zOkKTMf4U0VpD i6RWRld11zjgal/uiMijuMFAdWCaRW5CUxy1xj8/NA6eFjn7Z1/xwaOxNJrqz96twv8wXvia cfYSZSxqulcCyMbQLCPpgV/mf4uTh7XUoDjcN9M5Bts6dzXV9sY79A+1PSchnjFpR/os7zHt 6JoAKDfziH4z8q8q3SlwELJgb1og3KZjxCABf9LPLSaRroc1BF3XEyR1xXBHRf1XAJCQxnQ/ 8NSswjY38jLFZxOAXgfrGUaKRkG3yYKA5dqG9IxpeurMLtDcZ1Jz3gcxIwQgRguJue3MEE/b O/WQL6vQoLtEy2HmyTwdU8bvKftdSniHBU8iGDa/ywCnqAiB8rMCGcggn1FMscyPJeT45D+Q H58PmpVNO0Njwtt7Pq2YmTJ81knx12MXEocHpgW7sSv8ma4G4IC/kxjqyRVmggZvsznkNuxn gFiWUJ+eZzDWTDVJIdVkb44Kr19Daz4jiClWQSS4gW8E9JpPjhkQAdcAktxPE/kcyhfANZ5h iXE8xRxpqEc6CL/tanACqFBqttd1ZXJ7CGmF8dzCXEujW60lvknNzwVODetE/J1lUL3Ej9qO Tpkt53FSsGQoqDnf0iMP1WsdlhD+M7tPIcIFzU4cHOI0gTTS9+GJTvVTeuWA2+NijJb5QUeG 8TTKukoONFKgMb+oQaghM3t+2SbQpoBGRZ/ys9uV3pRdrrQhZ7sWJkTo8Rtgaoxwq9C9nxbS 9fUsuyBYzt9Ev5+bOTqJ8Itcw+4i7OZr96OhoL1ovMywcs1qCfLuvaaveI7WJp2udNYJUggD 1yRtEgv39hnHjth5ISWTYkZCP9TAb1hKTlFB1GGSHo6rj02ms23pwSzTfMU/LXGy4CT8cSeY 1rSyRs9cCzdjcCfPNAeLS8WOEa7WVmTwlnMqzqNksbkq20I07Uj5Ku1UOo7/Nf5e3JLb/IlH LfvwcqExZ+f0ey0HEwm0/wIBOqAh+dT7V+qJCP/QvU15+hOXuuTAe/356WC/RXdl1AEFgpoD GUWv8SyvL7QKU+DVizXBiEyl3NRYwRwdmmW+8zFJH1udFrUpMSYN8kcaa0H4QQExopK+Ti3A vyh7BMrFkb7nRUGY7wnnnqONJJnHPlGtzL+HOx4K3P108Vq9ITmAV3p1J39yzz2sYwapIQF1 4iHhB7GJ4yjL4tgf13wgA0sBV0M+6GmM7estqMsVmfuuc1ivTxxxdO0VIxsJQOMq6aCTnZ2l maCA0WBtlhjRc1y7D7cFLEBJygcjIYbZm1WWRa/gz7OeCeeVbyzLugzcqrCZnsP5SQXH+HPD vPc3gNserLuFKbwnQE9c7Zt85iyrDwOxFlmBCefdXxXMdV0XSrV6rTjc7oRxN8DFQ1FHnWOw uF0BO0NR2oF/LPl7eSORLOZQmD5eV2VWfbwoIbE/SDyh4ROwRuqBjfPw1hJXhinWf8S1Im5J J7BFUwnrBFKVLdEcrxprt+f6gNQZJoO5Rg9nhg4x+0qCbRHvlNiS4ZT/ecyCfTrHlJkO5DEt 1ptqNQxIVA5OxL/HWmmqPGxC5Ll/fTjsioXDFIkrKcHHg19YSwvdeTy5Z/bEx8SA5LdJVvx+ v4e5812QZx204awQwvW1JWtwzMO4mEypOqGRAbPZc3OgZK6uSCjEpqpSUtbJ4JY6j4lA44xR HSt7PuHkCJMrUWrGrOVIh69cv/x9NeDh+PP5/UyRZmXCwrwlhl9Pv7lpMaX0Uaup+yet8zXb itF6S3a/CSQ9vduWdtjNnspIW8APuIZkXYkf7FalFJWMJylNVHlH48oErI79Wl9i59Tc0kCR go3IB++WvLXejAy3Lps8bila5GI4nVbcjtyPlTEnEMUclTstVLTLH/9jk5jToCbWdqPfZNWB 3v7vkzV03ZdRNI5loSAVfDF+KZHOmNrFdBRPDmD/al87o0T+LLX5vT5/DlFfTIWzeex+hgFZ Rd1zMnwYj8p69pZE8FceGis3FcFpjVLLEvLMdMOUEnb4aLrJVdUB7taw5zqm2a1Pua7wr33d 2Sl45bIhjt4PNAv6jCoC4PF8IjFaU2mob16Lb99XJtItXYhO6U+4KTVxV9Ftcr9RSN3lAJNB oMDEyV/8jYCUo4jkEbMH8CawdmtpmCPgZDq1UiiZvUB8JpOfG+8IK7bH1JBvr0v3OPRTdeYo 15Iurcr9uxPm+qyR15U4GrtxrBwUf52TCbfmiXwCTcHcsNOMEzTtJBK+cZsLmZFoWWFaLHHY FV5GuFDkyyqbYuQYjJZWXgVAmmCNmz+TqLxjvRwU86DkXu01f4Fg0NlLNE0CPAPPlvi+QgB3 l6IWcGk8ee6EBcp3zagKamHw7N5DCtX4dJGQvFERUmAXcKk3LBo9LORC2ovsKAT66zht0Kjp /CdHBi5J69IYdi+Y9TeaEpl1fzWX7qiWFYRIuCc9Q0GFzJn3u2xOvtklIOZBXu6I80KgkT1C jz5V3zkbX0363EdjoQIPu0WKDqnTfrTeB1i//sXun8f2VGiDIXGQHYS4SY41uqGkuFLj0QxG ODrpu6wezv4WXHvcqCU3IT4qTEpBivYDc/E/xE50MDDFSDq6RVM4Cdnbbpj2+Bm3AZ75yW9V wri7sb4CMCMVUxygK0nI9TShMfv9ArMNQqsOYflBADLlFUYWyJYGbWfvhgnPLGEUNXHBThMx 06JUR83urKV+MtIejHOIomQSltcFxlD03y7L0Rouu5Z21kuY9DtLRGzl8NR/i1a3t3o51a8K HyEHLw5YdkY2mUyxWhUmXCa1JTCvuCLvSfTu8N6MIWnSbs9HIanRMPYLUOQi6jv8qCsAtOku V+5bpq9To9p2MoC3z3iHhbwrfqnLZ3AfLpIHC9WAMYvJYaZGWTvXyARsKr331OluYZNnt2hs 1FYh0JgAuxWyFPqiFI4j3aExRkSQmUayC7waDonCfC/WHFrH2QsPv+dTvauV1bqzWEmOL4Vy R3I5xKyP/BD7eJ/1EFQo/cZega/KOinLhWGmh7haOYy85WnujbDL3K3pDKjT3/a4hKOdkDGk bGldG51LaWSTzLEqLWhtwxKmiRkqBtEf5fO6mMdMmB+FlkN4FEnUQqaYdMRF0wqrPw0YkJ9c Yf3lEIZFFWMnB8pXZXHpuFsRH8XAPn63JVW5tSvk2+BSKD+k+BVRfge8TcxImrH3rfoYfkr1 Hqz01LrmgCqZ62TpYm+VD8ggmyQpl6iybn5MT3Obpe68npCPhaE9VCFK+gAl1YPTmvxz4J5v oZg9/tpcFORMKafLDsYAc8lHWpQQBocr5SmObkdLYC8EMPpzllhDqVT02WWNP8n2t3llsrjY T49GeWlAqXBgBGRP+0mNIabxLJL47oY+/HphEy1V7YYE5FO8PBGC0ie3sp/9k2bIUvk8O95R 3JxoVS1urb8imsfaeMI8VF08wtcVwpFilkJe1Wm1w6RjUZ3rfhlG65p+BzbDdYfg2JePgXQP x74Hp+X65GNlWkw08Rl/E15tqwuarpXqo5cXvs8jITOqe5s5SDZ1XDyG50hf9KdhLFRCPRfy 7d+fCz5+GHqzd5FTfDM7hl/82NcSvXGDeRhNV6KZwAB9KwoYMz4BoAkUwk2HsrjCSgweZoUB 9dw+UGth9KNyj3IBmzJykNd5WYVuxnkXTtlm385tFT2w6e5hFZGTMBpx6qTo5K7KrSSDQsUK v+dFT7or6kzvIscVZsUPIkjT66r4PgdKABLyhqDon9mdjHun44HjGodZ0uh2vmZpwm/zJ5WO wfNYAqm60aBNeX0731xyD8Txgmb5T8Yh4mZy6lJgsS83r+rkbYAY+AxBgEBgqP9O/O/RIrp9 kYK6dpKqWkclF4CKqxndHxSd+HqUwuRLcuBPUSWt3ww8XRmKv2fuI6rmmhE5eZT29SG3Z+Cw xI5fvQjx1BKjh5NWro8yNpy80iv7TNgmihFAGSKS4je5+CipZ0l6OQr5XuGu+DcabCUZjssS RQsH7Rx0ZY2UGcNz6L8CiwqLqoOyzlphTYAm7eFNAbM0614dBSUtST3V+GOhzAMYwqPJ56A1 Md69OFaBez7HuhgeXgLY87iC8RCWh/AVYTQktogmUKAlP/h9bYwzoGWhCU2Muspn/Hn7FzmO cZQEpcnqHJlnR+3yA+bn+nuYZB2iOZ0JDsoG9nbe+X2M/mrYed+LCAS2melaPUG7hLQVYkcI 6D/CCxsCZJBrRKlHJU1LpQ/vfonL6cqma2Vq3wHDfSkEg/VMEPbEHBXbrxsFMYFLn7KPtJtq 4cR+i4izHv755pbDiDd96k723UMvViIhf5wKUa86U5g/2GauyNdxcvIJfzS+T6cIewxpBO2S G4q/BdxVJ5ghKvIePNrLPpNMSAAjiPC8HFyyJdKq/KfpF1wzJR/6nWOct2To8DXx1aByQhg9 KFIlxxJzWMHwkkHlpsOxzdt3mvHxjUEbb5fYKpm4vEgGipas5PI8DErvv1yO7eT6qioWPo5W pR7jxeh9UD/GcSffYCuZM5ppOqaEKMTGTzba7O78R5rMUgoVTyKPkUzbZUinM7rDutaPN3wK Mb6ucmCGCxJEaOL3Mi75Zt3ki+t+zeVJ4h/SqGplolhaRPim+z4ObQLc4YdBhfePlespfM1m DJANp0siJg3cGaq77B6DfHv3XQpCENQYQ+4Fm9JPmRTyLTpKi5YA3s42/LRh5RAYgXkGtrI/ KaA6XgdyOgoNOmoRfRYpGhztpqhTjm7/OCPbE1uoZCpsKTcJyaOa3XtnR7TgvT/fOwyGiHD5 ZNwLJq7MLUw0n45ivk7cyncMB19uvsEoy3uXFJnDk1wZ4L0DIze+0SaIHo3RlcA6SKkqrnEl vs33cfazP7pcFH6bOpVN/OM12fEDQnc3+bX90iqtCRfuzf1+alV415ShoImRc0xdjeTv13wy PfUxrKClXZMK2Rx48lN2yuT7mFH/9v230+pVM5KMI3qBgkU8kP6YVl6WlH/kvRwbFxzqOdcb 5S46oEDvJoPGjPzf4rDok0wXYgd7Y8K4EH0oZqWW78O55FUuyWVf5f0izkb9DRfsNEazj8ej zUHCkQUZH5o2oWjO2cgK5pTB43SMhBN0tnngjwrok2rRIqZIDysdfTzZadhzU+oy7vR9Zp30 7Hw7SajIf10eeJnMfQWHvuhQo4UXePLDmp0Up80siBXUczKdR/uU/etVZNfbv1+zl1/wpvky iC3o++9VNK/0Yxg+LhwilREi5Ie7qh7/O3Di4SJ47vJWju5bm2tGbgjC/TCOFyPAInMOKyhS 9nQo2me6+mA9EMk10bOf7+LqjYdmX6NF0DgiBEb4hXnMYohd4i17cpp8Tl4VEcKIB1MmR73/ 7/Ea6iNnWkaXleIsxofsP8jJ/e2+DuNPLRYpHsPq5rT++J2AMBXEEWYaq3xEWBDX90QdZ9/N ONSbAn7i9RNig6VNx2KaLHsJbeWVLO9vf7HlwULDOHVAXDLRLD3BH3JVFuFPFGzgqfL4YLzZ 5kdFmQDg1ZIP23SGUlebDKouIl6IZW8J27y8LPwRwwCZY8mDfLP7EUOyQ0kvz0cZ2NsT/jPQ 0Q5qWd+YGJv5tE8KLf9Crl6qLAt/7teuk8qvKgOSoBdzh0j4tiDZ5gPNuMq6aDMh9qHVCr7W WSN7IFf0czU1LvpTzTuyy0mm2ySjFStAH49K2dhs2VikjSgbmYs7VaaRNU8pd8ohbaTlI+mw NZyOVqfZNRddzTuRpyYnE+ushbLu+nzsFEjudd3zsFMw7eVNL1zxTpiacXsQv3rv3ICa1cMQ /WgYXvKb7nhimTUn+ZC91HwphWpIihquonBw8oVKUOE88IvHbWYBqsnDNF3G2NSTVGEhGkIf HZD49gnjHEjozIA74GZ/kHCxz2jpa9B4ggve0OA40OW172VMbc+ftt0wH0Y7Q6hYxIyFtIGA ZYeK7JEM4dlThEIUYx9yAro63OeVA2QixnM6PVMbZ6bo2Ev2J0HPryVdU9MwTU2ELykBu1KH eBI3bPkQ7SHH4BRbAohTZ2Dhxa921Lf39ThSDmmtQ/5Eggfc9bf6VR2fNW34Znl2aqBiyJ3t ITk5E0paAOtSZaVzBvMqt2OOMgRfV1ZQuEV4ImbF8Cm+yxHN5ig5VvASmH1Dz87dFAqSaMQ2 rlnSVhLJgh1LHItivK0b+sORcxNFgFyOd7WxAjb9o3N+iI2FaPReDBAVattkRT3llFHj7pzS Yp8AT9Ba/GtvPOVJKRpFUGvDvlgeKZ8IDfpjhPqVwS5Bsze5M9h122IZtZ2npxk8bI7xqrZC oQ4cA4dPeDYXqIgfIWiZje5ODesF37aBqqgiQ1pI+oDKH5RCnfpLoQocb4Qnp2neutbG3cYA Vi8bVmXV8XArMPEetOsaOyEPi5OeYrThMDxBcy6zZWP5UFV5JALrVYDo0P1LmEidLOaGawJl 15igXwbF6MV1satW7EFna73UUkZsxcbn35BYqzetyLUZe2UXnaGzRoRvJ2RKtjFB769KUkMa dlopfT91bS6sZeSTZH1AdBS2QKWEV8QF1G4TOxBu2Geo0XNqTZMg1GMtAk9ReA7d6OVSaWc/ L66cGh6Ag6j4QI0yb2C3WCyhoVRh+Y6F9vgN7q1AEe6ZGl+xpebGxt39f2ddXk/U3xxwYlPR S6tZyj4Hj/+ZRqQStLpUDSVmK3mavOijUn4iLo+dzqIWniT1e8np7eTqojtBY2neTgLWSLqM EL1Quwg3tYcxXSZpnCNQ2yRnG+ngfgA12X7v97EuPMHNKSkfyBt1c4nja2Uq82+KCydnquCR KUpo56kcewEqNNf71PrnudTQzpzf+G6S8zJEk8hi+5wFDAJRRxbAFLAST5kuOAUXgSOB50pj egVRdh9Jb3Ge2tzazcM64XeaGe2gG1//X6WVPNhOVnbbSUBmHiiStXHbLnJ3SqcS3KF/An4u arDB/WnZyV44lnXZK9Sx4mMGRLV3JEGrhj7nuH12cG++ByGuYPRcQxIqRgiJDIq1gp45ONKC fO021cP97k49tDYtB5ZX6zaOEtuEFByU8u8RjWhPAGvQpXnjIK8DPfc3Mkeffk4yq7m9UZIH oFpzm/CL9Ebrj9PO+AliB11BiKTH2evcqPhLUlugj77cxDINAwPcWWxvgMVhRdolI43+RjA3 D9FrEWI0tOSAq1Df7s+Qm7j6SGUqmAJcX1YiM5EMK6KI8Ori8ST/fnyD6z4LH4h7QZPg8BaJ vzfW7WFbKOPTUlPvlPoFw1iIHyfaDgKx6zQEUj4zzTDHjrREdeaoFeI8LFjqt9Xh2b5gNJKJ Jc47qBoQh6HeMHpkweMMxSkKc6l6d1SkfekrIKka3tsLgd2JzwndJsbwKTe2E723deivzCRH vNN5yxIr6qBa3xnCkUPw+M3g7UjQx2bRvi87VSuc9b+UHCPBHaZAtDzAiVHE/H/Dw53lgQcY E0C314YxqAHD/mzOgcUOxjxSrihFIkXWZ4rn7wKC2ZnXmF0HZlNruyu72p9yObtW05k+/SnM FQleGjKVku9LRgzISz97yX1a8+/aJMrNXuvNaFCDp8fxrlHDJvYS9u//ZB8I/XOuijX1beCi OfCQ4nyx8DLkKmyorlzAr09lZGnaqHn8M8HSr8qvU9tfMvYluMB6zNFQpXD9XYM/A/sUIWKL sHlF9TDrC1lOH8kmMT33zdoQ8GggAfXLe0nMnMQLxMvAXnxBT5vRoZqH420Mw/AhW5gPX32D SMUk8lWqlfW5ZrcxcA4nvaBJ4BxR24b0UCeAngqaB+/tzUL+1xkbp5BPWnqKEEaIHUt2EXqQ eWJbdrx5ik5fBN3uRkntRrxzPyoqkSz2vb/r/UZLiqzbf1og6vWI/iBDCXAf9Un9JTxA9XBu uOxSlJm+kkuCwHeUe5SSdkYmNo+fXg1q5fur9eL43zWFmeZkIEs+UTt2J2yxsb6l3o4MT1SI yBUFg0180KqQuHtPZWVFRmIndy11lphLF5Sx05JooeAsgbRyJr3UVmy2OrKpekn9Y6Haqu5N 0EuiL+TGy+OgmAbkJtNIOUSqJuZT+1xRNg7eWhNUCGw+39l0O7Q/8Z1ytJBs+5DOU6i4DG+P OzloX2iSJmFuZGGOTxu1eJlpGG6fgwnmhg7VI+tMZ0B/8IlnofdCqvMEXcH9X2qy7fHZl+kw oYGQ3r4IaChTZiCV5XMXvsRYpBgTYmm4avJmJnB5/CuuCtz5mMybhliH5HLrWS4hFTLqRi9a ng85wA01HZz+LSNe4FXZoEeaDlFHN4p771Giqv7SynuhYcrGGWp6gINNP+yp3w8jYhnwhOLC c1CLB0CfPtl/eftothkNUdrxKuaIyJs3x4pMXZS0mPZria/qmK3lva2lLDLN7AoUnrYKPHsv YMSxvdYl+Cf57QRmbpxO39CCiiY2nGqt1veAzBFKQc5EZp0mzsd3rIXXiXhqxyX32mtt0Cfi UyM66hVVjKDBaSVxK8XNkyyPVh6NxWils+UcaLvQhpDQp+0FVNN1GbfddSZIC0PdPbaHJAC7 9vxXwDRinuZI/NE/mdFgU92PG98xASNPu1NBnz26MBlkREtb7TH05snr0K6Tp8ge630EQXad pwJf71s3D/pLLCqo9461kl4NvB+5NT1ij4gD302pmZWkPEq1roy+lKy3VnkNlS/+T9d8JOb4 icwj/cUyJH/hYq+ut4fR4QQsIrMum3asO4rafqZ0KGofxw5KJbd1dDWYAvQywjNzFOfr5fsg l1ZyxPs1Nh+Vl1BX2pj0+RgijwvKZypEwH+ngHDsCRp68EpQnBWluj84hszG82zRzEnMSZHa 45QJC+Wvvh75w5oTDllLOWpMqrG/x9E0EtFSXe0q9weSLhaJI4a9zHP+2/eNgElH7V6VpT8x LZscP/EVItZRnsaBeJqfPHqiLM/azPTyfw9n7V1R7id56jWKggcvBKEZJ5OjvnXg0mT2lOpj +f1PYMagIG/ML8Gjo0KLo1rSpRrs1uaD3NQyrZ1uoWIDIKveVaDOiWlVrHOuT9gLswSfWVSi JaD1j/l5GTPwnZ1pBiaqDeXvS9JE2dXSUdbrvsREylTx+v2qZrDucr8fKrChBTfP3sqq4wON zig7HRB7LOJDb+xia8TR3zQyE0v3UK+r427XY+RxcgWniHHR089DOdKK/e0Ktn0vFQuSNkSS 77/ezykgWH94/1T2Y37X4DkWMZ7M4K2Ng8sgOyw60KZS/oJVed0fTFEmpY2m79IuyFDETSOd RC29HYIaRIJkr5/fzCRvUneR4p1e9qOzPHi41bF2Rgs59NFLGKNAww/3E0LqlWXLzr7p/mdi hOIoXCNlAjyOq/n7DBw96ihiUPJU83aFfmcIs5DZcll2DTJW1/q/NVf+n79176Trpp74O+25 OCqzxYTeIHHGKD/5Q7sMRivgvoErM/Gjit9mrY117hNWf+WFq1a9HdczoQkMC3HxrK8g6Bos ifzH23afOhcJy79Cg53zvSfr7xuJkqRc8Maiw7el2NNghegNAHwB6RNhx3LrbCOd4ERLMY2e DAYJMRNLN4Kk0PwMDA8aiVo9PkTFzIrwLlAstMov9jpGP5QriwVKVoyA2jZmn4T6ZWw5Q/jE GnxiAWLLVFngbIK0focDL4Khs7E/mg3mSAmlZe1mEt+t8/ETisDLZ/YHC2XEtV9mNX31G2ME nYWI35JsiWNDtqOSMxo0ohlEzfWIwVlWqDYs0K9vourdFCUJTBoHhCqoDcMxTUJqKvIPW1k6 iX7rRWRtmwWwcTH59iI6QuPTlZ3zlQ8WUptZuFjiwq6KfGAhtIrdlsOXX8QhgdxKEe8ypXNB 6SCmLuTtpZAV3rNktGFbGBFoT6lZfyPj6mPWImYWAW/iMt1XRKHgZ4JQGIrDWIW5ptMaqG9O 0nMwr3luCuxxuv+Vx4vXtbCLiQcA9jeBAyaIP7U5y+VMMRcujA2v9qULF2L5IXhzdk7yoRpZ J/EyztZe3ppT08MLLKsh+sjKvhyo81UTFGaRRjAlZbZKGFBOXis8Jls3I8ptT1uce7BcTIp7 bE2Bamv6bv3L+xMl8zfbxmRcjXZRcssUBHhJj2KFmowavdtgP5vptjNbfJRczVYIBNYOx21F oLUr/itWWslU3DfhVXrGR35PcG+AI+VyNjGwlk24jDLQTrvMRB8j0I94HjFMQspokVOgNfi1 rpg4ANSaz064QIHmiLFU4JfI9293rMt6TYh1tLevhrLXaNS7MQXg0TyeG0bwMa2ZIs2m6v30 n5S+i97/RJE7/YCrBjJUUPmNVRYdacC1Rs6Y52blqtxpLq61M2ZXO5uDzCY1zy4c7Z5AodpU UP4Nt/EdgFMXA5Eub8Ur54k++p27nDWZMZMfbrUrBMXbyqA/0Bb6wqiTMczrMXbx6Y2JNMuI kP8FrD4hCmyGAmSu37VK46Bty3jrToA8c64YOseLYoBK9aY58SnmxWZXh6mugUZkZ/HVVUrK rE24u5vkc1yD9C/XDhGkuLYAYMoUazt5MaMmlitUAz2O3SQjwPbgVaQC5AWcUV5BftNazgqF MuzUlqyvAuFjRU1I2HpD+cOpUSZYEsKyaCcUrNG1HFkdmAXYBpJmvTaWeujIT8uQF1XOd/aa idBuljPAWOmpRUXSLk0YED7SYAbVc9wDXOBvhdtj/6+YwzWFmW9xW4DhbNwkZ+szdtvTeqr3 FrDHfKscmHVsk5uKXDtfQ/1FUD8z42AgRl7BZyaiViAnFVJBP97sNy0GjpHH43isBbKwJW8w nX2YaWYBxh/OLRkBHt0wScN7wxd/1j2N/zpdtoZKs9vq45gsW0ZOkb4bczbmADAzT/MA83gw DDw004gtrZcgIv8vEqp7ielxF197cTQutcrcAnhgWyyXbTKlhLR4dDcqLkCXb49/icrEL2RD Prm/aNqnROZBMMy6UusUYi1N00/UQ1/28N98iPW2F6GoF5EsNEuPSIDoWWPmpLbb4N7+WUSH FruKOk1H+PLSkoPzh7pkkMyE46DUuMdJ4o+LyhccnXEc2RhrrAlbRdEcHu/xk54L3n2ON7sp xgR05suRQqMdVTwSfwQj78/ojxkLFFK3tiL/XGmv49TUdGOkRJUIoijQFsnOblTtt83zSGYS 0kaKUMPKzlexS0A6eAEXkFO88niG16goGZncVxoSy+/VIUsIbhzbNJkwKpAc/Inj3nZlRojL oMEyx3xYPHZF0bnKZrQIq8Wq8M3sBlpfAmohWhX8ZKPXMyazNcWxcZpF6SU52n8UZTeUvjnT xd32H7lRzjiBfNHgTX8Dy7WxyOw5nRur0dPC5PjrViJbJ20Z30bdjatdmeKWZd8EjpG+B5tT wgzyqMmctyGIUj62gpjQVy2HG1RzCMA1gueQXcQr0UcCIxyVui4NMroPj/dQAPsT2UWs6EYk bwwMT0BsEue6hEt4xw6uWJBLJfiIfuA8Im6rCA1E23uxKQ+bOgXqnIzWntSJ3myKLgwbFGJt rifTgOLVO16kHFGWPmUBsAM93zAgWRYko252MTvc7TZcmjnkR7auNVrQTuIpU2rOBpOeP9ga +IOCv32QmPeBcyKe5ELglPoWMQIxiqKlCruyF7iNHHNClwjP6Lv2K2wgzf7KDLnsV8eEPIyI 44wi4zwuKz2t4YGNkO/Vwp/mDDW2hy8AdM93nc5TAJpRYuMQtm6dDHKXr5EiBMWugtig9JKR 3R/ja3sPd0NGCDRhBK1YP7FMoZXD6/ii50iw1DoDTz1ig+m8Xtj7IcqmGRlt8trJ4ER00fyq TWaALQQiRT6nIWuvoEs+/i0dN6wk00jqtmiuCbj86Q+VlJ5nPSbPer+av9ikFDv99l2F5pE+ hUzHdvzsJkhSAe8jKhackQnc6yQ+nh40u80kftPxPX6cLx4r49ap+O+rKE0TPoq8jnus5FD9 e5hcBJWfZ2ypQAAYoGeztWKLzT0Fh0jpRefrgCmrCga9cWdvf+cSizfFLAMxoWWJBPEfU9OW O+voPqArRhxoqAEB5czqnyBaprzvi3WzOOfVsgDUk9DBEuf5jD++6kIZzQsk43EXaU/CkhgR bLYYxSPYko8ts6yIh9hB9nCmWFEpBByW4jotv11pgEdo27UMg9MmYHiP3xtJrMT/ka1Zwolk 9cvErUS43JPYPr76DFl1FCFhmAek6A0qv/V9Lza48eQdrdnWbRKe5aX4l7gNeHsea8llV4rK WjZfO9Uy3MjVlXI4oHV83AaU7kwTCx5Oc74lltpF+8yV5oIQ6lQqAqKMG+/LNhlCl5Uzx+Ry o5zMI2O7V6K4zXBMX2raBPEYI+HchGsEPBrd3bvgkgynd/T275C3XRhiXqfUguulOSfcF05/ NYbbe1bKE8DL4Bd3VHy7tZDkwNq4BEh9Je6UjNF8XfCtvOT/aCR810iiSYxe2Jxe3XmiDJKF hJqx+wKQgWHJ+wFkH+3souDYFcdNUGIEdnzUNFMSxx48xS5JZA8CUMfNBeMMhyWiGGWrNrHa NwuYdewk8Llzb/pvPFnjiYgyLdQQBEKMnzbtXXt0wzoNNnacUWohxTqNIVGKaFFitiLuBpZ8 ygmukDQZAW79pLbVsoXLlmL29pNf947F9cEi6co7Ig40YoJVqD+NYfvZvTSZqoUGT24iuNTg jZ7smAbVOlj4RTA8bK65dnFmHU54aXeXyiR3kvLrZyOBxs+Jcyt7ZxmMbKMoATGBX93ib9DS HAKsdv2GYrY9CH9YDyW2xxukdUjaQqlBI+r3eMFVzC70P4ednHGnclKJHVjFc0hrlDe9fX74 9EO1V5iyEOrTx6OHqe1LhVEQq6V+wbhGXkY/QykjegqWZa3jlYaHXmwnWjtCo6NLlazXRH8d Q2PGTNPGLftnUkh7knMXdN62W1cQQaaeMNqj8xq7W1oLrOyhtZZyQdjrIYSY5b/lWPHzgd/j TY5utklG984eA+xUZMO5wY2mUfsu/21H4nYE9vuZcJR5U89yu1YPVZS3D3htnLGLPfqSuyw4 fOUGjl02YgZmecI0DYIfgNxY9NwyVraK3Y3r9JBjGft4Ep0MtxqIFVmdZ0dseEabaYbAzKEX mvyVy7e0SMCsD2MJQaXF9BvccU6EfJQnw08nOa7RL9wsySFKiHIdpt6q26dO+qJ1vd+rX4AH a67m4U2tDzo6XukkHz3lB0G3GJ+xgGE8WwCS7y2uwit5L/Wphqnj3xW3BgcLecox+AlunF2T mX1kSSmtEQrx2ZlYTVOgUlg+nRTbVD/gvCAduCXx7xgUt2O0X85If2fD3Xn9k1JNKcp/WJ66 bzZjf8naHfKPvqUesKkJFF76lXz9jSXWWh6UCrkaZofUBE174mW0fCuTP8Pw6Ocz+lBnooIE c8ZKzbxMpD+H5y0ppH9g2HRosyhV1CksF2ZbhwTViak4sUOuJmBqKfSCeli+g4a3mQEtmX/9 BTqozDkEAYMkH4ImXS9bC438rTqSTWNiC2iwK7cWuQbPUW/d46uoeYEAB7jezmExIrVJ62Kx FvivipckIYVHTN3kOUg3tzDqot0Ws7BA3hT0jfmJUyGBh/U+1TT3A2RbKcL0QzTgacFV0+4r oNgvVlT5gPpIOIOsAxn198Cg+92jitgg3WYfuNZcJaFFYTKgHIeiOmPotsOq+ODxs3qnPK7F 3EGIrDhHUdyUYyHwmvSo74lxcKJHlLQBWzTodPCa0ebANFJ4/vE0oDgI3SktKcG74qL5mNtQ kX730EE3qCChFnTwyCBpUz0540Fj6PXJXpaT5YAftmXEgMEPfMoaQkRwoo/C+byWiQv5sfq2 otLQs4FrNo8SELoKWmF82VhFWs7tAwzzcn4ddqgJVa9z/g2YBmWegqerV8R3XeUijZl5YCYO 7yufqzex/rYv2tutyHJcjZETDLj23ylLCxk405c2mWoPacEfjYzR/FsHu4KEHfkI0lF/d3UE Inzyz0ZDpIUboBkpSRLOaMKOoCZjZqfd4XGfUhvNA0nexZlqyYCWaN5M5QsHcJ0q89ieJAVO VYMf2eUKYfEYCTnA7jIWRF/dFH3DHVeB2jisvINqtsJHYypss9qEa5xJqBJiymEM7Pi2LzI9 KpCmPnMaUcqG6SBnaYdMCu28ZC6h+7REV8ukUSkcRIGoN5fP0AYIW0/uhXtrF7TN0eppxBye PQwC5ci9pS8EITH5Q9yal/IvET2jnnAip1mg6td9kE14egKWsLWlX/q+sJ0+H2C2zhDM5TnI 1vyVueynP4dsJ+pODZM+aaU9RU6pRGYhqJ8aGd6wSpDfbTsJlmJsXiUfW+zhLiuj2Ubphs+C nLlxKyA7KlFWTOPOqCjr9AwHM3p5tCmtVTxnI9LW1ZXZyA+wpmFFw7oO/NQj7Lw6JFnzq2Fg FHZn1fHlXQM4Opg74zgdQA+2QdwAGg2sM591b3e/359pkH51YiNy+9ZHTlBo0UPGfJgtvhBT FX3wBYE7g1PxdYpu7axiMOiPR0+TtDOUCpySfKz6ack7Sz5mJjeVqOWujr/6gimAxKo35U9F ukfXty8rAK0bJ0sykzXRyolo2S5okaYPWO2Fak2Td3Da4RkAKKtMKEPc85DrZavjPjMYu1Xy efuBSbMbiTytxUO3gLfVjOTWMwEJqm4VZnjBicoJj0t1V0W2LFAU6XkuzE44zawzdY74qV6X 5c+WjNmE5zOy9tuh2OtZ+wCbknZVY20qi/sNI9KHngnPGb8ARJrRf5nCBLiHEsaigzlSubpV MHC0oJqV6D48oeu/QBERj8UORqD1/krlDCMGgF4GvBvZ0l7FDBBAX3pFAi41OejsAqL8o44a HGVTSFaHKzmgh9JhPurv8OOxE8Z5XTTUBlxIZwna79Jx3ENEl/elNYR6yZBL6APtB1toR7du pf9qnHaP2kyrxwycBOheDZC2dKBY9Ou14F6XB7m709l9mro4z94hozkXv1/ZJk1Hj7lbDczX Q64e7dqKx2fvQNsaMxTPZmU9SLmjb53+Ae+tyoH+CA0/fnN7cjH0r/v8gNh3ihfgNJkob9Vg zA5jp1W4nJwX7DJI86TARXgfVd2djQRFkZ1h7jLBiP10AkwkAn/qc0uk6ho9SOzBaYBekHJz JkNZWp3b4gQOAwwvuNb/YOIIr1GTzcbRjyOLOP/X5OKaysxth0O5PJwjj5o8VGJBqJ5F0Idi mM3QIEmhMNcqXQPHsK6/umbxxxvOloYVDeXhR3E3V9AtRuoWwsgISZ7UCx1kxQqP6AAAfnte S19TrCL2s8KL5kFQlJnLGsECbKdiqbwNR8MUkcSmFZYRvWm43Ppmzm8ufPZ93OgmyqdrzIe2 BVw68cK5t5osiYWe+E9RtNR6vp9TMjFiRI9494Xr0d7hi4ff/rBHzGhuyoC1++/FBMyfKq2B zFrZHKWH/fyx7tl9Gm/hjdQqq+4wk8bCb8MksGLBUsZ/jMaTwlU3AT/fLXicvxnfT+bmyVqw yRh8jGzWLHgsRmzAzdvRTBqbU0eOQgAHBBXFQFA9wR16RP3rG7+L1TD/wYbMKxs7KDXaTHVl 1/pSctwpsxaAAnh929/cc/tkI5gfcAapTEckzIiHZdupawyG/NkkSLUt62FawDLQHt6LkeRv ANNuQI3/HmV93ZJL2qWSNbRD11bwFv5FYZ6SiCTby8W0GhdTDVBD9u+ePHC7d78k8XyZxS4M s4U7ELZ6uIz4ph6Cqd/aHovDjBzfGv93YRxzMcsRpJGnFxyMD89iSJFvkV+v5ydCjumtDI1O 8LSvbzGCtoeNqZMsi3+TG5L1pghYETIMa4iukPLmau26+0+sgmS818peHgrmspGulEEqK0+l CwKj/oLE2AqoBVRmDpavwKBM/eUBr0e/s5xWcJWoypDrOMkNvBrI9SJx3UqhqX9HWDLCBnlZ /VzQRr9UPxehtttpkG0CWOMcnRrOfO3h3nvBziKHUqXp9Vl3McqL7cV8lvoH8b24IETTKE3u 3fjcACb6mkXnbFuam4oxK2e3dzFyPGoJcJ21aGtYSftlCV20M7NdSU6juUdmqNjINrxxyrtF U8HymcWBjPzIMP1wfjxIFHRfMnN46wbMVRbBX0kr4K4VvOwMhF8xbm/LihFxfzOE1R4H7lZT UoCm/EaHcC7xt7L77w8vlrOhsb0mNWw1Q0l9dAXgxntCnLimQ3m1xD/7580vO72gwznYXK7G MwuXZNVBnGbWUfowtK/6jk+/5yjlXoToICA8VPqxwyZa/NmZJ+xjlKQciDa/bGpJUacTw8oS hS+HpNRUEvhg8XPHL/8s/I570FDAGXvwT/juttukApNCFJQ6T1x7KUy360y+naMQMDsV5RKK v7VAYLCsOt44L4BFI2zLQpmQGzfGOgEBX06sP1goAYmefVpgwsveUQCpSMKf25bKz/GBKT4p IRVXpcwEeJRCUsfkA/k/q47arYd+GW+lfkD3phtNJbBpVg5C5cm3TzWQoeBPD/DCLmaX+cio 9LYB/JYgmGBI1K0517r9GBKLvTkGW5VOESurHP/EVBa9o+hhXAz6fy2zpLujnlIT6HA+DQFJ ixyuTwWQUtLbDqVkT73AeJaeFGzjnR+H1K9sNa4ceecWG7+/tENHr0Nvy5o+rABYRt5+RYRn rmjT+Cf3/DOk+8HnVzjYNfdWnqF8DBPzS4a5hfewFYcG437B+n7Bpr1QGC8xjAyygE0wZgw2 8ZxprcdwVOSMg/JGfM7IbjRAvTunCU+DaEa//cOsQtsLcE5hVll9BXYPGjjR9jz4lzHw70nQ WFDMlnjXQBZMlzXPe/Qm7BFWhxn8hkdUBuhtAQ57sYml5B4xeBY4QQcYMD90lWRN/BD+05iM r07P5UxhH8DjeUZCbBNMk/jsdM+DBEvAEuwYIMCsOMjOOlKedR53qBOflnmiRnem5+Lx2DPZ qKLMwDSYksSVFSebQmHZY0md7K7bGtDTzZKwAz65ZMaLbu3lp0vIQ0i/MucYZ58V4PZDqUTg SjzRzXBxzrtIneqMOqVd0+Da8AKCnlhi3XTbN7ThaYEW6SZ19CAQIo/Y7P222Wp9IcSRVYSy Gf+YLp/03fKlyXHz1JcgCftCRYHE9drAFh8JZ6ows8AFqcoh0wJH2XX27ekRVblJmrDzPzcG 0uVY9H2b49cF73UJDlNg9MOKgyRgxCC6kHqobhXv15gV9K1VgFPTHgfTgEAQckt4J0fpptQ3 xqqXSdAJnA0mD2g74ZqMOvblL/duKGJwlzzGjwbnNA2B76HzIfxnQ1b348CCuch4MnytdwUy 1wJEVZH8sJOJTBDkkABgGG+1NsoLwNaHSWu54Cj8h98GIr6Itl8RcJvXp69HwVsVn8BF02d4 reLUA9CodNdrDzjdmajcp3qA+4d2uzXE8AlIL31XlxKBYG0PreXKMKmthj4FQzpTHdtsf9Pu gcAkU8SOxApCujgTCIueCwrYCK+1N0UkrDuZhXUbmaGzNaXUgfxyfvgdxoJ0fS+EyBACW/Fo JJyXMIOOucF1ecVo5tYj/EVG7metp+T1JByyNAPXMOqZ5kwqqu61buftee67vKeFNVe/fREt l+YcGaiJCBYsceb1sPxrpVjjEVBD0kgEU1LLQU9u+phvP30TxNCzB425Fd6OYCQdDD1i04iW u2Ljci8QHb17ONv4j/O0GY6VqPuTEkryfGtlTEoRuk/Fp4JVDz9LLndY1S4LBGjZRoVPrEjW UGHz5JTJWP55JKzgLhgbdcwUACrkQsyd5I+OD3NFRNZB3JFuUadVycHv0vRi1vyjhujZScwx 1ZxsUSQXLbuyJJRuqdZCEpUEJBhqP+sRu7xrR3t20EwynhEaDb8iKuDnspo2+xYzEn08oXVG sOu15IK5+O7imGn8QneWScAOdYp1r1N3qA12Mn2GCNvNE5Uhk6zp3Z0ZHq0v3rH+zVJDFoAP dHHx3I197vqnc1Ow3AS/e1bl98Mwua+pqQO8ttll5diRzNIOjnwjrjXtXpaCEeFPhP6uGqUH DJbWyD2PV6R06S8emUIqsNy5nvk+68bSijCS/5mOsfK7QVNmw1UoVNnBc2M2RC5YT9kTL0na z2ukrjPxjKCrSNLbl25eg/aar3Wog7sikxVJUG2X4uIaHOoux39XCW26DAUuujCSbWKKK6Fx NsTGjWTyFNOBmQiHqoriA9tUeJ/Rk6W46oVuq8rhw00PJE6+u1BvuaIaXG03S11ypNTi5SjQ 6Yo27xUeRuY7Ue7W/aByYbgvh44WhB1zX+dwwmFm6thihR5YW3ctPh8DDFHmoWCDXG171s55 VwCx5Y/HJwFzmNSu04ZH+/amP/4a8JzvNoQS8mlFIIbwOjjsht7tzpni3ySbjVVVAuXxFumB VtNGIc/AgCxFpY33oBhCfxi3SgG+ESMXCuZdaTINSwlRt635EmFuR51/jpQkwckRhaCR7GxE QOcdYRZxPnprUjl1GNJirOOODvvF/0+uu9J+y95pwZaqDoAUKjsMw8yxE9XwGx9nubNvsLul RiturKrhHAEzX+3RuEDVg1D98jRqQoO9b0/GrVHMVChSzQjZ0F406ajtKMkQXnRadu1Lm0e/ NpZlOf3TvEkkYtmH0X7ghTj9h62FNUw/TgqYYJp5a4wljktd1LgfSL4WGAv+jjzKkfOxqdgh 0i0xsRmgiyyFtCoNoUn0mCwQmoUDjaftAXJGDpmSOuE2MW2wldR7Lyjd1HgY0+ZAPwcvvdCW 2dkrh4AMgvHrJzZY/CvUjMYThercfNcCP7EUn/VsgU4ti9jQSU1BrnMr5ABw5vi//noYe2Ot /sQrA+TsfBvDo43x6kOtfWPVd+7ZkcURU9yim1h2FpxtV/mxdn5pkmzEk17EpVIe5qtOMG57 ZaJ8dij8qUMvK5nKss64pGqzUSqEPFBCwU5wksS++0ZAUuYtee2UTri1VBvcDNrqvZJ3SJO1 uTT4tBLKqp7zvBzNvsMNeXgqWh0HNtNQnLBjzlOFijEiliKICxej9Ll5Xevt+8WtWW9+tjE5 O1SfjYQKFKaTdxms1NV+4VBYjTQMqjSDp6gdlkuHxGNSbwfJQQlYBsJWhZWxrrKUyQ9b1bzS 7IzSbayQsaxbEwQ71hRGna0jMVfwdSeZHc/CVBgmO9CSAr8HfbTc8LzPcw6ReQZokpAXzVF1 Bzjn+rzVP3jvav7NPW8j5TAjzre3gNfCIDiCKiMVMQ4Z2Cw/bFoGlP4RSD6Jbl/OOXKYgpZ8 7urMKuEgQR+YTp37iR3FA3bTbXcdIHAKcWtMS+9zivNhwLDa/z297ouZPpRBIZkNc+H8ouVc a9CWq/jnt9PI+u5NKYRO7fhiEai5dwj+TCDC21Rv4lDGBFh7Dig/g2AzQmYzY3MJAkuS3pM8 TyacPIBO8x04NDdwXNmsdYkOISHwjn+g5A1s3eArk5m/aoz08F+aZU56kp5KP6uDzSrMi0wn D+I59mKZE9GvWdxUOSgTJcguLt57FnwTghKi9n5kNMOdZyq29WTiLbBLl96JAxZOQ4jixNut OlsCchC2uA96uyA9qv+EJ7OOdQGEuGcrHIBxtPnG+ZT9mln3+mN9N/Yu+n0SpyvQwTafk9+P EPH9qnNc51V43QZvCrS3jOOyIb3veLykJGlMrUZ+SMOOEK4tJkJ+hvIY5azk3ME1fYkrvL9i sGfmdnj+X3nRC3YPgCkl7Us6FWdA9l+cCXuGsFnL86XkCkPjE1PeCKZ2EyZ8nNxRfvY1GNHI BJSygq1BZVwX8EcinRSZaOWFV80bs0Xmi0PWCFWKyjpbp4gAG52oQWP5UXkrbEHp37s5HU3u 1tXtg3p4MdPsmj9bLgxPtIUJOLaUeI2kZCRFwiQ6Pb6rniXvqGMeLpHhxUV+VA3XFn3IJbcV 3Q+h29pAvMUmdQmfel+DrGn7xY8BIrlpHu1Vcoqvf122Rtr1vIyl6PMP7GEHSWHzMBk2N8eN uDDoz5EcpFomte5iLI+r6p6QbdHtCiKpcJ6hzl9aRz+0xOFRcxsbzbdnbu+VkU2XcYmBXu48 mZnYvIJ3MINEc9omQXQGsUFQSg5dwxPID1yw3g/xNF+AZbrQ4MoMAUvQFn/cWdpucn15hw79 7tgWaJQrRIXwvYClae2bA5S+yv6Opw3QUS7foHsB6z2kgDL9fLUDzVNk1VfJlsB5kWYV9VGN WYFMGhxTI99oXFmzWS1TQgEM8/bHexCy5k5l2KeHCsnFq1aOkvgKABSqIAJUPYi8cLKKabwL LS7RXwWzjc6PTFfQchXybOFqa1CSPVmqcwb1rGZ5GxJC/o4UaVRkK4DNXMeWxsmUIaloZqZN Wakt2Itywi7d2Bv68X+9wyQkDNlh2oXvv/hcRuMZswkI4WKYKxXllL/87dmP/lM2OreasN46 NxxqQ6Pz7EYNMBsSniC6SJqiRXrZWrhsBs6ju828EWSy2X/tTH8duHri1KG42KT75y3Jvnm2 yhPjzqPuwJyFzd3EMJRPhZh1520kzhgmq1FzmPvpKR5Bh7IRsK9rI+rZS05j5X5gOADMgbKb OJ68/1uJoZrdsWRSqtVwNXikdKG0GPMR25dyLK5fOv68M5y73Cqx8kKk/iBvtp7ovnUtnRzA LXvyQCDoEi/V1tymnMzIGQhbNCCiQuw4k8YwqMGbmusVT5zLCQbCvRs0D2Z3B8SZeKJSm07Z iES08W9y7SD899+x4bfzTu31QjuubcjfkkL9SO/XLEKQuX4A9ZMHv4mWxPhfFd+sZliKJa7X QiU3kwHjr2gjkLG2QXBODT0lk6c4k1quj1fRl8Hxu34nFlWOpZ/rhp+XRqZ7XFkdiEguQlx1 mzIrAw/mxRPGhQ5tzUSJP7Kczql/CCyD+Msp7ldInzfRrSoMD0/09QqzDLp5QGwKUrO+tyu6 esxH3ICQXCvp/tcVxxkR/Q7FIxaXhWzbV1UWaJggociQWTLR358zJQpitHYsqc6j3n9VTGqW H7Mq4+OA0So0SA1iHEQOxF+Y8E/joC47fDGm4oLoUM5XbeR6+W4TjRqjSL2LJtWFLvZGYphp F8fJzuLQEdPnAdRejykYfDSDvTlPDOqpoU5qTdVCVUiSgF/2MhBzWDOKrC6TcKdlW10kFuaU Vw2FwPrptAzH/XpSmjO9d3G5WQ6hlCE++ffkSLi8HyMrs7m+mZIbaoU7GJNULvMILAwc11un d3lP4eLUlX4fTsf5G6FkeXnA3OTwIZL/btRoE0l8ADLVjDSVuQy5jYTcNHMsvNODb1JGUETK mukixUfEIByqSNF1WPAC5TZVDiJkLsUurlsqPd2VKZ00JaG73dyFzyJt6J3t3eBSlL537zp7 fIG0lCN5XoChd6AgSaiRopgfMRWEdgSQjOukECqPw5OGxy3UUmUYDyMwdU0+smi1d+Jzcl2g fMTOq+yXq8pW3w/kIkjyIeQVKrNKRAjjQhkGjbjdyLfkZ9GwDaTBdNAfd2Ty4L5LymGHv5vH IVqMnUq2wbsnKXlic5M+rZK7sVRovRUh8LK42YffgFpvUGBBOK5Ih+WmCEJ8z86pLMC6JPXi s0yQAR3zBjl7AG8c4QQeKl6Wv1OuMGafGBdFQ4wvBWzKx9HrbG1UvIecoblQ/KJnJtrcz0QS GlKbKGl4Pr+GxE19cY4f/mHd6swN/22avXhP8uoHUAacqsd75Ed9ekB7dspdcKl7aQHEc9Na PsVxKQMpZO5+GBkYc10YZVga2FDjkPPAostVJue8w3nRukDjM/ABLAvI4ph9o2kMFUVftZGD hVNUHuJRf7UsynNDs0sNsVnHR2L3GIvS6dRlGqXyk5roZvBclWKnm4100v+rf+RQ/HkmtnIJ DAPtFszeIlxQ4W5sGHQeFYV9EeFKTmAx0UtgmECem851sJ5VUaGa+V8ZN8dgWPerA3oy4UT+ 7q27RpMC/XIr/2R1zjOp0gjSjgpMEe97xCC3mk7bNbgLLb6+ihXmJULEIeBmf4iDP/kZ1Nvq 0ZhTgBrPkOLZWGuE0+ZiqlFOd2ml5US6LXQ/8jfnOSP4wydRdXTBOTOpewexZw1KyyFaZYgX Tx5zQTNf5QFWN4fE0H3CCkPYVhNTdPWIDurIhwMLdwxbCTM6fcG3+JA+1TpQX+s5ZlYw5+bv Dqkre+1YmDqLgnNP4iBvwO3982IldPaL5oMCMAEDQZ/fgeaX7kuquF6o1F2rhwzao832T9WD uc0Bn0C12gHppVwI1vQaN/l+YGSOoefnadWD01/DSw6sFaoiM7JDkHc+f+tarW783GELIQtS sDy7ZqOUIKVVlkTDspBxHHLph4kdT7DHfdH3EajRd+vtB3XJGKrm9S4OeKVhpvn3graD/AqE uA6RP5lbFTr+2FCGSVxys2FN58rr9iwmDWF0pG5xJvMDkeX5LHZRv6MT0+NxHV/eud4mjTZr nc0vPNmtsvaajFohb9nArKfUMSw3zhPEE8r7suEyrZBStB5zAKO8kCi7r39vd4EspsF3/aY0 qP1vQV9Zb5qMPW5zyWWUqM3W+YpH2Dbl6bvnrZ53G2/2vtWSR4T2RvepIfh7nr0xPeF85lAl NDPKkeeVRXI8beCoHkm/TI69wL7UgzcsuwFNe3vNJshqRFpzyOUwMQ7fWpfAKQ3sjavWauef Ye0abJIoKQEaNtd7gEqbzCAdX0kNfn1NL0YY+mV0oif417KkQZpNqcG2fE0NOg/wXFGaCQhE NhDR35SEpQyCKeiUW0XjYpV4ozAs/gt+LYYKD05jm0R7GdfC18euMmkx4iGipWyY7MBOQm/1 UWLvRzSL3iUYnc0knaKBJCKES9bWMn5ApCxE6o9RYewV8OeYktQ55UUTZUJq5gAI0FbWK9QE EucsjtpxORvZyBKVHIPmhr/VrWrDutTHMPcRm9rbT07dbrdQlg1rBg7wdUV6uoXg802cSDQb wFk4fZyIAlkOOn9gFPFWvwDzhPJvPMjgV2hZmJp4/OWwFcSYua8rat/iJ/1B2Eizr5HsKyZh iEbCcsBKgnfWyf/euiQoBlYNOBSlNM8mMnSNtufXzvgRu/dRANT4z1fBMotskL5Hmb0eTBQs D1uRTlCWsDPIj2/N+i2097orFNQcFF9Rg8V/ifq0dptknfBXAnX/+we6xDSwcwxNuNEGsoG/ UGGmEAKvcXQi/xs3vOIOi9nkVlKONE2xFjjzR6jN+ZkZ942zu0d6ZUQobsbCR3NPePvxbQST 8y8EMCVjeVK97nvD0K5V1vGJZEWdSH0qqzph3ceiOI+sla6bvUdgcK7TP41gTjH8MT6ky6DP 7964YSvzTXlsrcEx558qS/MN3NmCQPd/Fv+L53AHDTfDxP7PPvVgGwMEgSeMJ07O86bDYmOa Bsa5jSaZTE2/SVkBi5tyQiqpPX3biXakCofOAnkOksjdCGUX5tUE8/IKxLDdHqiL14uKoGG8 +YI2YYMMhZ1cm8y16J6sOVczLp04TYR7C9He5zLt+3KL3e+N+wy+f15DmsZn8KsRJVld/3Gi /YtbnoKezt3osMi3t2ElIrAIaHHyO824rTWaHQNItjSQwesGNxcDnXFZg2xGYKS6xYL8PLsh jl1QuLN158Y8GVgVt5TU3ONovO11I7a9blpY6yNNP3hFIM72++dRykfFf47XzdCokvZ6WQIS zEzJhzuRrPBySi+i2h2Jo+hy/vAKQUS7YVz//F/YCUQHxCLO197Ku0mGEaEM2jgVhk9hq5Zz j5Tjz4j/oDdwREuko0d9B8lwLOPHunjEH20ufpHWTncIeyPVidT98DyiIuUkzCa8KagPtDn+ KCIqZCIRZhm1DpFRyg0kkGkvyo5IY52no9A3hK8medR6KUXQgOnuSo9VUor9nROWLNROxvum lG4G2MIlIDjR49coOyLUxFKq1g3Yek5OJxXkaLsAgN89fV+ku1qqbPgiG06WCgxWJA91D8w3 dHJOcEYcENyEDskaF4ZCKSQIX5oInhWyrqhztn8ujJxdyELHx1woX6WtJFKy1le4QJ+IpXSj xETTkqnw8uXbySxqttk0Tz4XIks/kMPaxOH4jbMv2ZMR99N2Bo9yNLprxF93NjNyldVfySV8 fPVRtYC5fPIjnDrbK7OLOv9DovFbgW+/6t84dXoCDQ31yE0qCwBuDuTGGpj3rnfXac7QLxdB odL7v72hFVo5ZapXJZVsOHTSdbK4U8w3CqotzlyRapO0bF/ZFtcrr7CQ9jUySju8vr5ts4rd dvtEyW7R7kYtV73W78hf6JOSLTHxP0MNzERCa/cLoWcgxsySe14T3YOozclK3fYiouUrYLuk 30TXH0kOc/9JelIxxAnIi4WUYj9nSPlu8IpyH+gEgyzIrSTI9lURpEL/kfOwcGKIAwedXvlU /Od7a0oatXw2njNTMxgbVTT0Szc5g2viXSWUY5Kuc9DNvpz5xTP0H7U32VTN6oMcnziXzGr7 L8UN76IylEc7DK9ny74K4XaHUx64tk5HnSCrwnDdyqGXQAtBc8v7Gs0eVBuxaIdWpNBUr+is 1XFbS9uNec0negI9NHMKhsPnRe/CPbRYaYDWP90GraOnLsjfjAVe+jV1ob3ZnSpEI4c9ui1r flIB5Z+vIR3hfKMz2OWSsxOEYC0gbF7PhAJ3RlK3gkKl6GajXwehXVSvsX6vV7bUHCN0TXYF GD+obL1z1m77ocsD7Gr+zZgft60BzlTazEqBQLtIi0LcN0WnERd4YtayROe3PNcZZFEq8Oo4 iVMtG7s8t9VOqv2GnuHjhQcLZmvsKES8hDPXRpV/oquiEYVqg91dYuWlEgMUDtbttlt5T73T Yf/HMIthdmi5Os1DaUsGAXIjx80Vbj/p8lICBmcP38kJbHqaO/gr+5sDG6jK3wEavMYHzrT3 1ukw3XC5B1nIHDmvQRZoQc7kIDHrYLeUVEb0od+fyhsr9BgtZjCQ4t6IBJOQpEFdE0rXmw+T +YKBOtxCmGQHMnRQaQHuGPu2J+iCPt1h9oySSGSwC7FAsgMJ7pXnslipYcRmk/cc8otNZVIi mD8pxO/gueQShzQooz2vN803nmjFvcGPlZqvjDEBJ+CnatxDjoGPPBn6wkJBKXlC02FvGkUk 0CprOXbGj1tnJmn5UOGJ9cRoir166rkhLWRXvru9zbxLkQuvY/AmZxqBI3t5rt9StJwcJPSr KXbWoyNOCLxSXy+yO3ZNZHKNFF147wywVZfi1wk/nDkcmo9wcxcgp2Pkk1q0ptNkkNRRwI0x 1hX5+8no75wZfLI6fUaHLAfC7iEvDIiXtydx4eV86/6nhPxuvOYeetzdqdeR48n+uQVO72Qn zkeUfVEW1R3sM9+ItrG/rn7pBVtb11BWpUO9M/lgOP7earOKrggH6Ce9RkBiSi+2a0Gmbeuk UNmVYsS4SbJoThZQamm9pfs6FiNokNj/VPQmcX0a3lKAAMW/fnDmDIZoDdoyWb10Pv/TSAG8 lIy3jXyLXgsbH6bLSrynxwEelpVL2Vp+HA2s9G+kjVJFyxyjk2b8IZxlvyqUDhHGO/rfsANg BEJ+7auDwT0h9VawbwRBdJyTqhjB47UCh+t9Ilmb1Z6NFGWY+qH+9UBTeyXLB2zDv4b9uthf nVQNpaVvkK5V6v25rvQ2OFZiZsZtXUkPvoH5mabdbj1n7k1sTX+Kw9WBodaJgtT3rWQVvMxm KJ1U1OgmhuLkCIACpimZFXNeaal+QhwsNY3V450VB+ZyPD7mQJf9L1vq9VqNpuXhyi0kZXoJ U8vUtQ7wjWu515B71mP+4UDMWXQzm3YrZe/ROHeb690fJErWvvP75cIIaF9Fppp7/UFUgc5Y wPx3IiSkfp036sdG/w6iM+H9w2eIWfp7Df6DL7ymJ6VIs8zKgqacvDESEOUqkc6ZdTbaXSL2 0V5jmL/3kAKccbBjhXBt73g1Yen1ZogeLp1GvkR4HIgE4YjLhFZCQKZNZKktrxncB++6v+qL ELudOYrdiS+rNmVkhTKLl4OSdsDttqvzPZ2nXHXUWaCY4Fpjcd3VMk6jOYbyZTv84oczssaq dmhQr8uhUSNyCLUeakGZGqBG8JKpQuzwTw22eKEk+lwx+zNFuNpqjjbnH06ODwiC/2YirJAQ QG1VdPEX9l0s92F1tfMffAl/1TfWzjqvdxB/Lcy5ZSlACKJc5ChXn0gHphgeYGWXl8aa24l/ 1en9AAMbo6ycmwVc5RB+HE0UyF3OmySBcan54XYcyIsHetei8omP91rtnLKl0nX3ZwohsFov nC3G9l3XqbGTCEOaRvQ0h+0Tvtdl7wuVeL8Jn1q+9sYZSryT9lEVP3JBEk6bkGMbveonPBtU 8chIQpjzeM6TTIyHV3ejPJNPwHKSBlbpbUUAT4tTWnAw45Lcc24j+hPlLdlPvGQo2OeSRU8V jsczz6cc5mnwG4R4yfAh57JrJpH9gRN4/IxJBAXa2t4iuTrFgSeVSgcVqD0qQ/Mr+kqf9lle HAdrsc9HmQN53plEKh5N7lhRtXPSxZT2jg5cppIA86yfbkg0KGI8IERtm9aHMPr/0mFzFLuY D7fS35NLVCwrb68TZtPI4MDnPVNphlHDyuIO1IcAM1/wjF9TTfwynyLaLa6dURfrf4s44r+2 pGX2p8qcJAP1Qs3S2g3K/MWtVkMSgGa8ml9mk9Y5xk444zyY4P+9LoG87N/U9UnvO0ksBOdh pTpdYhknX12QPRxpy8/63R26vG4drIBgi6yyh8ic5TLGdC/IGZ46am42derDm5r6HXzalkCb 3GsKEtAVWNVQyi4IPuuuo6LuiV7U6VCABs0woCixnNuav24go9rqs7yKXFX856OCe30YvElj D2EsbLchqc52+k81x2UV7KGYQgtBRWOhA1EKAmAsp6W74Q1PeETny6i5r/FqJAh4M59I58Ky 66EVRwNhN6hKKTxkP/6rmD31BeiAw6ThFYNNxvejDA8SVnxxM+GB4/vLHPSPT32/OrtlZLJc /NKds0lhLKbv5UPpuon+STlL5kQFOnVupxgv8Cf2c4Sl2/cNe6QECKMsTuIwLnijlIa3kpQG QyDlX02+sqntwBMhUlXe4WGlVyZU0AQjQcKt/OS4BkEg3IzY6njE+9L28j3CGV1eKvYAISOS JjqDdpMv58vxsKv54zjGUhXEHtU/GdF0ppj6gyKNZRPpDGiDuEO9234KHDc7FdNQi1oPs3zd hyg59US5QnDcYSJAUSdc40mYlSQ+z/jlYwUBnJbrskBF735OWjZSPRno8Q9kiQFntmjpLAJS R2aZbm4/j7Y1cQE5h9lR14H0psLK0BTwiWITsrQB5jm/JvJx4g8VdkVAuAJ+ASa9xNlY3e2/ LQUIX20s4NerWLZvAQlYnWb90MwrQ9aX7hiM1F/TmOJkpJhCdeacSzdzwnszYSnhy1vqM9XR jYjwfU4VGJ79zrCXF2gLNfI0W5uUSyZSqVB2gP26O8ukBGxRKeRXJfkbUhCOeBoK7w3wfQRD D3iZxP16TAyZvGL25dUWokoJfBGHM1bL8uoznxlCFlKZK+iU0Qh2QTTjSkHrZz8bJlavx8QX 75vRpBbGYTbiWFbjW/Ot+I7uG9cZcKIysoI9O5MPqD66jj2dVESp2w+FJ1VjXeLxN253OUzM 2TffBTpGGmOUBZlsYbhUH+RZIywZZstEPsrRWnju2WwfqN7jXf4ispSun12WZpkG9X4LK0N+ z+9KU8WbFx+3SmiN+Ley5MzKnRdqDF/zkRmGEVWnytSOOub4hxNTs/kqBxpfQgh56BPQ6nSs /foU8tgF6TAmManm0HRhMXXVpoxBt9F6b2gxsVnrV8LlBHO91EQaQnxMxdoTIg4c0kq1M6VE 2YyBFt8PhZGy5uwKi9sjRyWHv1yDvhxbHFCoeJnBSRWmk2v8hJvpm43b1/4eUSvjbk02c4QG OGDt/2wOIRGjwJqfYNmHn7eznrSyT6SerW3JPiu68p377ifW+KYWyEmHkHTHkUt7C147VvVS arsvFEmLgTM61khWIob3gF7eVmX0zrsrRuTEFjlTcr4ZGVTrcZ8PBqyCVKI+4h1UR1PZwg7s quoqpcBtQ9fwa+ijjlKkKMaTwXfY2KkK9qKp6tJOzoQjdsfWrcv8aa8C9ebjzP7OGP9C98+U SI3GYNKYjg8yQYvsfbs65VoEOqARG3yDaPI83dDqAJqg8CrnHHCDf/oG6ntlJtNRpwR76cC2 wkUlHMJOiuNq5FpPcPiQbDM27Ianwq4eA3KJcvooPGdlLNlOB4i+QMeANWxAs4oSFLO2M1eb pvr/0e3Wri87Z5ix1rwB0LHCfXzCJgQhBAqzNOgvhTdXPmvk15hkGKgUN+FVIYBu5ZrCHAgu 3hxc5XXE27mfAKkV0lQlPpB7YOfRm4oDnOpEGVHdXE2McdzLoTjvLCIGZ1aCH3XR8kx2qwQ8 bIkN5DDIPiOzq6NlzcKGD8vF/2UR4yfTQ9+GXzmz7MfeItzhUQCk8D6GBhZtMLU0EvNoT3Sg LKnbRTEUtrV4381EJPBVfaCnaov/SSGQJ+mgYmiKleBtWPCld9G0kByh68XcUB/dNUY6+WP5 k5j5Z3r+9PS0/k1GLilMJ42a/oJxUGnrgB/PdFGN0Xtsi+TpWTCmftCc/NW2as1YprdT5kW4 y1M0+H/TPVOs1l7gTleOShrWEMgUi+qQqFF11SS9/1J7IXH+anOguZGyoUTi8IGP8Etn1x74 vC86PyGKr0y7xoCLB718v6fIIarJ8xPW9SVI2HNKpmkGF8Cv2En+nmHuie9IztV41hBs6t8W VLifqftsnOyz8rdL4nuGTN7o9XV6navPtIfbYk15OAYk7i6BkZxr8RkY+zbsbaVWTV/Qigrn tSf4vlIxJt52fNgn+rhj3sSJmgdtLfPOFXenx+OFtGXj0Z70ro/zLo7DqaWNFJz+XP/z9SBH s+J7g4hSCjKmjE5u617QBECUKAqGenvU2Tw71EwAds+XsICoDkPq83DoD2rxmA7Hzfg6vXHP d/mrO04B32UovVQ8jeC2bAQXdr4j0gI8+EcIH+ud5Al506cBOVJGz8BZmAMM28GPaZk2+uyI zatdb5d284N6DeORYCbLbeTYbmXvJf2FkVpUnkQIeSQ7SUvLA7SgQCK+3IHpLlo0nRtVp43L +kj0ZaPM+A+qe0AXgTsNlbCmVWo/sc66nnEhUKQid4VI3C34QHArarE05baz1Ud9uX+ZQSV0 WUhoIQFo2ph8fD4uPefnDqcvZ3RLwDsCcLX7b6X5NCg3dXJJT+aA7GtE1rQzxmzfbBnNVssB oVf5o4OcBxO7KrcUCrUmr8ux1JgWocYZyyFIfTXAKHfRYbv1cBmiulaGiomEc7u2r31Y18c7 A8emQgGYVeZkYkJneVm0s2XMb7gF3YSBpV0DC4pXyDFFmmD5Y4646IHVsPEV6VqbaufWBbct R3dhOwKj0qVMJNWGvZC53tYfiRruHhTGeHjpptAar4rPvIc1H8dCWp8pZ8W/IRJxSabaZUEF fDikRKZQw8VphjEUW/d3ukSgzjcsgG0Y0fnQf0/mL23JkyFG0e0tAe+/5MVkb/8gBpoEhIaW 50e7Db1UL5DGrNmekVsnT45jXQR0Lo9hQl4dbAsF7QNa8q2nYVcWxW9WAl6ghhxjARHOQLqQ NDNWvpaxY+xT+NnAGYsZeTO8iYecezf0GMTasWvKZCZi/xb/B6mRDTA/+ivcB23B/0eDAS1h aQRB3FnPCUG50n8EP6C8Vqd11f7eccZpWPgVGzZa3yGyuLCfp3miXRSynvhTI8hVtTM84zHb SERY1hexQDI80d5cKsoNY0AvYWd0TOmkxDO3dolLVTjqCDoG2Mi1/2mSKwFYaOT4QrEAziYw Eo7zxtA9l/6NsTzCiDeNfUli1UgTC/IAr4sBmiIygxeiTEXPynW8zg29APjovX1PAK8z5zcy G0PxQDz3Kj4FvMt8BUgMPRB/D+xRk3rz0UdgKW0rCjEW7o+RQFtHFbkOiAzLHnV/xF+yhwBS VEdYRruz0UKvPSt1BOSVwpld/0BG7KDa74OFnn2fY2GignFn3ro9BaZ8oyLxMI+AArKokHIk xbKCm5U8HWlb5oEbsN2OPSiqvLgKS1P21haLi8a5G5KZwNmN2wzUagkVaOOXpysE66HHMNno Ve65hoKb+L8CilztfVdG+OfI0HIU3ozK7yMCR/+g/uMIsOTuKV4tyjhLi6sCx96KLJ/ku5a/ 3Nlt1FaJC11QzxzLLDdWZm+1yyI0NdSElgMUQ1jSBC73kyBBTZ/7f5YVmaG1QUD5vD4LGL6y CI0SKhxswQibjo47//AP1Ryf3PcoWkWmXvEq0wQbbx+QPLZmBeAywSUIihitCiMJsDMcsCTQ /BX45eXVJuWGtPAtNrc8/5Tje5XrhRJzfos0uTB8oTdWJPXGpr3Q8DBldcf9rNyQxfIQqkM1 WhQDJYd+pimQDndLxocYq5zeWiLH9GYvLta/Qq2GHY6gdU0hiicOtSclWhSXCiktZFqmrC14 T9X0L1SBocNV9EyRpKIH//Gu1ASsQ54QEQ4F0wapzGCypaRY+O5zH+DRGLj86xEsWws3NVHM 5r1WwCFebbcO+aakYPr6kq7bZvl1j9vdbLl12BB8UmRcARhemhDjmAqfIwnLcqMIFcxbrNgk 2hfWnmpUWF6rspmNqYvMrB8A9+fLyUEyBzmOrCrkN+FbRZgr4c4N2Z4l7sQgEJiMce1IzRbx TzHs/6Lio0YJbxf54ifu/6YMPPQetUceS3s7x5dgVgJfM89w69KXs/Ns3989TyTp7nt1sPt0 xUFoaw29DNU2zn+yHx7HBb4LGYxFSAvkAGFM2tRfaxzVLwlmc39vOR+/iGUpxtA3lsdyEJHB zwkiUVjiCF1dVm98jOH773XcQUuzQdKRvc/30nzG6loH+PwOdTGmXV1wDI3BN/GHlNk+RqL3 sB8zOMNjdWVsg9vtSr12e6CbS3j9pH988TQ9GqlKdqObJpi8mpLOkpIzZvOwYcqalOM37fTP OoO51XI9qc81riopA2YcSQR9xcRy14tEpq3mAo6pF1jgsqz/PEZQkoAg21dIyfKYPUoxISRo fpFSVXSNrRmP32tQoa/Ds86ptVj8dc/uvGDFcGtEgd0ydXt4hvSfwedi7HTMYK0hnzKzHPsb 8jZrNnjHdw4PF0TmPbAzonNAqwfg6YAyDJHpAcZ+cAgdgt0zp9SkAnTC56oxuRy1LLBAe4ah XZpdywDeFpXCjoDJ98Glnh6aEqf3pm1N8yRjCrnjFHKyWrU5aTqr6pOpJIA8hyUSMAQwqz6K UefmieZoFa89+TPDNPIDn3RgrnHPfBSaS6mqx8t9aRl4HHI/zWMOod8uYoPAVFlFw/nsY/Bl gpUo1ZayiXnxMfdDRDDLI2/zg583kEn+sgxLcpKyUqiDUwkLTKwjZENA3/XQN9J1g0R42D6p Dm+aNTeK1C9TRhWK9NPjfv7FFZRvbDyMwLK0NDQKlSm9fiZzLbyaOblGOFOfjia4wRAmnyJC eRx5dyL5/QPE89ldlpBMkjMcwO3r3Z9P3CvVhH108YTi22rQXeMzwr6rLTdER4IdXFnqlOT6 2E1wdU16g6io0JKNCrfzarBN2viArobF4XO819B4dZIx49TcYmFafhazXc1haraLD+67CDrF bYwcEvL5IVxFrUCRLKaMS2rpBlE2JLZh7ZL6LQQfHaNAzStxKVYEybwTsGFgHPK/G7EgswbY MSX+SBgQnYZRz2hOuZhKNKJGQosnW1iGvUXVnQvgszL8PVN1EqJuhf3RTthsjT7cI1s/3k2G /CwUZQB2cOAnejwxUuGP6F9jSTJZMuxa65aukBvUzOo1VSCoBAT2vEj4HIplUzjs/bpceYj2 4Ac7qmtuPjVJj+lKCZX730R7hCTAz/OUtbVC4GQufXr2mquPgXycGW1+AVT2tThfByU2tVaI rb2vS5DegNpn988dYP4eQvpY476zaQ2Oq2vgw9KEAT0fo8i3hTzhBBZlFpcGz2NJgnlSVxAR fKqw7X9cRXnod44BrwCjY6s08oxyEfbLeRixhVxSh7ZoEQm7hfiQKWnzXQI5HEbzTb5jcsjE QXfHC2Kay9oA3q2a6byurTdwdfQlBskE09pUk/9AZ04kapAd+s3ApXXvP9z/TiI1PI/i5n+h 2yhV0wI640DsmTDJIcZ+T7+8+pikUj7Hxn//UkxhDOUhaQb3i6c0jbL+Ns51xxYCrsfKO2Pf PMCaT+wC8p8BEXoIdW91b3gOHn4MjMF4RXW1QpcmwoNWm8lPX1FGbZkjjZ0zGKmZ0IwjnOlL EiEmAHjtGMHgTyD8EKfKrwtAOCMOqhAIwYlmHBff+3UmSnwOLAO4nPL3V2UbY4X6m/v0JUkn XohbWet/HYWabJZ8a6zslgpEAvc7+U4RNXPoavYI4J843NWqoU3DYDqOHT0ikRxkhCtW4sZz kjMDa9sHvOLTRsqYSlGXpA+LjhMGGNDSe+QpzrbnQlnQqBjQxQCseskh/bTg1jNLqQ0dKnqS 3TWyHeJ0S48AAAEAAgAgIBAAAQAEAOgCAAABACgAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAA AAAAAAAAAAAAAAAAAADM//8AaFdYAAAAAACAgIAA////AMDAwAD/AAAAAP//AL8AAAAAAP8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIiESIiIiIiIiIiIiIiIiIiIhNVVVVVVVVVVVVVUl IiIiI0REREREREREREREUlIiIiNERERERERVVERFVVJSIiIjRIiIiERJmUREmZRSUiIiI0RE RERERJVERElUUlIiIiNEiIiIiERJVVVZVFJSIiIjRERERERERJmZmVRSUiIiI0SIiIiIiERJ VElUUlIiIiNERERERERERJVJVFJSIiIjRIiIiIiIiERJWVRSUiIiI0RERERERERERJlUUlIi IiNEiIiIiIiIiERJRFJSIiIjRERERERERERERERSUiIiI0SIiIiIiIiIiIhEUlIiIiNERERE RERERERERFJSIiIjRIiIiIiIiIiIiERSUiIiI0REREREREREREREUlIiIiNEIiIiIkSIiIiI RFJSIiIjRDmSREJERERERERSUiIiI0QyIiIiRIiIiIhEUlIiIiNENEJ3ckRERERERFJSIiIj RDIid3JEiIiIiERSUiIiI0Q0QndyREREREREUlIiIiNENEJmYkRERERERFJSIiIjRDRCZmJE RERERERSUiIiI0QzMiIiREREREREUlIiIiNERERERERERERERFJSIiIjQkQkQkQkQkQkQkQy UiIiI0JEJEJEJEJEJEJEMlIiIiIkM0M0M0M0M0M0M0MiIiIiIiIiIiIiIiIiIiIiIiLgAAAP 4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AA AAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH 4AAAB+AAAAf4AAAP/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBL AQIUAAoAAAAAABFSejHXfqbAAHwAAAB8AABUAAAAAAAAAAAAIAAAAAAAAABkZXRhaWxzLnR4 dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC5waWZQSwUGAAAAAAEAAQCCAAAAcnwAAAAA ------=_NextPart_000_0016----=_NextPart_000_0016-- -- to 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, 25 Nov 2004 16:17:24 +0000 Message-Id: <6.1.2.0.0.20041125111320.03baeec0@localhost> Date: Thu, 25 Nov 2004 11:16:41 -0500 To: From: "Joel M. Halpern" Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable These codes are being normatively referenced in an IETF standard. It is very unusual for the IETF to reference in such a fashion a document=20 that is not publicly and freely available. The IETF is not usually=20 interested in defining a name space that can only be referenced and=20 understood by a proprietary community. (Being assigned by a specific=20 community is fine, and in fact frequently necessary for name spaces.) This leads to several obvious questions: 1) Is there actually a need for any name spaces other than realm? All CDMA= =20 and GSM operators have dedicated names suitable for use as REALMS. 2) If it is important to use other name spaces, then an explanation of why= =20 it is needed ought to be included. And the community that wants their name= =20 space useable ought to make their registry publicly readable. 3) At the very least, it is necessary to explicitly and normatively=20 reference the GSM Association Permanent Reference Document. Yours, Joel M. Halpern At 01:37 AM 11/25/2004, jouni.korhonen@teliasonera.com wrote: > > I did some further digging... there *is* a TADIG naming system > > for all operators, see: > > > > http://www.gsmworld.com/about/structure/tadig.shtml > > > > Its defined by GSMA. But I'm still searching for a good reference > > that could be put to the document, however. > >The TADIG code (for GSM: prefix) mentioned in the current draft >is defined in GSM Association Permanent Reference Document TD.13. >(GSMA PRD TD.13). > >"The TADIG Code shall consist of 2 fields, with a total length > of 5 characters consisting of a 3-character country code and a > 2-character operator (or company) ID." > >The code is available for anyone for 100=A3 yearly fee. -- to 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, 25 Nov 2004 06:38:19 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Date: Thu, 25 Nov 2004 08:37:46 +0200 Message-ID: <07B14A720C46C344AC96AAA64F5D6A313BEC8D@FITMS201MB.tcad.telia.se> Thread-Topic: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Thread-Index: AcTSYk/TTnBetKHlQ9GUbRliUfW0YQAVZSTA From: To: , Cc: , Hi, Comments inline. /Jouni > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Jari Arkko > Sent: 24. marraskuuta 2004 22:11 > To: Joel M. Halpern > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: Re: draft-ietf-geopriv-radius-lo-01.txt - CDMA=20 > operator-name prefix >=20 > Jari Arkko wrote: >=20 > > The GSM prefix appears to have the same issue. I know > > there are GSM operator codes (MNCs) but the document > > does not refer to them, but some notion of a text based > > identity. I'm not sure if the GSMA is keeping a registry > > of the text based identities as well. In any case a > > reference to the registry/allocation responsible would > > be needed. >=20 > I did some further digging... there *is* a TADIG naming system > for all operators, see: >=20 > http://www.gsmworld.com/about/structure/tadig.shtml >=20 > Its defined by GSMA. But I'm still searching for a good reference > that could be put to the document, however. The TADIG code (for GSM: prefix) mentioned in the current draft is defined in GSM Association Permanent Reference Document TD.13. (GSMA PRD TD.13).=20 "The TADIG Code shall consist of 2 fields, with a total length of 5 characters consisting of a 3-character country code and a 2-character operator (or company) ID." The code is available for anyone for 100=A3 yearly fee. >=20 > --Jari >=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: Wed, 24 Nov 2004 21:55:18 +0000 Message-ID: From: Avi Lior To: 'Jari Arkko' , Miguel Garcia Cc: "Beck01, Wolfgang" , AAA mailing list , radiusext@ops.ietf.org Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 16:54:44 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, Again I think that only option b is the valid one. Unless I am missing something, I think a Proxy must be able to identify the the Proxy-Authorization that is associated with it. From RFC 2616: "When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request." Therefore you would think that a particular proxy would extract the credentials from its headers and those would be the only ones that are sent to the AAA infrastructure. And this also implies that the Proxy has a way to identify the Proxy-Authroization header. Is this right? > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, November 24, 2004 1:58 PM > To: Miguel Garcia > Cc: Beck01, Wolfgang; AAA mailing list; radiusext@ops.ietf.org > Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application > > > Miguel Garcia wrote: > > > In HTTP there is typically a single Proxy-Aut* header, due to that > > typically there is a single proxy sitting between the > client and the > > server. > > > > In SIP things get a bit more complicated, since it is common that a > > SIP > > request traverses several proxies, where theoretically each > proxy could > > demand credentials. It is also valid that each SIP proxy requests > > credentials for the same or different realms than other SIP proxies. > > > > In other words, a SIP proxy can receive a SIP request that contain > > several Proxy-Authorization header fieldss. Each header field will > > contain the credentials for a particular realm. > > > > So let's assume that one of this proxies receives a request that > > contains several Proxy-Authorization headers. Which one > should the SIP > > proxy put into the Radius/Diameter message and send it to the > > Radius/Diameter server? > > Thanks for the explanation. The situation is clearer to me > now. > > > a) Put blindly everything, I mean, all the Proxy-Authorization > > headers. > > Repeat attributes (Radius will give us a problem since > attributes are > > not grouped). > > I see the problem. > > > b) Extract the credentials that are of interested (according to the > > realm) of the SIP server and RADIUS/Diameter server. This > requires to > > configure the SIP server with the realm it is serving, but > it has some > > benefits: first the Radius/Diameter message contains one set of > > credentials (no poblems with Radius); second, it allows the > > Radius/Diameter server to be authenticating several realms, > so there is > > no uncertainity because there is only one set of credentials in the > > message. > > > > Therefore, we proposed to clarify all this issue and > describe the need > > to configure the SIP server with the realm it is serving. > This allows > > the server to select the appropriate credentials. > > This sounds reasonable, and my original worry turned out > to be a non-issue. (I worried that this might somehow > limit what the user's realm might be. But the client's > header includes both the username, which might of the > form jari@domain, and the challenging proxy's realm. > Only the latter is used in matching what gets sent to > the AAA server. In conclusion I could be jari@domain1 > when traversing through three proxies that challenge > me using realms domain2, domain3, and domain4, and > a single AAA server could handle all of this.) > > --Jari > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 20:12:38 +0000 Message-ID: <41A4EAB6.1080202@piuha.net> Date: Wed, 24 Nov 2004 22:10:30 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Joel M. Halpern" Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jari Arkko wrote: > The GSM prefix appears to have the same issue. I know > there are GSM operator codes (MNCs) but the document > does not refer to them, but some notion of a text based > identity. I'm not sure if the GSMA is keeping a registry > of the text based identities as well. In any case a > reference to the registry/allocation responsible would > be needed. I did some further digging... there *is* a TADIG naming system for all operators, see: http://www.gsmworld.com/about/structure/tadig.shtml Its defined by GSMA. But I'm still searching for a good reference that could be put to the document, however. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 19:37:25 +0000 Message-ID: <41A4E27A.7010504@piuha.net> Date: Wed, 24 Nov 2004 21:35:22 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Joel M. Halpern" Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: draft-ietf-geopriv-radius-lo-01.txt - registry of operator name prefixes? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Joel M. Halpern wrote: > Description of issue: operator name prefix space must be properly defined > Submitter name: Joel M. Halpern > Submitter email address: joel@stevecrocker.com > Date first submitted: 18-November-2004 > Reference: > Document: draft-ietf-geopriv-radius-lo-01.txt > Comment type: T > Priority: 1 > Section: 5.1 & 11 > Rationale/Explanation of issue: Operator-prefixes are defined. > Creation rules and a registry must be defined > Length description of problem: > Section 5.1 states that only the listed operator name prefixes may > be used. It then states that other operator name prefixes may come into > existence. Thus, it is creating a registry, presumably with some > expectation on rules for how prefixes get into that registry. > However, the IANA considerations section (11) does not even mention > the three allocated values. No section describes how new values may be > created, or what rules such new values must abide by. > > Requested change: > The document should properly define the registry it is creating. Agreed. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 19:36:55 +0000 Message-ID: <41A4E24D.4070401@piuha.net> Date: Wed, 24 Nov 2004 21:34:37 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Joel M. Halpern" Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Joel M. Halpern wrote: > Description of issue: Operator-Name prefix defined without usage > Submitter name: Joel M. Halpern > Submitter email address: joel@stevecrocker.com > Date first submitted: 18-November-2004 > Reference: > Document: draft-ietf-geopriv-radius-lo-01.txt > Comment type: T > Priority: 2 > Section: 5.1 > Rationale/Explanation of issue: The operator prefix CDMA is defined, > but never user > Length description of problem: > The CDMA operator-name prefix is listed as a valid prefix in section > 5.1. However, no definition is included as to what names may use such a > prefix or how they should use it. > > Requested change: > Either describe who allocates "CDMA" operator names, and how such > names are allocated, ore remove the name The GSM prefix appears to have the same issue. I know there are GSM operator codes (MNCs) but the document does not refer to them, but some notion of a text based identity. I'm not sure if the GSMA is keeping a registry of the text based identities as well. In any case a reference to the registry/allocation responsible would be needed. The REALM prefix is the only one that does not have an issue, although I'm not sure the text for that is 100% accurate either. How about REALM can be used by any domain name acquired from IANA. => The right to use of REALM with a specific name is obtained coincident with acquiring the rights to use the particular Fully Qualified Domain Name (FQDN). Using a REALM name without ownership of the supplied FQDN creates the possibility of conflict and is therefore discouraged. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 18:30:32 +0000 Message-Id: <5.2.0.9.2.20041124094902.0171d850@qcmail1.qualcomm.com> Date: Wed, 24 Nov 2004 10:09:45 -0800 To: radiusext@ops.ietf.org From: Jun Wang Subject: Sterman Issue#8 and Some Other Issues Cc: ac Mahendran Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi folks, The following comments and questions are related to issue #8 and some other new issues. 1) The title of Issue #8 indicates that "Rspauth generation not possible if RADIUS server chooses nonces and qop=auth-int" This issue exists regardless of whether the RADIUS Server or Client chooses the nonces. We think the current approach proposed by Wolfgang can apply for both cases. 2) Section 2.19 (Digest-HA1 attribute) first paragraph states: "If this attribute is present, the RADIUS server did not accept the nonce value." This statement seems incorrect. It should be replaced with: "This attribute holds H(A1) as described in RFC2617 to be used for constructing the Authentication-Info header by the RADIUS client." 3) There several places (like sections 2.19, 3.1, and 3.2) which state something like: ".... MUST NOT...., unless....". We think it will be better to reword the sentences along the lines provided in the examples below. a) Section 2.19 under string definition, states the following: "If the 'algorithm' directive's value is 'MD5' or 'AKAv1-MD5', the Digest-HA1 attribute MUST NOT be sent by the RADIUS server or processed by the RADIUS client, unless the authenticity and integrity of the Access-Accept message was secured by cryptographic or equivalently secure means." We can replace the above text to: If the 'algorithm' directive's value is 'MD5' or 'AKAv1-MD5', and the authenticity and integrity of the Access-Accept message was not secured by cryptographic or equivalent secure means, the Digest-HA1 attribute MUST NOT be sent by the RADIUS server or processed by the RADIUS client. b) Text in Sections 3.1 and 3.2 states: "If the Digest-Qop attribute's value is 'auth-int' and the Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5', the RADIUS client MUST NOT use the Digest-HA1 attribute, unless it knows for sure that the Access-Accept message was encrypted or otherwise protected against eavesdropping". We can replace the above text to: The RADIUS client MUST NOT use the Digest-HA1 attribute if all of the following conditions are true: - The Digest-Qop attribute's value is 'auth-int'; - The Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5'; and - The authenticity and integrity of the Access-Accept message was not secured by cryptographic or other equivalent secure means. 4) Section 2.4 (Digest-Response-Auth attribute) states: "This attribute is only used in Access-Accept messages if the RADIUS server is configured to choose nonces." Why is this attribute not applicable when RADIUS client chooses nonces? It seems that this attribute is needed as long as the mutual authentication is performed (see section 3.2.3 of RFC 2617.) 5) This comment is applicable to all attributes in Section 2. All attribute definitions should clearly specify in which RADIUS messages (Access Request, Access Accept, Access-Challenge, Access-Reject) these are valid. For example, section 2.9 only mentions Access Accept message. However, the Digest-Algorithm attribute can also be present in Access-Challenge message. 6) The definition of Digest-Stale attribute in Section 2.18 is not clear. It should be clarified as follows: 2.18 Digest-Stale attribute This attribute indicates whether the RADIUS server accepted the nonce value received from the RADIUS client. Type DIG-STALE Length 3 String The string consists of a single character. If the nonce presented by the RADIUS client was stale, the character is '1' and is '0' otherwise. If the RADIUS sever does not accept the nonce received in Access Request message but authentication was successful, the RADIUS server MUST include this attribute in Access Accept message and set it to '1'; the RADIUS server MUST also set the 'next-nonce' attribute in the Access-Accept message to the valid nonce-value. 7) In Section 3.1, the text on Digest-Stale attribute is not clear. It should be clarified as follows: If the RADIUS client receives an Access-Accept message from the RADIUS Server with the Digest-Stale attribute set to '1', the RADIUS client sends an error (401 or 407) response to the HTTP-style client containing WWW-/Proxy-Authenticate header with the stale flag set to "TRUE and the nonce value set to the 'next-nonce' value received in the Access-Accept message. 8) The following RADIUS Server procedure should be added to section 3.2: If the RADIUS sever does not accept the nonce received in Access Request message but authentication was successful, the RADIUS server MUST include this attribute in Access Accept message and set it to '1'; the RADIUS server MUST also set the 'next-nonce' attribute in the Access-Accept message to the valid nonce-value. 9) More general question related to comments 6), 7) & 8) above. The current text assumes that if the nonce is stale and authentication is successful, the RADIUS server will indicate it to the RADIUS client using Access-Accept message. Shouldn't this be indicated in Access-Challenge message? So, Access-Accept messages should be sent only when nonce is valid and authentication is successful. For any other purpose, Access-Challenge or Access-Reject should be used. Thanks, Jun -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 16:23:41 +0000 Message-ID: From: Avi Lior To: 'Jari Arkko' , radiusext@ops.ietf.org, "'Miguel.An.Garcia@nokia.com'" , "'BeckW@t-systems.com'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 11:23:32 -0500 MIME-Version: 1.0 Content-Type: text/plain Miguel, Wolfgang and Jari, I am trying to get a deeper understanding here. But it seems to me that in Scenario 1 where the RADIUS Client is generating the nonces, the client really needs to be the one that determines the staleness of the nonces and not the AAA. Therefore, the client will not even invoke the AAA server when the nonce is stale; and the AAA will just assume that all nonces are valid. > > 8- In the Radius document, scenario 1, we have a question. > We suspect > > that this scenario does not work if the Radius client generates a > > nextnonce. The reason is that in the following authentication, when > > the nextnonce becomes a nonce, the Radius server will not recognize > > the nonce as locally generated (it was generated by the Radius > > client), and will reject the request with a "state=true". RFC 2617 > > seems to describe the case: > > > > If the > > nextnonce field is present the client SHOULD use it when > constructing > > the Authorization header for its next request. Failure > of the client > > to do so may result in a request to re-authenticate from > the server > > with the "stale=TRUE". > > > > Does anyone have any comment? Can anyone confirm that the > operation in > > Digest is as we indicate? We will add some text indicating the > > limitations of Scenario 1. > > In looking at this, I have the same question as you. So no > help from me, sorry. > > > 9- The Radius draft, in section 2.15, indicates: > > > > RADIUS > > servers that do not implement a parameter contained in a > > Digest-Auth-Param attribute MUST respond with an > Access-Reject > > message. RADIUS clients that do not implement a parameter > > contained in a Digest-Auth-Param attribute MUST reject the > > original HTTP-style request. > > > > The problem is that the text seems to go against RFC 2617 that says: > > > > auth-param > > This directive allows for future extensions. Any unrecognized > > directive MUST be ignored. > > > > The proposal is to remove the above text from the RADIUS draft. > > Yes, this is correct. > > > 10- Similar contradictory text was found in Section 2.16 of > the RADIUS > > draft, that says: > > > > RADIUS servers that do > > not implement AKA Digest MUST response with an Access Reject > > message. > > > > We propose to remove the above text. The motivation is that the > > algorithm already conveys the AKA (AKA extends the algorithm to be > > AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the > algorithm, so the > > situation currently described, where the client may include an auts > > attribute, is just an error case, where the client made a > mistake and > > included AUTS when not doing AKA. In case the Radius server > does not > > implement AKA authentication, it will safely ignore this AVP. > > Right. > > > 11- We noticed that most of the HTTP Digest directives > contain just a > > single token. However, the "qop" directive may contain a > comma-separated > > collection of tokens. For instance, qop="auth,auth-int". > The question is > > how do encode these tokens in the Digest-Qop attribute. The > options are: > > > > a) Treat the whole thing as one token and put it into the attribute > > value. > > b) Each token is an attribute, thus, there might be > multiple Digest-Qop > > attributes in a particular Radius/Diameter message. > > > > We think that option b) is cleaner. Particularly it will be > easier for > > the Diameter/Radius client to encode different values in different > > attributes. > > I think option a) is cleaner, although I don't care enough to > think it should be a showstopper. But here's my reasoning: > avoid unnecessary mapping work that the client needs to do; > handle everything as much as possible by taking all text from > the SIP syntax and putting it blindly into an AVP... > > --Jari > > > -- > to 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: Wed, 24 Nov 2004 16:15:38 +0000 Message-ID: From: Avi Lior To: 'Miguel Garcia' , Jari Arkko Cc: "Beck01, Wolfgang" , AAA mailing list , radiusext@ops.ietf.org Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 11:15:15 -0500 MIME-Version: 1.0 Content-Type: text/plain Option b) is cleaner because it requires less parsing work by AAA server. Regarding the following comment: > handle everything > as much as > > possible by taking all text from the SIP syntax and putting > it blindly > > into an AVP... Wolfgang's original document did that for all the attributes (using subtypes) which could have been handled by both RADIUS and Diameter. Lets not go there again. > > > >> 11- We noticed that most of the HTTP Digest directives > contain just a > >> single token. However, the "qop" directive may contain a > >> comma-separated collection of tokens. For instance, > >> qop="auth,auth-int". The question is how do encode these > tokens in the > >> Digest-Qop attribute. The options are: > >> > >> a) Treat the whole thing as one token and put it into the attribute > >> value. > >> b) Each token is an attribute, thus, there might be multiple > >> Digest-Qop attributes in a particular Radius/Diameter message. > >> > >> We think that option b) is cleaner. Particularly it will be easier > >> for > >> the Diameter/Radius client to encode different values in different > >> attributes. > > > > > > I think option a) is cleaner, although I don't care enough > to think it > > should be a showstopper. But here's my reasoning: avoid unnecessary > > mapping work that the client needs to do; handle everything > as much as > > possible by taking all text from the SIP syntax and putting > it blindly > > into an AVP... > > > > I don't care either. I just thought we shouldn't put too much work to > the Diameter/Radius server about how to encode Digest directives. > Approach a requires the Diameter/Radius server to be able to encode > "auth", "aut-int", "auth,auth-int", and use it appropriately. If the > number of tokens is just two, then any approach is feasible. > > - Miguel > > > > --Jari > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 15:26:20 +0000 Message-ID: From: Avi Lior To: 'Jari Arkko' , Miguel Garcia , "Beck01, Wolfgang" Cc: AAA mailing list , radiusext@ops.ietf.org Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Wed, 24 Nov 2004 10:26:01 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Miquel, Jarri, > > 3- Radius does not define UTF8String data types, so all these > > attributes > > will remain as String, but the Radius draft will indicate > that contain a > > UTF8String verbally (this is required by HTTP and SIP). Just one point now. RADIUS "Text" type attributes are UTF-8 compliant. I just want to make sure that the definition of Text and UTF8String are the same. And they appear to be. >From RFC 2865: text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. >From RFC 3588: This is a human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 [UFT8] transformation format described in RFC 2279. So where applicable the attributes in Sterman should be set to 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 14:13:14 +0000 Message-ID: <41A4967D.5000102@piuha.net> Date: Wed, 24 Nov 2004 16:11:09 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: "'radiusext@ops.ietf.org'" , Miguel Garcia Subject: Re: issues in 11 and 12 in the sterman draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit There's one more additional thing. Is Section 4 the final result or will it be modified based on your agreement with Miguel? The table below still has some mapping for the translation agent. I think we should be able to do it completely without any AVP mapping. But I don't dig into this deeper if you say Section 4 is still being worked on. > +-------------------------+-----------------------------------------+ > | RADIUS | Diameter | > +-------------------------+-----------------------------------------+ > | Digest-Realm | Digest-Realm | > | | | > | Digest-Nonce | Digest-Nonce | > | | | > | Digest-URI | Digest-URI | > | | | > | Digest-Domain | Digest-Domain | > | | | > | Digest-QoP | Digest-Qop | > | | | > | Digest-Algorithm | Digest-Algorithm | > | | | > | Digest-CNonce | Digest-Cnonce | > | | | > | Digest-Nonce-Count | Digest-Nonce-Count | > | | | > | Digest-Method | SIP-Method AVP | > | | | > | Digest-Username | Digest-Username AVP | > | | | > | Digest-Entity-Body-Hash | SIP-Entity-Body-Hash AVP | > | | | > | Digest-Response | SIP-Authorization Digest-Response | > | | | > | Digest-Response-Auth | SIP-Authentication-Info Digest-Response | > | | | > | Digest-Opaque | Digest-Opaque AVP | > | | | > | Digest-Auth-Param | Digest-Auth-Param | > | | | > | Digest-AKA-Auts | Digest-AKA-Auts | > | | | > | Digest-Stale | Digest-Stale AVP | > +-------------------------+-----------------------------------------+ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 14:10:55 +0000 Message-ID: <41A495F1.6070103@piuha.net> Date: Wed, 24 Nov 2004 16:08:49 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Beck01, Wolfgang" , "'radiusext@ops.ietf.org'" Subject: radius-sip nits Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit radius-sip nits Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: Nov 24th, 2004 Reference: Document: radius-sip Comment type: E Priority: 2 Section: Multiple Rationale/Explanation of issue: > proprietary (ie costly) extensions. Operators are therefore s/(ie costly)// > 2.16 Digest-AKA-Auts attribute > > This attribute holds the auts parameter that is used in the AKA > Digest ([RFC3310]) calculation. > > ... > > 11.2 Informative References > > ... > > [RFC3310] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer > Protocol (HTTP) Digest Authentication Using Authentication > and Key Agreement (AKA)", RFC 3310, September 2002. This looks more like a normative reference to me. > Digest-Realm (DIG-REALM) = "examplecom" Is the realm style in digest this, or is there a dot missing? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 14:08:35 +0000 Message-ID: <41A49562.6010709@piuha.net> Date: Wed, 24 Nov 2004 16:06:26 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Beck01, Wolfgang" , "'radiusext@ops.ietf.org'" Subject: issues in 11 and 12 in the sterman draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am happy with the resolutions of everything in these issues, except for two parts: (1) My understanding is that there's still one version of at least of the AAA draft and maybe of both drafts coming due to the attribute merge. This was part of issue 11, so I'd like to check the results when the final text is available. (2) I think we didn't end the discussion on: Jari wrote: > The choice between the server and client generated > nonces: is there some guidance on how the client knows > which one to do? if it believes it may have a user that > does Digest AKA then it should do use the server generated > scheme? But how would it know this in a roaming case? Wolfgang wrote: > If you are expecting AKA users, you have to use server > generated nonces. Jari wrote: > I guess my question was how do you know you are expecting > AKA users. Is there a fallback in case we were NOT expecting > them but one showed up because our roaming partner started > supporting AKA yesterday? (Or am I missing an e-mail?) I also looked through the draft but did not spot text that deals with this. Can we provide a server-generated error that says "please try again without generating your own nonce"? Or is it too late if some message has already been sent to the user at this point? --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Nov 2004 13:39:52 +0000 Message-ID: <41A48E92.5030106@piuha.net> Date: Wed, 24 Nov 2004 15:37:22 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > I am deliberately cross posting to AAA and Radius-ext because I believe > this topic is of interest for both lists. > > Yesterday Wolfgang and me met for a few hours and set the goal of > reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest > drafts. These are the drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-04.txt > > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt > > These are the main points we discuss. If you have any comments, speak up > now, otherwise we will do the proposed changes in the relevant drafts: > > 1- We agreed to modify the Diameter SIP application so that it imports > the Digest-* AVP from the corresponding RADIUS attributes address space. > This came out of a comment from Jari Arkko, and I think it is important > to avoid duplication of AVP/attributes. > > As a side effect of the above, the SIP-Authentication-Context will > disappear in Diameter SIP app. This was a grouped AVP that only > contained a Digest-Entity-Body-Hash AVP. The latter will remain (in the > RADIUS draft). Great! > 2- We noticed a divergence in the Digest-Expected-Response AVP in > Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 > attribute. The difference: Digest-HA1 contains H(A1), which is computed > at the Radius server and sent to the Radius client, and it is used to > compute the expected response. In Diameter, the expected response is > computed at the Diameter server and sent to the client. This assumes a > secure connection to avoid eavesdropping, which is not a problem for > Diameter that mandates IPsec or TLS. I think Diameter can go for the > Radius approach for compatibility reasons. > > Proposal: Diameter will remove Digest-Expected-Response AVP and will > import Digest-HA1 from Radius. Ok. > 3- Radius does not define UTF8String data types, so all these attributes > will remain as String, but the Radius draft will indicate that contain a > UTF8String verbally (this is required by HTTP and SIP). Hm, I guess this is OK. > 4- Currently here is a divergence on the definition of Digest-Stale > attribute: Diameter uses "true" and "false" (as per RFC2617), Radius > uses 1 and 0. We agreed to use "true" and "false" to avoid stupid > transcodings. This is much better. Good. > 5- Diameter indicates that the Digest-* AVPs contain the quotes from/to > the Digest directive, Radius assumes (although does not indicate) no > quotes. We agreed that the Digest-* attributes do not need to include > the quotes from HTTP Digest parameters. So, there will be an explicit > indication that quotes are not part of the attribute value. This is better too. > 6- We run into a problem when multiple SIP proxies are authenticating > the user, because at some point in time the SIP request may contain > several Proxy-Authorization headers. The key here is the realm, it > will be always different. If different Diameter/Radius servers are > serving different realms, there is not problem. But, if a common > Diameter/Radius server is serving different realms, then the server is > not able to determine which credentials should be evaluated. > > We propose that the Diameter/Radius client MUST send only one set of > credentials at a time, those belonging to the served realm. This > requires to configure the Diameter/Radius client with the realm it is > serving. We will include some text indicating this case. I fail to see the problem, most likely due to the insufficient understanding of the protocol details on my part. But will your solution lead to some problem if there's roaming involved? > 7- Some of the attributes (e.g, Digest-Response and > Digest-Response-Auth) had an artificial limit of 32 octets in the > value. While this value is correct for MD5 hashes, if in the future > other hashes are added to HTTP Digest, will run into > trouble. Proposal: don't restrict the length of a value. Right. > 8- In the Radius document, scenario 1, we have a question. We suspect > that this scenario does not work if the Radius client generates a > nextnonce. The reason is that in the following authentication, when the > nextnonce becomes a nonce, the Radius server will not recognize the > nonce as locally generated (it was generated by the Radius client), and > will reject the request with a "state=true". RFC 2617 seems to describe > the case: > > If the > nextnonce field is present the client SHOULD use it when constructing > the Authorization header for its next request. Failure of the client > to do so may result in a request to re-authenticate from the server > with the "stale=TRUE". > > Does anyone have any comment? Can anyone confirm that the operation in > Digest is as we indicate? We will add some text indicating the > limitations of Scenario 1. In looking at this, I have the same question as you. So no help from me, sorry. > 9- The Radius draft, in section 2.15, indicates: > > RADIUS > servers that do not implement a parameter contained in a > Digest-Auth-Param attribute MUST respond with an Access-Reject > message. RADIUS clients that do not implement a parameter > contained in a Digest-Auth-Param attribute MUST reject the > original HTTP-style request. > > The problem is that the text seems to go against RFC 2617 that says: > > auth-param > This directive allows for future extensions. Any unrecognized > directive MUST be ignored. > > The proposal is to remove the above text from the RADIUS draft. Yes, this is correct. > 10- Similar contradictory text was found in Section 2.16 of the RADIUS > draft, that says: > > RADIUS servers that do > not implement AKA Digest MUST response with an Access Reject > message. > > We propose to remove the above text. The motivation is that the > algorithm already conveys the AKA (AKA extends the algorithm to be > AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the algorithm, so the > situation currently described, where the client may include an auts > attribute, is just an error case, where the client made a mistake and > included AUTS when not doing AKA. In case the Radius server does not > implement AKA authentication, it will safely ignore this AVP. Right. > 11- We noticed that most of the HTTP Digest directives contain just a > single token. However, the "qop" directive may contain a comma-separated > collection of tokens. For instance, qop="auth,auth-int". The question is > how do encode these tokens in the Digest-Qop attribute. The options are: > > a) Treat the whole thing as one token and put it into the attribute value. > b) Each token is an attribute, thus, there might be multiple Digest-Qop > attributes in a particular Radius/Diameter message. > > We think that option b) is cleaner. Particularly it will be easier for > the Diameter/Radius client to encode different values in different > attributes. I think option a) is cleaner, although I don't care enough to think it should be a showstopper. But here's my reasoning: avoid unnecessary mapping work that the client needs to do; handle everything as much as possible by taking all text from the SIP syntax and putting it blindly into an AVP... --Jari -- to 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, 22 Nov 2004 22:51:16 +0000 Message-ID: From: Avi Lior To: "'gwz@cisco.com'" , Avi Lior , jari.arkko@piuha.net Cc: radiusext@ops.ietf.org Subject: RE: [Sterman Issue 7] Message Authenticator: Options Date: Mon, 22 Nov 2004 17:50:45 -0500 MIME-Version: 1.0 Content-Type: text/plain Glen, I hope the answer is no. That is, when there are security issues we should fix tehm - charter or not charter. So far however, Message-Authenticator has not been shown to be compromized. And apparently there is still some question on whether or not the ease of generating MD5 collisions is a parctical RADIUS attack. -- to 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, 22 Nov 2004 22:43:39 +0000 Message-Id: <200411222243.iAMMhRAC026532@sj-core-2.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Avi Lior'" , Cc: Subject: RE: [Sterman Issue 7] Message Authenticator: Options Date: Mon, 22 Nov 2004 14:43:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit thread-index: AcTQ4NeAuF7MvZdWSGuJFKPFAEV4jgAAmH9A Avi Lior <> wrote: ... >> Also, should RADIUS Digest go through unmodified, standard RADIUS >> proxies? If so, how would they be aware of a new AVP that they need >> to process? > > Yes that would be a problem. They wouldn't be aware of it. So there > is that issue as well. So, does this mean that as far as the IETF is concerned RADIUS security is good enough, forever (I assume that this reasoning was at least in part behind the injunction against 'new security methods' in the charter)? ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 22 Nov 2004 22:32:07 +0000 Message-Id: <200411222231.iAMMVjPJ025286@sj-core-5.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: , "'Avi Lior'" Cc: Subject: RE: Progress on RADIUS Extension for Digest Authentication Date: Mon, 22 Nov 2004 14:31:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcTQ3e1AL0rbrpI/QeqJba67Fb0d3QABLmJg Jari Arkko <> wrote: > Avi Lior wrote: > >> Also, if Message-Authenticator is busted or close to being busted it >> is busted for EAP as well as Sterman. So Key Wrap document can >> basically indicated that Message-Authenticator should be deprecated >> and replaced with Key-Wrap. What is wrong with this strartegy? > > Nothing as far as I can see. It's a fine strategy, as long as it is executed _outside_ this WG (since it would appear to violate the charter in at least two ways). > > --Jari Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 22 Nov 2004 22:15:30 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: [Sterman Issue 7] Message Authenticator: Options Date: Mon, 22 Nov 2004 17:14:56 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Jarri, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, November 22, 2004 4:44 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: [Sterman Issue 7] Message Authenticator: Options > > > Hi Avi, > > I may be missing some background here. [Ok, I confess I have > not read all the e-mails in my Inbox :-) ] > > Why is this problem specific to RADIUS Digest draft? I > realize that it will have to reference the use of > Message-Authenticator. But so do other RADIUS specs. If the > use of MD5 is an issue, it would seem to be simpler that the > IETF would just do it once and for all in all of RADIUS. > Alternatively, start mandating IPsec. This is a problem for RADIUS in general. The discussion started around the use of message authenticator for the digest draft. Mandating Ipsec. Hmmmmm Ipsec could be mandated but I don't see that it will be used in RADIUS. > Also, should RADIUS Digest go through unmodified, > standard RADIUS proxies? If so, how would they be aware of > a new AVP that they need to process? Yes that would be a problem. They wouldn't be aware of it. So there is that issue as well. > Finally, if MD5 is bad, wouldn't that be a problem for > most Digest usage, RADIUS or not, given that the only > algorithms supported now are MD5 and AKA? I guess I'm asking > what makes the Message-Authenticator usage of MD5 different > from other RADIUS usage of MD5 or Digest usage of MD5, both > of which have to be relied upon anyway? Or is the issue that > the MD5 usage in Message-Authenticator is particularly vulnerable? It seems that everyone thinks MD5 is bad. But note that in fact Message-Authenticator (is HMAC-MD5 based) and is *not* vunerable (as I understand it). MD5 is vunerable in that we can easily create collisions. But as Chiba pointed out, "From what I understand, having an easy way to generate collisions does not mean that it will be easy to create valid RADIUS packets that result in the collision hash." Not being a security expert, I would be interested to see analysis if it is feasable to apply the MD5 attacks to RADIUS messages. -- to 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, 22 Nov 2004 21:54:57 +0000 Message-ID: <41A25FAA.5070500@piuha.net> Date: Mon, 22 Nov 2004 23:52:42 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Progress on RADIUS Extension for Digest Authentication Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Avi Lior wrote: > Also, if Message-Authenticator is busted or close to being busted it is > busted for EAP as well as Sterman. So Key Wrap document can basically > indicated that Message-Authenticator should be deprecated and replaced with > Key-Wrap. What is wrong with this strartegy? Nothing as far as I can see. --Jari -- to 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, 22 Nov 2004 21:48:28 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: [Sterman Issue 7] Message Authenticator: Options Date: Mon, 22 Nov 2004 16:48:11 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi David, Thanx for the quick repsonse. I didn't even consider the charter issue. That will take some time. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, November 22, 2004 4:39 PM > To: radiusext@ops.ietf.org > Subject: RE: [Sterman Issue 7] Message Authenticator: Options > > > Avi Lior writes... > > > -Will keywrap be ready in time? > > This is important but the authors feel that it is ready to go. > > Keywrap may well be important, to the extent that it > successfully addresses NIST certification requirements, but > it includes more than just an improved MAC, and would likely > require a charter change to be in scope (new RADIUS security > methods are currently out of scope). > > I think that Message-Authenticator is probably the way to go > for the Sterman draft. More extensive security enhancements > to RADIUS could be optionally applied to digest > authentication, as well as any other RADIUS application, when > and if they are standardized. > > -- 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: > -- to 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, 22 Nov 2004 21:46:08 +0000 Message-ID: <41A25DA5.3040507@piuha.net> Date: Mon, 22 Nov 2004 23:44:05 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: [Sterman Issue 7] Message Authenticator: Options Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Avi, I may be missing some background here. [Ok, I confess I have not read all the e-mails in my Inbox :-) ] Why is this problem specific to RADIUS Digest draft? I realize that it will have to reference the use of Message-Authenticator. But so do other RADIUS specs. If the use of MD5 is an issue, it would seem to be simpler that the IETF would just do it once and for all in all of RADIUS. Alternatively, start mandating IPsec. Also, should RADIUS Digest go through unmodified, standard RADIUS proxies? If so, how would they be aware of a new AVP that they need to process? Finally, if MD5 is bad, wouldn't that be a problem for most Digest usage, RADIUS or not, given that the only algorithms supported now are MD5 and AKA? I guess I'm asking what makes the Message-Authenticator usage of MD5 different from other RADIUS usage of MD5 or Digest usage of MD5, both of which have to be relied upon anyway? Or is the issue that the MD5 usage in Message-Authenticator is particularly vulnerable? --Jari Avi Lior wrote: > Hi folks, > We would like to get closure on the issue of the use of Message > Authenticator for draft-sterman-aaa-sip-04. > > Everyone seems to agree that we need to use some sort of RADIUS Message > Authenticator. > > There was a discussion on the strength of HMAC-MD5. Some suggested that we > should stregthen the RADIUS Message-Authenticator to HMAC-SHA1. > > -HMAC-MD5 is not busted (yet). > -draft-sterman-aaa-sip-04 carries HTTP digest which are based on MD5. > -draft-sterman-aaa-sip-04 seems to be addressing legacy deployements. > Recommending that greenfield implementation use Diameter. > -There is a push to get draft-sterman-aaa-sip-04 out quickly. > -keywrap proposes a new message authenticator Message-Authentication-Code > which supports either HMAC-MD5 or MHAC-SHA1 methods. > > Options: > ======== > 1) Allow draft-sterman-aaa-sip to use Message-Authenticator(80). And when > keywrap is ready we can state in keywrap that RADIUS implmentation should > upgrade to Message-Authentication-Code. > > 2) Require draft-sterman-aaa-sip to use Message-Authentication-Code. > > > Questions: > ========== > > -Will IESG accept a new RFC based on HMAC-MD5? > If not then we don't really have a choice. > > -Will keywrap be ready in time? > This is important but the authors feel that it is ready to go. However, > note that Keywrap allows Message-Authentication-Code to be HMAC-MD5 isn't > this a problem? > > Your comments and opinion would be appreciated. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 22 Nov 2004 21:45:10 +0000 Message-ID: From: Avi Lior To: "'gwz@cisco.com'" , Avi Lior , radiusext@ops.ietf.org Subject: RE: [Sterman Issue 7] Message Authenticator: Options Date: Mon, 22 Nov 2004 16:44:56 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Glen, If you allow HMAC-MD5 people will keep using it. If HMAC-MD5 is an issue, then in my opinion don't provide that option. Besides folks already have Message-Authenticator that they can use. > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Monday, November 22, 2004 4:37 PM > To: 'Avi Lior'; radiusext@ops.ietf.org > Subject: RE: [Sterman Issue 7] Message Authenticator: Options > > > Avi Lior <> wrote: > > > -Will keywrap be ready in time? > > This is important but the authors feel that it is ready to go. > > However, note that Keywrap allows Message-Authentication-Code to > be > > HMAC-MD5 isn't this a problem? > > The use of HMAC-MD5 is optional and included just for ease of > transition. It is _not_ required by the draft; if you like, > we can add text to the Security Considerations section > deprecating its use (or even remove it altogether -- I have > no problem with that). > > > > > Your comments and opinion would be appreciated. > > > > Avi > > Hope this helps, > > ~gwz > > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel > -- to 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, 22 Nov 2004 21:39:03 +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: [Sterman Issue 7] Message Authenticator: Options Date: Mon, 22 Nov 2004 16:38:46 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18F96@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Sterman Issue 7] Message Authenticator: Options Thread-Index: AcTQ2Kq1IX+rxvGxT9aXYbn1w3OV+QAAYcag From: "Nelson, David" To: Avi Lior writes... > -Will keywrap be ready in time? > This is important but the authors feel that it is ready to go.=20 Keywrap may well be important, to the extent that it successfully addresses NIST certification requirements, but it includes more than just an improved MAC, and would likely require a charter change to be in scope (new RADIUS security methods are currently out of scope). I think that Message-Authenticator is probably the way to go for the Sterman draft. More extensive security enhancements to RADIUS could be optionally applied to digest authentication, as well as any other RADIUS application, when and if they are standardized. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 22 Nov 2004 21:37:31 +0000 Message-Id: <200411222137.iAMLbJYr004010@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Avi Lior'" , Subject: RE: [Sterman Issue 7] Message Authenticator: Options Date: Mon, 22 Nov 2004 13:37:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit thread-index: AcTQ2KySMxZFn2btTd2AiLOTdkLSbwAAhyuw Avi Lior <> wrote: > -Will keywrap be ready in time? > This is important but the authors feel that it is ready to go. > However, note that Keywrap allows Message-Authentication-Code to be > HMAC-MD5 isn't this a problem? The use of HMAC-MD5 is optional and included just for ease of transition. It is _not_ required by the draft; if you like, we can add text to the Security Considerations section deprecating its use (or even remove it altogether -- I have no problem with that). > > Your comments and opinion would be appreciated. > > Avi Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 22 Nov 2004 21:17:10 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: [Sterman Issue 7] Message Authenticator: Options Date: Mon, 22 Nov 2004 16:16:33 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi folks, We would like to get closure on the issue of the use of Message Authenticator for draft-sterman-aaa-sip-04. Everyone seems to agree that we need to use some sort of RADIUS Message Authenticator. There was a discussion on the strength of HMAC-MD5. Some suggested that we should stregthen the RADIUS Message-Authenticator to HMAC-SHA1. -HMAC-MD5 is not busted (yet). -draft-sterman-aaa-sip-04 carries HTTP digest which are based on MD5. -draft-sterman-aaa-sip-04 seems to be addressing legacy deployements. Recommending that greenfield implementation use Diameter. -There is a push to get draft-sterman-aaa-sip-04 out quickly. -keywrap proposes a new message authenticator Message-Authentication-Code which supports either HMAC-MD5 or MHAC-SHA1 methods. Options: ======== 1) Allow draft-sterman-aaa-sip to use Message-Authenticator(80). And when keywrap is ready we can state in keywrap that RADIUS implmentation should upgrade to Message-Authentication-Code. 2) Require draft-sterman-aaa-sip to use Message-Authentication-Code. Questions: ========== -Will IESG accept a new RFC based on HMAC-MD5? If not then we don't really have a choice. -Will keywrap be ready in time? This is important but the authors feel that it is ready to go. However, note that Keywrap allows Message-Authentication-Code to be HMAC-MD5 isn't this a problem? Your comments and opinion would be appreciated. Avi -- to 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, 22 Nov 2004 16:10:35 +0000 Message-ID: From: Avi Lior To: "'gwz@cisco.com'" , "'Nelson, David'" , Avi Lior , 'Bernard Aboba' Cc: radiusext@ops.ietf.org, 'AC Mahendran' Subject: RE: Progress on RADIUS Extension for Digest Authentication Date: Mon, 22 Nov 2004 11:10:13 -0500 MIME-Version: 1.0 Content-Type: text/plain Glen and all, I agree, if the keywrap doc is ready we should ask for it to be: a) a working group item; and b) put it in to working last call ASAP. As for its use for sterman draft, ideally we should use keywrap for this document. I am all for that with the caveat that we should not delay sterman. I don't want to see sterman delayed. Especially since Message-Authenticator is not busted. Also, if Message-Authenticator is busted or close to being busted it is busted for EAP as well as Sterman. So Key Wrap document can basically indicated that Message-Authenticator should be deprecated and replaced with Key-Wrap. What is wrong with this strartegy? > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Friday, November 19, 2004 4:07 PM > To: 'Nelson, David'; 'Avi Lior'; 'Bernard Aboba' > Cc: radiusext@ops.ietf.org; 'AC Mahendran' > Subject: RE: Progress on RADIUS Extension for Digest Authentication > > > Nelson, David <> wrote: > >> Okay. So lets get this draft into last call right away. > > > > Which draft? The keywrap draft? We haven't reached consensus > that > > it should be a WG work item yet, > > Has anybody called for consensus from the WG? It's > incredibly difficult to reach something without moving your hand... > > > although Bernard has suggested that > > it should be, and it seems to address a valid issue (NIST/FIPS > > approved algorithms). > > > > Perhaps we ought to follow your earlier suggestion and use the > > existing Message-Authenticator Attribute in the Digest > Authentication > > draft (as it is a short-term dependency for 3GPP2). We > could then let > > the keywrap draft take its course, hopefully eliciting more > review and > > comment on the list than heretofore. > > I like this plan! Let's 1) rubberstamp a flawed document, insuring > 2) either massive upgrades or (more likely) non-action later because > 3) we can't make a decision on anything of substance in less > than 2 years. > > > > > -- Dave > > Hope this helps, > > ~gwz > > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel > -- to 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, 22 Nov 2004 15:41:49 +0000 Date: Mon, 22 Nov 2004 07:41:19 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Adoption of CUI as a RADEXT WG Work Item Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There appears to be a substantial community of people interested in the CUI work, so that we have consensus that it should become a RADEXT WG Work Item. My suggestion is that the open issues be addressed and that a new draft-ietf-radext-cui-00.txt be submitted to the archive. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 22 Nov 2004 14:37:16 +0000 Date: Mon, 22 Nov 2004 06:36:44 -0800 (PST) From: Bernard Aboba To: Jari Arkko cc: john.loughney@nokia.com, radiusext@ops.ietf.org Subject: Re: Issue: RFC 2486bis - obsoletes or updates? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hmm... RFC 2284bis at least had a line in the header that said > something about obsoleting 2284. Checking for the XML command > to do this... found from Henrik's 2284 draft... Ok, I'll add it. Yes. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 22 Nov 2004 12:22:18 +0000 Message-ID: <41A1D96C.6090101@piuha.net> Date: Mon, 22 Nov 2004 14:19:56 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: john.loughney@nokia.com Cc: radiusext@ops.ietf.org Subject: Re: Issue: RFC 2486bis - PPTP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > PPTP is used in the document, but never expanded. > Expand first instance of PPTP Done. Thanks. Also added a few informational references to the terms, and expanded ABNF, EAP and RADIUS where they first appeared, just in case... --Jari -- to 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, 22 Nov 2004 09:20:47 +0000 Message-ID: <41A1AEE3.4040302@piuha.net> Date: Mon, 22 Nov 2004 11:18:27 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: john.loughney@nokia.com Cc: radiusext@ops.ietf.org Subject: Re: Issue: RFC 2486bis - obsoletes or updates? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Abstract says: > This document is a revised version > of RFC 2486 which originally defined NAIs. > > Don't know if 2486 is still valid after this document is published > > Requested change: > > Somewhere it should say if this draft updates or obsoletes RFC2486. I think it obsoletes RFC 2486. But its unclear to me whether this needs to be put into a text within the document itself, or whether its something that the RFC editor adds. I haven't personally edited a bis draft before, so I have no experience. Hmm... RFC 2284bis at least had a line in the header that said something about obsoleting 2284. Checking for the XML command to do this... found from Henrik's 2284 draft... Ok, I'll add it. Here's the current revised version: http://www.arkko.com/publications/nai/naibis.txt http://www.arkko.com/publications/nai/naibisdiff.html Thanks for reporting this John. --Jari -- to 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, 22 Nov 2004 08:44:50 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Issue: RFC 2486bis - PPTP Date: Mon, 22 Nov 2004 10:31:19 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432141@esebe056.ntc.nokia.com> Thread-Topic: RADEXT WG last call on RFC 2486bis-02 Thread-Index: AcTQat0GdTqXJ5WhSCWAznjStEF+SgAAg5UQAAAmN/A= From: To: , Description of issue Submitter name: John Loughney Submitter email address: john.loughney@nokia.com Date first submitted: 11/22/2004 Document: RFC2284bis Comment type: E Priority: 1=20 Section: Abstract Rationale/Explanation of issue: no expansion of PPTP Length description of problem PPTP is used in the document, but never expanded. Don't know if 2486 is still valid after this document is published Requested change: Expand first instance of PPTP -- to 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, 22 Nov 2004 08:44:42 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Issue: RFC 2486bis - obsoletes or updates? Date: Mon, 22 Nov 2004 10:30:17 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432140@esebe056.ntc.nokia.com> Thread-Topic: RADEXT WG last call on RFC 2486bis-02 Thread-Index: AcTQat0GdTqXJ5WhSCWAznjStEF+SgAAg5UQAAAgVtA= From: To: , Description of issue Submitter name: John Loughney Submitter email address: john.loughney@nokia.com Date first submitted: 11/22/2004 Document: RFC2284bis Comment type: E Priority: 1=20 Section: Abstract Rationale/Explanation of issue: Length description of problem Abstract says:=20 This document is a revised version of RFC 2486 which originally defined NAIs.=20 Don't know if 2486 is still valid after this document is published Requested change: Somewhere it should say if this draft updates or obsoletes RFC2486. -- to 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, 22 Nov 2004 08:44:36 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG last call on RFC 2486bis-02 Date: Mon, 22 Nov 2004 10:37:56 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432142@esebe056.ntc.nokia.com> Thread-Topic: RADEXT WG last call on RFC 2486bis-02 Thread-Index: AcTQat0GdTqXJ5WhSCWAznjStEF+SgAA37bg From: To: , Bernard, > It has been pointed out that a newer version of this document (-02) = has > been submitted, so that a revised last call announcement is required. I did a re-review of the draft, found two points to be clarified (the = 2nd point -=20 expanding PPTP might be better solved by having a terminolgy section, = where most acronyms are expanded), but no show-stoppers. If there are no = significant other issues, I'd be fine with having my issues addressed during next = revision, if there are any AD or IESG comments. thanks, 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: Mon, 22 Nov 2004 08:06:56 +0000 Date: Mon, 22 Nov 2004 00:05:58 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG last call on RFC 2486bis-02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It has been pointed out that a newer version of this document (-02) has been submitted, so that a revised last call announcement is required. This is an announcement of RADEXT WG Last call on "The Network Access Identifier" specification, RFC 2486bis, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard (recycled). The document is available for inspection at the following locations: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-rfc2486bis-02.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-02.txt (should show up here today) RADEXT WG Last Call will complete on November 30, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 20 Nov 2004 06:18:00 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG last call on RFC 2486bis Date: Sat, 20 Nov 2004 08:17:01 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D43212B@esebe056.ntc.nokia.com> Thread-Topic: RADEXT WG last call on RFC 2486bis Thread-Index: AcTObeg+4TKLm89vS6ScZ05XdA9HUwAWp03Q From: To: , Cc: Hi all, > 2) Like Pasi, I'm a bit puzzled why we need another LC > on this document. We already had a last call and all > issues were resolved, the issue tracker does not show > anything remaining. I agree. 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: Fri, 19 Nov 2004 22:09:26 +0000 Message-Id: <200411192209.iAJM9BYr001206@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Nelson, David'" Cc: , "'AC Mahendran'" Subject: RE: Progress on RADIUS Extension for Digest Authentication Date: Fri, 19 Nov 2004 14:09:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcTOSjdq4kYM78VNSYar9JlI0zwRewAItkqAAANcdtAAATG/QAAArVug Nelson, David <> wrote: > Glen Zorn writes (regarding the keywrap draft)... > >> Has anybody called for consensus from the WG? > > No. Not so far. > >> I like this plan! Let's 1) rubberstamp a flawed document, insuring >> 2) either massive upgrades or (more likely) non-action later because >> 3) we can't make a decision on anything of substance in less than 2 >> years. > > Well, since RADEXT has been in existence for about 4 months, the > comment about 2 years is probably an exaggeration. :-) I call it wild hyperbole, myself, if I hadn't been referring to the IETF in general... > > If 3GPP2 can wait for us to do the right thing, I'd prefer that > approach as well. I see no reason to assume that waiting would be necessary: the document in question has been widely reviewed already, both within and outside the co-authors' respective companies; the reviewers have included at least one IESG member. There can't be _that_ much wrong with it! So, if I may be so bold as to suggest a plan of action: 1) Issue a call for consensus on accepting the document as a WG item today. 2) If consensus is positive, ask the authors to submit a renamed version of the doc. 3) Upon submission of the revised document, immediately issue WG Last Call on it (as many people have observed, Last Call is the best (if not only) way to get people to read a draft anyway) :-( 4) If the key-wrap draft bogs down in any way during LC, just advance the Digest Auth draft as is; otherwise make the minor modifications necessary and advance it. > > -- Dave Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 19 Nov 2004 21:39:06 +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: Progress on RADIUS Extension for Digest Authentication Date: Fri, 19 Nov 2004 16:38:46 -0500 Message-ID: Thread-Topic: Progress on RADIUS Extension for Digest Authentication Thread-Index: AcTOSjdq4kYM78VNSYar9JlI0zwRewAItkqAAANcdtAAATG/QA== From: "Nelson, David" To: Cc: , "AC Mahendran" Glen Zorn writes (regarding the keywrap draft)... > Has anybody called for consensus from the WG? No. Not so far. > I like this plan! Let's 1) rubberstamp a flawed document, insuring > 2) either massive upgrades or (more likely) non-action later because > 3) we can't make a decision on anything of substance in less than 2 > years. Well, since RADEXT has been in existence for about 4 months, the comment about 2 years is probably an exaggeration. :-) If 3GPP2 can wait for us to do the right thing, I'd prefer that approach as well. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Nov 2004 21:07:02 +0000 Message-Id: <200411192106.iAJL6lYr009100@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Nelson, David'" , "'Avi Lior'" , "'Bernard Aboba'" Cc: , "'AC Mahendran'" Subject: RE: Progress on RADIUS Extension for Digest Authentication Date: Fri, 19 Nov 2004 13:06:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcTOSjdq4kYM78VNSYar9JlI0zwRewAItkqAAANcdtA= Nelson, David <> wrote: >> Okay. So lets get this draft into last call right away. > > Which draft? The keywrap draft? We haven't reached consensus that > it should be a WG work item yet, Has anybody called for consensus from the WG? It's incredibly difficult to reach something without moving your hand... > although Bernard has suggested that > it should be, and it seems to address a valid issue (NIST/FIPS > approved algorithms). > > Perhaps we ought to follow your earlier suggestion and use the > existing Message-Authenticator Attribute in the Digest Authentication > draft (as it is a short-term dependency for 3GPP2). We could then > let the keywrap draft take its course, hopefully eliciting more > review and comment on the list than heretofore. I like this plan! Let's 1) rubberstamp a flawed document, insuring 2) either massive upgrades or (more likely) non-action later because 3) we can't make a decision on anything of substance in less than 2 years. > > -- Dave Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 19 Nov 2004 20:49:24 +0000 Message-ID: <419E4F28.5090307@piuha.net> Date: Fri, 19 Nov 2004 21:53:12 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Nelson, David" Cc: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: RADEXT WG last call on RFC 2486bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson, David wrote: > I thought we were looking for affirmative acknowledgement from the > previous commenters that all the issues had been appropriately addressed > in the revised draft. As I recall, the three changes in -02 were all minor and editorial. So far we've used the positive acknowledgment approach in cases where there's been problems, suspicion of inadequate review, or something else abnormal. If we don't suspect these problems it might be more efficient to just move forward; the issue submitters either responded positively already or at least they've had quite some time to look at our proposed text... How about at least making the period shorter, say a week? I think we have some other work which has bigger issues, lets get this thing out of the way so that we can concentrate on the other stuff. --Jari -- to 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, 19 Nov 2004 20:33:27 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , Avi Lior , Bernard Aboba , "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org, AC Mahendran Subject: RE: Progress on RADIUS Extension for Digest Authentication Date: Fri, 19 Nov 2004 15:17:07 -0500 MIME-Version: 1.0 Content-Type: text/plain Yes it would be the keywrap. So I would prefer to do it right but as time constraints have it.... > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Friday, November 19, 2004 2:28 PM > To: Avi Lior; Bernard Aboba; Glen Zorn (gwz) > Cc: radiusext@ops.ietf.org; AC Mahendran > Subject: RE: Progress on RADIUS Extension for Digest Authentication > > > > Okay. So lets get this draft into last call right away. > > Which draft? The keywrap draft? We haven't reached > consensus that it should be a WG work item yet, although > Bernard has suggested that it should be, and it seems to > address a valid issue (NIST/FIPS approved algorithms). > > Perhaps we ought to follow your earlier suggestion and use > the existing Message-Authenticator Attribute in the Digest > Authentication draft (as it is a short-term dependency for > 3GPP2). We could then let the keywrap draft take its course, > hopefully eliciting more review and comment on the list than > heretofore. > > -- Dave > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Nov 2004 20:24:44 +0000 Message-ID: <591B780D9676844E8A704B5B013FFE9203E1CD71@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: radiusext@ops.ietf.org Cc: aboba@internaut.com Subject: CUI: WG Work Item Date: Fri, 19 Nov 2004 14:55:58 -0500 MIME-Version: 1.0 Content-Type: text/plain -- to 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, 19 Nov 2004 19:47:34 +0000 Message-Id: <200411191947.AFW13151@mira-sjc5-d.cisco.com> Reply-To: From: "Ed Van Horne \(evh\)" To: Subject: CUI: WG Work Item Date: Fri, 19 Nov 2004 11:47:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcTNxWbKALGmKR1rSnaFvaIm8LCKYAAqxVNQ -- to 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, 19 Nov 2004 19:31:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG last call on RFC 2486bis Date: Fri, 19 Nov 2004 14:30:29 -0500 Message-ID: Thread-Topic: RADEXT WG last call on RFC 2486bis Thread-Index: AcTObchVXV+hv7SkRz6+LSW01TqbpQAAEPRg From: "Nelson, David" To: , "Bernard Aboba" Cc: > 2) Like Pasi, I'm a bit puzzled why we need another LC > on this document. We already had a last call and all > issues were resolved, the issue tracker does not show > anything remaining. I thought we were looking for affirmative acknowledgement from the previous commenters that all the issues had been appropriately addressed in the revised draft. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Nov 2004 19:28:03 +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: Progress on RADIUS Extension for Digest Authentication Date: Fri, 19 Nov 2004 14:27:48 -0500 Message-ID: Thread-Topic: Progress on RADIUS Extension for Digest Authentication Thread-Index: AcTOSjdq4kYM78VNSYar9JlI0zwRewAItkqA From: "Nelson, David" To: "Avi Lior" , "Bernard Aboba" , "Glen Zorn \(gwz\)" Cc: , "AC Mahendran" > Okay. So lets get this draft into last call right away. Which draft? The keywrap draft? We haven't reached consensus that it should be a WG work item yet, although Bernard has suggested that it should be, and it seems to address a valid issue (NIST/FIPS approved algorithms). Perhaps we ought to follow your earlier suggestion and use the existing Message-Authenticator Attribute in the Digest Authentication draft (as it is a short-term dependency for 3GPP2). We could then let the keywrap draft take its course, hopefully eliciting more review and comment on the list than heretofore. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Nov 2004 19:26:46 +0000 Message-ID: <419E4872.3080007@piuha.net> Date: Fri, 19 Nov 2004 21:24:34 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: RADEXT WG last call on RFC 2486bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 1) The correct draft version is -02, not -01. I posted the pointer to the new version earlier to the list but did not submit until today. Here are the pointers until it appears: http://www.arkko.com/publications/nai/draft-ietf-radext-rfc2486bis-02.txt http://www.arkko.com/publications/nai/draft-ietf-radext-rfc2486bis-02diff.html 2) Like Pasi, I'm a bit puzzled why we need another LC on this document. We already had a last call and all issues were resolved, the issue tracker does not show anything remaining. --Jari -- to 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, 19 Nov 2004 18:18:48 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E75462018CEAB6@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Bernard Aboba'" , "'radiusext@ops.ietf.org'" Subject: CUI: WG Work Item Date: Fri, 19 Nov 2004 19:18:16 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CE64.23D3F4A2" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4CE64.23D3F4A2 Content-Type: text/plain ------_=_NextPart_001_01C4CE64.23D3F4A2 Content-Type: text/html CUI: WG Work Item ------_=_NextPart_001_01C4CE64.23D3F4A2-- -- to 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, 19 Nov 2004 16:18:35 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: CUI: WG Work Item Date: Fri, 19 Nov 2004 18:16:46 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FDDB@esebe056.ntc.nokia.com> Thread-Topic: CUI: WG Work Item Thread-Index: AcTOUypU2uRiCrvPToejEqDMyBV/YA== From: To: (Oops, my previous message was actually about 2486bis, but ended up having the wrong subject line. Sorry about that!) But I also support making CUI a WG work item (the contents of the document still need work, though). 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Nov 2004 16:16:04 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: CUI: WG Work Item Date: Fri, 19 Nov 2004 18:14:57 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD1783C5@esebe056.ntc.nokia.com> Thread-Topic: CUI: WG Work Item Thread-Index: AcTOUumlRyUocPyvSmC/WVOhw2u57Q== From: To: We already had one WGLC for 2486bis; given that the issues raised back then were very minor, I'm not quite sure why=20 we need another one... But anyway, the issues I brought up back then have been resolved, so I'm OK with the document. Best regards, Pasi > -----Original Message----- > From: Bernard Aboba > Sent: Thursday, November 18, 2004 7:54 PM > To: radiusext@ops.ietf.org > Subject: RADEXT WG last call on RFC 2486bis >=20 >=20 > This is an announcement of RADEXT WG Last call on "The Network > Access Identifier" specification, RFC 2486bis, prior to=20 > sending the draft on to the IESG for consideration as an IETF=20 > Proposed Standard (recycled). The draft is available for=20 > inspection at: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-radext- > rfc2486bis-01.txt > RADEXT WG Last Call will complete on December 8, 2004. Please send=20 > comments to the RADEXT WG mailing list (radiusext@ops.ietf.org),=20 > using the issue format described at: >=20 > http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 19 Nov 2004 15:12:19 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , "Glen Zorn (gwz)" Cc: Avi Lior , radiusext@ops.ietf.org, AC Mahendran Subject: RE: Progress on RADIUS Extension for Digest Authentication Date: Fri, 19 Nov 2004 10:11:28 -0500 MIME-Version: 1.0 Content-Type: text/plain Okay. So lets get this draft into last call right away. Bernard, remember that 3GPP2 is looking for the sterman draft ASAP. There is a document that is ready to publish that must have an RFC number for sterman. So if this achievable then I am all for doing it right. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, November 18, 2004 11:56 PM > To: Glen Zorn (gwz) > Cc: 'Avi Lior'; radiusext@ops.ietf.org > Subject: RE: Progress on RADIUS Extension for Digest Authentication > > > > Doesn't this draft > > http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt > > solve your problem? > > I believe that Section 3.2 of this document does provide for the > following: > > a. Integrity protection and authentication of messages. > b. Multiple algorithm support (HMAC-MD5 & HMAC-SHA1 for starters) > > My reason for suggesting that the WG consider this is that > the Security ADs have expressed concern about MD5 usage in > new documents. In addition, NIST is likely to require a > FIPS-approved MAC such as HMAC-SHA1 for FIPS certification. > So I think that RADEXT WG will eventually need something > along these lines. So why not bite the bullet now? > -- to 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, 19 Nov 2004 07:42:37 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: CUI: WG Work Item Date: Fri, 19 Nov 2004 09:42:23 +0200 Message-ID: <07B14A720C46C344AC96AAA64F5D6A318247FF@FITMS201MB.tcad.telia.se> Thread-Topic: CUI: WG Work Item Thread-Index: AcTNnb98HvA41SnoRpO5nNE9P0geRQAbUOzw From: To: , -- to 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, 19 Nov 2004 06:44:23 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: Chargeable User Identity (CUI) Date: Fri, 19 Nov 2004 08:41:53 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432106@esebe056.ntc.nokia.com> Thread-Topic: Request for Review: Chargeable User Identity (CUI) Thread-Index: AcTNncMVVD2ae7nRTPipJHyMyjP2fAAFWf0gAABKAmAAE5v1cA== From: To: , , Hi Farid, > As per our IETF discussion, John has volunteered to write up an > applicability section for the CUI draft - the idea is to make the > rationale for the CUI more clear. So, John's suggestion is a good = idea > *IF* most folks are not still convinced about the rationale=20 > for the CUI. I agree. If the WG thinks that this should be a WG item, then we can submit the update as draft-radext- ... 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: Fri, 19 Nov 2004 04:56:40 +0000 Date: Thu, 18 Nov 2004 20:56:15 -0800 (PST) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: "'Avi Lior'" , radiusext@ops.ietf.org Subject: RE: Progress on RADIUS Extension for Digest Authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Doesn't this draft > http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt > solve your problem? I believe that Section 3.2 of this document does provide for the following: a. Integrity protection and authentication of messages. b. Multiple algorithm support (HMAC-MD5 & HMAC-SHA1 for starters) My reason for suggesting that the WG consider this is that the Security ADs have expressed concern about MD5 usage in new documents. In addition, NIST is likely to require a FIPS-approved MAC such as HMAC-SHA1 for FIPS certification. So I think that RADEXT WG will eventually need something along these lines. So why not bite the bullet now? -- to 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, 19 Nov 2004 03:57:10 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: CUI: WG Work Item Date: Fri, 19 Nov 2004 05:56:04 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4320FD@esebe056.ntc.nokia.com> Thread-Topic: CUI: WG Work Item Thread-Index: AcTNnb9HtuG7dKpXR7GYiZQZRjOzeAAIKHAwAAEk5aAACi1SUA== From: To: -- to 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, 18 Nov 2004 23:38:44 +0000 Message-Id: <200411182338.iAINcVYr010565@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Avi Lior'" , "'Bernard Aboba'" , Subject: RE: Progress on RADIUS Extension for Digest Authentication Date: Thu, 18 Nov 2004 15:38:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Index: AcTNxVC84hx3SIMVRpGVMMPGuSQHjQAAddYA Avi Lior <> wrote: > Hi Bernard, > > Regarding Issue[7] The need to use Message Authenticator. > > I think we all agreed that a message authenticator is needed here. > I think the debate was whether the Message-Autheticator will suffice > here. > > You suggested that maybe we introduce a new attribute. But as you > pointed out that while MD5 was found to be vunerable HMAC-MD5 was > not. There was lots of debate on this issue. > > I don't think we would solve this issue in the near future. This is > because, judging from the emails I don't think we would get consensus > even if we created a new message authenticator based on HMAC-SHA1. Doesn't this draft (http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.tx t) solve your problem? > > So my suggestion is to use Message-Authenticator(80) which is based > on(HMAC-MD5). Which is not broken and proceed with the work. Not > having anything is clearly bad. > > >> -----Original Message----- >> From: Bernard Aboba [mailto:aboba@internaut.com] >> Sent: Thursday, November 18, 2004 1:16 PM >> To: radiusext@ops.ietf.org >> Subject: Progress on RADIUS Extension for Digest Authentication >> >> >> The specification "RADIUS Extension for Digest Authentication" has >> completed RADEXT WG Last call. Issues filed against the >> specification are available here: >> >> http://www.drizzle.com/~aboba/RADEXT/ >> >> The latest version of the specification is available here: >> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt >> >> Further progress on this document requires that we verify that >> changes made in the -04 document represent RADEXT WG consensus. >> Since detailed text changes were not posted to the RADEXT WG mailing >> list prior to the submission of the -04 document, it is not possible >> to determine whether RADEXT WG consensus exists on the changes based >> on examination of the mailing list discussion. It is therefore not >> possible to move forward on this document until this issue is >> cleared up. >> >> In order to make progress, we have made a request that Issue >> submitters and other WG participants examine the changes in >> -04 and send email to the WG list, stating whether the changes are >> acceptable. So far, the mail received indicates the following: >> >> Issue 4: No mail received. WG consensus not verified. >> Issue 5: No mail received, Diameter draft needs to be updated before >> determining whether the resolutions can work. WG consensus >> not verified. Issue 6: No mail received. WG consensus not verified. >> Issue 7: Mail received, indicates WG consensus *against* the proposed >> resolution. No consensus verified. >> Issue 8: No mail received, security issues raised at IETF 60. No >> consensus verified. Issue 11: No mail received. No consensus >> verified. >> Issue 12: No mail received. No censensus verified. >> >> Given the lack of confirming email, we are at present unable to >> confirm whether the changes made in -04 represent WG consensus, and >> in one case (Issue 7) it appears that the proposed resolution has >> been rejected by the RADEXT WG. >> >> In order to enable the WG to demonstrate sufficient interest, we are >> going to extend the Request for Comment on the proposed resolutions >> until December 6, 2004. If you have submitted an Issue on the >> document, and >> believe it has been resolved, please send mail with "Issue X: >> Resolved" in the subject line, where X is the Issue number of your >> issue. >> >> If you have additional comments on the specification, or wish to >> contest the resolution of an issue, please send email to the RADEXT >> WG mailing list (radiusext@ops.ietf.org) in the format described on >> the RADEXT WG mailing list: >> >> http://www.drizzle.com/~aboba/RADEXT/ >> >> -- >> to unsubscribe send a message to >> radiusext-request@ops.ietf.org with the word 'unsubscribe' in a >> single line as the message text body. >> archive: Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 18 Nov 2004 23:33:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: CUI: WG Work Item Date: Thu, 18 Nov 2004 15:23:15 -0800 Message-ID: Thread-Topic: CUI: WG Work Item Thread-Index: AcTNxZSWN+Ihmd/HSqS4SAtK2+ohYw== From: "Adrangi, Farid" To: -- to 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, 18 Nov 2004 23:21:28 +0000 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" Subject: CUI: WG Work Item Date: Thu, 18 Nov 2004 18:21:22 -0500 MIME-Version: 1.0 Content-Type: text/plain -- to 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, 18 Nov 2004 23:18:50 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: RE: Progress on RADIUS Extension for Digest Authentication Date: Thu, 18 Nov 2004 18:18:34 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Bernard, Regarding Issue[7] The need to use Message Authenticator. I think we all agreed that a message authenticator is needed here. I think the debate was whether the Message-Autheticator will suffice here. You suggested that maybe we introduce a new attribute. But as you pointed out that while MD5 was found to be vunerable HMAC-MD5 was not. There was lots of debate on this issue. I don't think we would solve this issue in the near future. This is because, judging from the emails I don't think we would get consensus even if we created a new message authenticator based on HMAC-SHA1. So my suggestion is to use Message-Authenticator(80) which is based on(HMAC-MD5). Which is not broken and proceed with the work. Not having anything is clearly bad. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, November 18, 2004 1:16 PM > To: radiusext@ops.ietf.org > Subject: Progress on RADIUS Extension for Digest Authentication > > > The specification "RADIUS Extension for Digest > Authentication" has completed RADEXT WG Last call. Issues > filed against the specification are available here: > > http://www.drizzle.com/~aboba/RADEXT/ > > The latest version of the specification is available here: > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt > > Further progress on this document requires that we verify > that changes made in the -04 document represent RADEXT WG > consensus. Since detailed text changes were not posted to the > RADEXT WG mailing list prior to the submission of the -04 > document, it is not possible to determine whether RADEXT WG > consensus exists on the changes based on examination of the > mailing list discussion. It is therefore not possible to > move forward on this document until this issue is cleared up. > > In order to make progress, we have made a request that Issue > submitters and other WG participants examine the changes in > -04 and send email to the WG list, stating whether the > changes are acceptable. So far, the mail received indicates > the following: > > Issue 4: No mail received. WG consensus not verified. > Issue 5: No mail received, Diameter draft needs to be updated before > determining whether the resolutions can work. WG consensus > not verified. > Issue 6: No mail received. WG consensus not verified. > Issue 7: Mail received, indicates WG consensus *against* the proposed > resolution. No consensus verified. > Issue 8: No mail received, security issues raised at IETF 60. No > consensus verified. > Issue 11: No mail received. No consensus verified. > Issue 12: No mail received. No censensus verified. > > Given the lack of confirming email, we are at present unable > to confirm whether the changes made in -04 represent WG > consensus, and in one case (Issue 7) it appears that the > proposed resolution has been rejected by the RADEXT WG. > > In order to enable the WG to demonstrate sufficient interest, > we are going to extend the Request for Comment on the > proposed resolutions until > December 6, 2004. If you have submitted an Issue on the > document, and > believe it has been resolved, please send mail with "Issue X: > Resolved" in the subject line, where X is the Issue number of > your issue. > > If you have additional comments on the specification, or wish > to contest the resolution of an issue, please send email to > the RADEXT WG mailing list (radiusext@ops.ietf.org) in the > format described on the RADEXT WG mailing list: > > http://www.drizzle.com/~aboba/RADEXT/ > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to 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, 18 Nov 2004 23:06:35 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: CUI: WG Work Item Date: Thu, 18 Nov 2004 15:05:28 -0800 Message-ID: Thread-Topic: CUI: WG Work Item Thread-Index: AcTNnb9HtuG7dKpXR7GYiZQZRjOzeAAIKHAwAAEk5aA= From: "Bari, Farooq" To: -- to 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, 18 Nov 2004 22:00:40 +0000 Message-Id: <6.1.2.0.0.20041118164648.03b04778@localhost> Date: Thu, 18 Nov 2004 16:57:11 -0500 To: radiusext@ops.ietf.org,geopriv@ietf.org From: "Joel M. Halpern" Subject: draft-ietf-geopriv-radius-lo-01.txt - registry of operator name prefixes? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Description of issue: operator name prefix space must be properly defined Submitter name: Joel M. Halpern Submitter email address: joel@stevecrocker.com Date first submitted: 18-November-2004 Reference: Document: draft-ietf-geopriv-radius-lo-01.txt Comment type: T Priority: 1 Section: 5.1 & 11 Rationale/Explanation of issue: Operator-prefixes are defined. Creation rules and a registry must be defined Length description of problem: Section 5.1 states that only the listed operator name prefixes may be used. It then states that other operator name prefixes may come into existence. Thus, it is creating a registry, presumably with some expectation on rules for how prefixes get into that registry. However, the IANA considerations section (11) does not even mention the three allocated values. No section describes how new values may be created, or what rules such new values must abide by. Requested change: The document should properly define the registry it is creating. -- to 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, 18 Nov 2004 22:00:34 +0000 Message-Id: <6.1.2.0.0.20041118163452.03b76598@localhost> Date: Thu, 18 Nov 2004 16:59:48 -0500 To: radiusext@ops.ietf.org,geopriv@ietf.org From: "Joel M. Halpern" Subject: draft-ietf-geopriv-radius-lo-01.txt - whose location? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Description of issue: Document mixes location of user and location of access Submitter name: Joel M. Halpern Submitter email address: joel@stevecrocker.com Date first submitted: 18-November-2004 Reference: Document: draft-ietf-geopriv-radius-lo-01.txt Comment type: T Priority: 1 Section: Multiple Rationale/Explanation of issue: The location of a user is very different from the location of an access device. Length description of problem: The document states that it provides the location of the access device providing network service. The document then goes on to describe this as "the users location". The document even describes this location as being useful for services other than charging (cf section 4.2). However, what is needed for accounting is very different from the location for service delivery. The correlation between the two depends many factors outside of the scope of this draft. Mixing the two is not helpful. The information format in fact seems designed to provide not the access device location, but the location of the subscriber. It is also likely that if access identification is desired, geographic location will often not be the correct mechanism. Requested change: Decide whether this document is intended to provide subscriber location (which is rarely directly useful for AAA), or access device / network location information. In either case, remove the inappropriate material. If access device identification is desired, please indicate why operator defined tokens are not sufficient. And reference where such tokens are when they are needed. -- to 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, 18 Nov 2004 21:47:25 +0000 Message-Id: <6.1.2.0.0.20041118164150.03a104e0@localhost> Date: Thu, 18 Nov 2004 16:46:41 -0500 To: radiusext@ops.ietf.org,geopriv@ietf.org From: "Joel M. Halpern" Subject: draft-ietf-geopriv-radius-lo-01.txt - CDMA operator-name prefix Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Description of issue: Operator-Name prefix defined without usage Submitter name: Joel M. Halpern Submitter email address: joel@stevecrocker.com Date first submitted: 18-November-2004 Reference: Document: draft-ietf-geopriv-radius-lo-01.txt Comment type: T Priority: 2 Section: 5.1 Rationale/Explanation of issue: The operator prefix CDMA is defined, but never user Length description of problem: The CDMA operator-name prefix is listed as a valid prefix in section 5.1. However, no definition is included as to what names may use such a prefix or how they should use it. Requested change: Either describe who allocates "CDMA" operator names, and how such names are allocated, ore remove the name -- to 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, 18 Nov 2004 21:34:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: Chargeable User Identity (CUI) Date: Thu, 18 Nov 2004 13:34:28 -0800 Message-ID: Thread-Topic: Request for Review: Chargeable User Identity (CUI) Thread-Index: AcTNncMVVD2ae7nRTPipJHyMyjP2fAAFWf0gAABKAmA= From: "Adrangi, Farid" To: , , As per our IETF discussion, John has volunteered to write up an applicability section for the CUI draft - the idea is to make the rationale for the CUI more clear. So, John's suggestion is a good idea *IF* most folks are not still convinced about the rationale for the CUI. Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of=20 > john.loughney@nokia.com > Sent: Thursday, November 18, 2004 1:12 PM > To: aboba@internaut.com; radiusext@ops.ietf.org > Subject: RE: Request for Review: Chargeable User Identity (CUI) >=20 >=20 > Bernard, >=20 > I am working on some revised text. I should have this ready=20 > tomorrow, and perhaps > resubmit it next week. Would it be more useful to do the=20 > consensus call > on the updated draft? >=20 > John >=20 > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Bernard Aboba > > Sent: 18 November, 2004 20:36 > > To: radiusext@ops.ietf.org > > Subject: Request for Review: Chargeable User Identity (CUI) > >=20 > >=20 > > This is a request for RADEXT WG review of the document=20 > > "Chargeable User > > Identity", for the purpose of determining whether this document is > > suitable for becoming a RADEXT WG work item. So far, the RADEXT WG > > response to the call for interest has been insufficient to=20 > > move forward > > on it. The document is available for inspection here: > >=20 > > http://www.ietf.org/internet-drafts/draft-adrangi-radius-charg > > eable-user-identity-02.txt > >=20 > > The Request for Review will last until December 6, 2004. If you > > believe this document is suitable as a RADEXT WG work item, please > > send email with "CUI: WG Work Item" in the subject. If you=20 > > believe this > > document is unsuitable, please post email with "CUI: Reject" in the > > subject. If you have an Issue, please post it to the RADEXT=20 > > WG mailing list > > (radiusext@ops.ietf.org), using the format described in the=20 > > RADEXT Issues list: > >=20 > > http://www.drizzle.com/~aboba/RADEXT/ > >=20 > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 >=20 > -- > to 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: Thu, 18 Nov 2004 21:13:57 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: Chargeable User Identity (CUI) Date: Thu, 18 Nov 2004 23:12:03 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4320F7@esebe056.ntc.nokia.com> Thread-Topic: Request for Review: Chargeable User Identity (CUI) Thread-Index: AcTNncMVVD2ae7nRTPipJHyMyjP2fAAFWf0g From: To: , Bernard, I am working on some revised text. I should have this ready tomorrow, = and perhaps resubmit it next week. Would it be more useful to do the consensus call on the updated draft? John > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Bernard Aboba > Sent: 18 November, 2004 20:36 > To: radiusext@ops.ietf.org > Subject: Request for Review: Chargeable User Identity (CUI) >=20 >=20 > This is a request for RADEXT WG review of the document=20 > "Chargeable User > Identity", for the purpose of determining whether this document is > suitable for becoming a RADEXT WG work item. So far, the RADEXT WG > response to the call for interest has been insufficient to=20 > move forward > on it. The document is available for inspection here: >=20 > http://www.ietf.org/internet-drafts/draft-adrangi-radius-charg > eable-user-identity-02.txt >=20 > The Request for Review will last until December 6, 2004. If you > believe this document is suitable as a RADEXT WG work item, please > send email with "CUI: WG Work Item" in the subject. If you=20 > believe this > document is unsuitable, please post email with "CUI: Reject" in the > subject. If you have an Issue, please post it to the RADEXT=20 > WG mailing list > (radiusext@ops.ietf.org), using the format described in the=20 > RADEXT Issues list: >=20 > http://www.drizzle.com/~aboba/RADEXT/ >=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: Thu, 18 Nov 2004 18:48:17 +0000 Message-Id: <200411181848.iAIIm2Yr001076@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: Subject: CUI: WG Work Item Date: Thu, 18 Nov 2004 10:48:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcTNnYd+SWaO42mjTTmRBRXmx2cUjgAATAmA -- to 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, 18 Nov 2004 18:36:15 +0000 Date: Thu, 18 Nov 2004 10:36:05 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Request for Review: Chargeable User Identity (CUI) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a request for RADEXT WG review of the document "Chargeable User Identity", for the purpose of determining whether this document is suitable for becoming a RADEXT WG work item. So far, the RADEXT WG response to the call for interest has been insufficient to move forward on it. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt The Request for Review will last until December 6, 2004. If you believe this document is suitable as a RADEXT WG work item, please send email with "CUI: WG Work Item" in the subject. If you believe this document is unsuitable, please post email with "CUI: Reject" in the subject. If you have an Issue, please post it to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the format described in the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 18 Nov 2004 18:25:39 +0000 Date: Thu, 18 Nov 2004 10:25:24 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Request for Review: Carrying Location Objects in RADIUS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a request for RADEXT WG review of the document "Carrying Location Objects in RADIUS". The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-01.txt The Request for Review will last until December 6, 2004. Please post your issues to both the RADEXT WG mailing list (radiusext@ops.ietf.org), and the GEOPRIV WG mailing list (geopriv@ietf.org) using the format described in the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 18 Nov 2004 18:16:10 +0000 Date: Thu, 18 Nov 2004 10:15:41 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Progress on RADIUS Extension for Digest Authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The specification "RADIUS Extension for Digest Authentication" has completed RADEXT WG Last call. Issues filed against the specification are available here: http://www.drizzle.com/~aboba/RADEXT/ The latest version of the specification is available here: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt Further progress on this document requires that we verify that changes made in the -04 document represent RADEXT WG consensus. Since detailed text changes were not posted to the RADEXT WG mailing list prior to the submission of the -04 document, it is not possible to determine whether RADEXT WG consensus exists on the changes based on examination of the mailing list discussion. It is therefore not possible to move forward on this document until this issue is cleared up. In order to make progress, we have made a request that Issue submitters and other WG participants examine the changes in -04 and send email to the WG list, stating whether the changes are acceptable. So far, the mail received indicates the following: Issue 4: No mail received. WG consensus not verified. Issue 5: No mail received, Diameter draft needs to be updated before determining whether the resolutions can work. WG consensus not verified. Issue 6: No mail received. WG consensus not verified. Issue 7: Mail received, indicates WG consensus *against* the proposed resolution. No consensus verified. Issue 8: No mail received, security issues raised at IETF 60. No consensus verified. Issue 11: No mail received. No consensus verified. Issue 12: No mail received. No censensus verified. Given the lack of confirming email, we are at present unable to confirm whether the changes made in -04 represent WG consensus, and in one case (Issue 7) it appears that the proposed resolution has been rejected by the RADEXT WG. In order to enable the WG to demonstrate sufficient interest, we are going to extend the Request for Comment on the proposed resolutions until December 6, 2004. If you have submitted an Issue on the document, and believe it has been resolved, please send mail with "Issue X: Resolved" in the subject line, where X is the Issue number of your issue. If you have additional comments on the specification, or wish to contest the resolution of an issue, please send email to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG mailing list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 18 Nov 2004 17:54:23 +0000 Date: Thu, 18 Nov 2004 09:53:35 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG last call on RFC 2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is an announcement of RADEXT WG Last call on "The Network Access Identifier" specification, RFC 2486bis, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard (recycled). The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt RADEXT WG Last Call will complete on December 8, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 17 Nov 2004 22:13:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv]: Another review of the geopriv radius location attributes draft Date: Wed, 17 Nov 2004 14:12:28 -0800 Message-ID: <53A5D324B48C8C468F0A44D13E6BB26201249307@exchange2.corp.ipass.com> Thread-Topic: [Geopriv]: Another review of the geopriv radius location attributes draft Thread-Index: AcTE+2bf+xE2cxhKTVmGRCyXJej64wBqQwEwAZJ1UxA= From: "Blair T. Bullock" To: "MORAND Lionel RD-CORE-ISS" , "Hannes Tschofenig" , geopriv@ietf.org, "Adrangi, Farid" cc: radiusext@ops.ietf.org, "BOURDON Gilles RD-CORE-ISS" , "FOUQUART Philippe RD-CORE-ISS" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable It is very common practice to introduce Location resolutions from the back-end systems through a RADIUS server and/or policy proxy. That is where the data and intelligence lies and attribute "stuffing" is more and more prevalent in these systems, particularly when the location information requirements (generality/granularity) are variable depending on the consuming entity and multiple policy-based correlations are used to determine such designations (NAS-IP + Framed-Address subnet + proxy target) However, from a standards standpoint, it does not preclude someone from developing proprietary policy and location logic and leverage attribute manipulation to achieve your goals. NAS-level location data features and formal AVP definitions for basic service information exchange is a really good thing whether or not a company decides to preclude them by some other proprietary manipulation. It sure does make first-mile RADIUS diagnosis much easier. At least there is a solid value definition and sound standards-based industry assessment to which we can all use as a baseline. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of MORAND Lionel RD-CORE-ISS Sent: Tuesday, November 09, 2004 1:50 PM To: Hannes Tschofenig; geopriv@ietf.org; Adrangi, Farid Cc: radiusext@ops.ietf.org; BOURDON Gilles RD-CORE-ISS; FOUQUART Philippe RD-CORE-ISS Subject: [Geopriv]: Another review of the geopriv radius location attributes draft Hi, Here are "some" comments and questions on the location attributes draft. As general comments: - User location, network location, etc. should be clearly defined or clarifed each time they are used. - It seems that it is assumed that only the NAS can insert the location information. However, it is likely that this information will be also introduced by a local RADIUS server acting as a proxy (e.g. when the exact location information is not available at the NAS).=20 - It is not described whether this location information will be included in every access-request or only when some criteria are met e.g. based on a given realm. It'd be intersting to spell out these criteria.=20 - If the use of location info in access-request could be optional, a COA explicitly requesting this info (when not received in the initial access-request) could be used by the Home RADIUS server. ************* 1. Introduction Wireless LAN (WLAN) Access Networks (AN) are being deployed in public places such as airports, hotels, shopping malls, and coffee shops by a diverse set of incumbent operators such as cellular carriers (GSM and CDMA), Wireless Internet Service Providers (WISP), and fixed broadband operators.[skip] =20 [skip] Although the proposed attributes in this draft are intended for wireless LAN deployments, they can also be used in other wireless and wired networks where location-aware services are required. =3D=3D> the need goes beyond location-based services for these networks. = The location information may be needed in any roaming situation, to enable the home network to authorize/deny access based on the user's location (network and/or geographical location), whatever the access network technology. Proposal: replace "where location-aware services are required" by "whenever location information is necessary" **************** 3.2 Mid-session Delivery Mid-session delivery method uses the Change of Authorization (COA) message as defined in [RFC3576]. In accordance to [RFC3576], at anytime during the session the AAA server may send the access network a COA message containing session identification attributes (see [RFC3576] for the possible options). The COA message may instruct the access network to generate an Authorize-Only Access-Request (Access-Request with Service-Type set to "Authorize-Only") in which case it is instructing the access network to send the location information attributes. =3D=3D> How does the AAA server instruct the access network to send = location information attributes within the new Access-Request? Is there any specific attribute in the COA indicating that the location information is requested? Or do you assume that any Access-Request sent by the NAS will contain the location information attribute and so case 1 and 2 are the same? ***************** 4.1 Use Case 1 - Use of Location Information in AAA An Operator requires Location Informaion for Authorization and Billing purposes. The operator may deny service if Location Information is not available. Or it may offer limited service. The NAS delivers Location Information to the Home AAA server. =3D=3D> Is there a way for the AAA server to indicate to the access = network that the request failed because the location information is missing? The RADIUS server authenticates and authroizes the session. If the user's location policies are available to the RADIUS server, the RADIUS server may deliver those policies in an Access Accept. This information may be needed if intermediaries or other elements want to act as Location Servers (see Section 4.2). In the absence of receiving the policies intermediaries MUST NOT divulge the location information. =3D=3D> (1) the attributes that convey the policies in the Access-Accept = are not described.=20 =3D=3D> (2) As stated in the section 6 (Policy-Information attribute), policies can also be put by the access network and propagated with Access-Request or Accounting-request. Location Information may also be reported in accouning messages. > edit "accounting" Accounting messages are generated when the session starts, stops and periodically. Accounting messages may also be generated when the user roams during handoff. This information may be needed by the billing system to calculate the users bill. For example, there may be different tarrif rates applied based on the location and their maybe different tax rates applied based on the location. Unless otherwise specified, location information in the accounting stream may not be transmitted to third parties. The location information in the accounting stream MUST only be sent in the proxy chain to the home network (unless specified otherwise). =3D=3D> Do the user's location policies received in the Access-Accept = (in the authorization phase) also apply to Accounting messages? ******************* 4.2 Scenario 2 - Use of Location Information for other Services Location Servers are entities that receive the user's location information and transmit it to other entities. For the purpose of this scenario Location servers are the NAS, and RADIUS servers. The RADIUS servers are in the home network, in the visited network, or in broker networks. Unless otherwise specified, excluding the proxy chain from the NAS to the Home RADIUS, the Location Server may not transmit the location information to other parties. =3D=3D> I think you mean: "Unless otherwise specified, the location = servers MUST NOT transmit the location information to other parties outside the proxy chain between the NAS and the Home RADIUS server".=20 Upon authentication and authorization, the Home RADIUS may transmit the Rule set in an Access-Accept to the other Location Server allowing them to transmit location information. Then and only then they are allowed to share the information. =3D=3D> Is it possible to discriminate parties allowed to distribute the location information to third parties e.g. only the local access network is allowed and not intermediary networks (e.g. brokers)? Note since the NAS is the source of all Location information that is disimenated by RADIUS, the NAS could tag the location information with the location rules or a reference for the location rules received in an Access-Accept. All location information in the Accounting Stream will now be tagged. =3D=3D> Is it so sure that NAS is always the source of location = information? Couldn't we have scenarios where the location information is added by the RADIUS proxy in the visited network, because the NAS is not able to retrieve the user's location for instance? *********************** 5.1 Operator-Name Attribute This attribute contains an operator name which uniquely identifies the ownership of an access network. The Attribute value is a non-NULL terminated string whose Length MUST NOT exceed 253 bytes. The attribute value is comprised of the prefix and the identity, separated by a colon. The prefix identifies the operator type; example: GSM, CDMA, and REALM. The identity uniquely identifies the operator name within the scope of the operator type. =3D=3D> What is the exact meaning of "operator type"? The operator name = is supposed to identify the owner of the access network. Therefore, instead of GSM, CDMA and REALM, would it be better to define something more generic describing the type of access network connected to the NAS? This document defines three operator type prefixes which are: GSM, CDMA, and REALM. The GSM prefix can be used to indicate operator names based on GSMA TADIG codes. REALM can be used by any domain name acquired from IANA. Possible forthcoming operator types MUST be associated with an ogranization responsible for assigning/managing operator names. =3D=3D> Is it really needed to have IANA assigned numbers for prefix (as currently defined)? Prefix and name are just text information. It should be up to the RADIUS end-points to use a common language. Ones could decide to have something based on pref+ID, others something else (e.g. country code+operator/network code). ************************** 5.2 Location-Information Attribute This document describes two formats for conveying location information: civil and geospatial location information. Section 5.2.1 defines the civil location information format. Section 5.2.2 defines the geospatial location information format. Additionally, the Precision field provides further information about the location information provided via Radius. For large networks information about the location of the user can be provided in different degrees of accuracy. This field gives a hint. Ideally the location of the user is returned to the home network but in some cases it might not be available. It has to be noted that the user does not provide the location information itself. =3D=3D> (1) I don't understand the end of this paragraph! What kind of = user location are you referring to here? Whatever the precision and the nature of the location information, the location of the user could always be returned to the home network. Maybe you are talking about the location of the user's end point (which could be far away from the NAS)? =3D=3D> (2) only two formats of location information are defined at this stage: civil and geospatial. What about some "location ID" that could be sent to the AAA server to retrieve location info? I mean that the location info attribute may convey either explicit ("self-explicit") location information or any identifier if there is a mean for the receiver to extract explicit information from this ID, such as the CellID in GSM. ***************************** 6. Policy-Information Attribute In some environments it is possible for the user to attach information about its privacy preferences. These preferences allow the visited network, intermediate RADIUS proxies and the home network to authorize the distribution of the user's location information. =3D=3D> How do these privacy preferences distributed by the Policy-Information attribute in the Access-Request interact with the policies being delivered by the Home RADIUS server in the Access-Accept? ***************************** 9.1 Operator-Name Attribute Operator-Name Attribute SHOULD be sent in Access-Request, and Accounting-Request records where the Acc-Status-Type is set to Start, Interim, or Stop. A summary of the Operator-Name Attribute is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Operator-Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: To Be Assigned by IANA - Operator-Name Length: >=3D 3 Operator-Name: The text field contains an Access Network Operator Name in prefix-based format as describe above. Example: REALM:anyisp.com =3D=3D> If the prefix is put in the "Operator-Name" field in text format = and if it keeps the current signification, there is no reason IMHO to have IANA-assigned numbers. Otherwise, we could have a separate field describing the operator type (whaterver the meaning of this parameter) as defined below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Operator-Type | Operator-Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ************************************* 9.2 Location-Information Attribute Location-Information attribute SHOULD be sent in Access-Request, and Accounting-Request records where the Acc-Status-Type is set to Start, Interim or Stop if available. The Location-Information Attribute has two variations depending on civil or geospatial location information. The format is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Code | Precision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location-Info ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (8 bits): To Be Assigned by IANA - Location-Information Length (8 bits): >=3D 3 Code (8 bits): Describes which location format is carried in this attribute: (0) describes civil location information (1) describes geospatial location information All other bites of the Code field is reserved and required for alignment. =3D=3D> it is proposed to add a value (2) for location ID Precision (8 bits): Describes which location this attribute refers to: (0) describes the location of the NAS (1) describes the location of the AAA server (2) describes the location of the end host (user) (3) describes the location of the network =3D=3D> What is the meaning of the fourth value? How could it be = possible to have less than the NAS or the visited RADIUS location information? BR, Lionel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Nov 2004 18:00:58 +0000 Message-ID: From: Avi Lior To: 'Miguel Garcia' , "Beck01, Wolfgang" , Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Cc: AAA mailing list , radiusext@ops.ietf.org Subject: RE: [AAA-WG]: Reconciling Radius/Diameter SIP application Date: Thu, 11 Nov 2004 12:59:31 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, Wrt to UTF8String in diameter and lack of support in RADIUS. Well would the RADIUS type TEXT work for you? Text is defined in 2865 as "Text contains UTF-8 encoded 10646 [7] characters" > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Thursday, November 11, 2004 8:55 AM > To: Beck01, Wolfgang; Mari Carmen belinchon; Miguel-Angel > Pallares; ext Carolina Canales (ML/EEM); Pete McCann; > Rajaniemi Jaakko Matti; Tammi Kalle Tapani > Cc: AAA mailing list; radiusext@ops.ietf.org > Subject: [AAA-WG]: Reconciling Radius/Diameter SIP application > > > Hi: > > I am deliberately cross posting to AAA and Radius-ext because > I believe > this topic is of interest for both lists. > > Yesterday Wolfgang and me met for a few hours and set the goal of > reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest > drafts. These are the drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si > p-app-04.txt > > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt > > These are the main points we discuss. If you have any > comments, speak up > now, otherwise we will do the proposed changes in the relevant drafts: > > 1- We agreed to modify the Diameter SIP application so that > it imports > the Digest-* AVP from the corresponding RADIUS attributes > address space. This came out of a comment from Jari Arkko, > and I think it is important > to avoid duplication of AVP/attributes. > > As a side effect of the above, the SIP-Authentication-Context will > disappear in Diameter SIP app. This was a grouped AVP that only > contained a Digest-Entity-Body-Hash AVP. The latter will > remain (in the > RADIUS draft). > > 2- We noticed a divergence in the Digest-Expected-Response AVP in > Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 > attribute. The difference: Digest-HA1 contains H(A1), which > is computed > at the Radius server and sent to the Radius client, and it is used to > compute the expected response. In Diameter, the expected response is > computed at the Diameter server and sent to the client. This > assumes a > secure connection to avoid eavesdropping, which is not a problem for > Diameter that mandates IPsec or TLS. I think Diameter can go for the > Radius approach for compatibility reasons. > > Proposal: Diameter will remove Digest-Expected-Response AVP and will > import Digest-HA1 from Radius. > > 3- Radius does not define UTF8String data types, so all these > attributes > will remain as String, but the Radius draft will indicate > that contain a UTF8String verbally (this is required by HTTP and SIP). > > 4- Currently here is a divergence on the definition of Digest-Stale > attribute: Diameter uses "true" and "false" (as per RFC2617), Radius > uses 1 and 0. We agreed to use "true" and "false" to avoid stupid > transcodings. > > 5- Diameter indicates that the Digest-* AVPs contain the > quotes from/to > the Digest directive, Radius assumes (although does not indicate) no > quotes. We agreed that the Digest-* attributes do not need to include > the quotes from HTTP Digest parameters. So, there will be an explicit > indication that quotes are not part of the attribute value. > > 6- We run into a problem when multiple SIP proxies are > authenticating the user, because at some point in time the > SIP request may contain several Proxy-Authorization headers. > The key here is the realm, it will be always different. If > different Diameter/Radius servers are > serving different realms, there is not problem. But, if a common > Diameter/Radius server is serving different realms, then the > server is > not able to determine which credentials should be evaluated. > > We propose that the Diameter/Radius client MUST send only one set of > credentials at a time, those belonging to the served realm. This > requires to configure the Diameter/Radius client with the realm it is > serving. We will include some text indicating this case. > > 7- Some of the attributes (e.g, Digest-Response and > Digest-Response-Auth) had an artificial limit of 32 octets in > the value. While this value is correct for MD5 hashes, if in > the future other hashes are added to HTTP Digest, will run > into trouble. Proposal: don't restrict the length of a value. > > 8- In the Radius document, scenario 1, we have a question. We > suspect that this scenario does not work if the Radius client > generates a nextnonce. The reason is that in the following > authentication, when the nextnonce becomes a nonce, the > Radius server will not recognize the nonce as locally > generated (it was generated by the Radius client), and > will reject the request with a "state=true". RFC 2617 seems > to describe > the case: > > If the > nextnonce field is present the client SHOULD use it when > constructing > the Authorization header for its next request. Failure of > the client > to do so may result in a request to re-authenticate from > the server > with the "stale=TRUE". > > Does anyone have any comment? Can anyone confirm that the > operation in > Digest is as we indicate? We will add some text indicating the > limitations of Scenario 1. > > 9- The Radius draft, in section 2.15, indicates: > > RADIUS > servers that do not implement a parameter contained in a > Digest-Auth-Param attribute MUST respond with an > Access-Reject > message. RADIUS clients that do not implement a parameter > contained in a Digest-Auth-Param attribute MUST reject the > original HTTP-style request. > > The problem is that the text seems to go against RFC 2617 that says: > > auth-param > This directive allows for future extensions. Any unrecognized > directive MUST be ignored. > > The proposal is to remove the above text from the RADIUS draft. > > > 10- Similar contradictory text was found in Section 2.16 of > the RADIUS > draft, that says: > > RADIUS servers that do > not implement AKA Digest MUST response with an Access Reject > message. > > We propose to remove the above text. The motivation is that the > algorithm already conveys the AKA (AKA extends the algorithm to be > AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the > algorithm, so the > situation currently described, where the client may include an auts > attribute, is just an error case, where the client made a mistake and > included AUTS when not doing AKA. In case the Radius server does not > implement AKA authentication, it will safely ignore this AVP. > > 11- We noticed that most of the HTTP Digest directives contain just a > single token. However, the "qop" directive may contain a > comma-separated > collection of tokens. For instance, qop="auth,auth-int". The > question is > how do encode these tokens in the Digest-Qop attribute. The > options are: > > a) Treat the whole thing as one token and put it into the > attribute value. > b) Each token is an attribute, thus, there might be multiple > Digest-Qop > attributes in a particular Radius/Diameter message. > > We think that option b) is cleaner. Particularly it will be > easier for > the Diameter/Radius client to encode different values in different > attributes. > > Any comments to any of the above? > > Regards, > > Miguel > > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 10 Nov 2004 19:12:47 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , MORAND Lionel RD-CORE-ISS Cc: geopriv@ietf.org, radiusext@ops.ietf.org, Hannes Tschofenig , BOURDON Gilles RD-CORE-ISS , FOUQUART Philippe RD-CORE-ISS Subject: RE: [Geopriv]: Another review of the geopriv radius location attr ibutes draft Date: Wed, 10 Nov 2004 14:12:14 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Bernard and Lionel, > > ==> How does the AAA server instruct the access network to send > > location information attributes within the new Access-Request? Is > > there any specific attribute in the COA indicating that the > location > > information is requested? Or do you assume that any Access-Request > > sent by the NAS will contain the location information > attribute and so > > case 1 and 2 are the same? > > RFC 3576 does not use attributes in the CoA-Request in order > to request attributes in a subsequent Access-Request. Nor > does it make sense to include location attributes in a > CoA-Request. The session to which the CoA applies is not > selected using location attributes, nor is the request that > the NAS change its location -- "Please move NAS17483 to > Cleveland, Ohio." I agree with Bernard, and we don't send location attributes to the NAS in COA Request. I think that the text is confusing: "The COA message may instruct the access network to generate an Authorize-Only Access-Request (Access-Request with Service-Type set to "Authorize-Only") in which case it is instructing the access network to send the location information attributes." May be we should say: "The COA message may instruct the access network to generate an Authorize-Only Access-Request (Access-Request with Service-Type set to "Authorize-Only") in which case the NAS MUST include the location infromation in this Access-Request." > > ==> Is there a way for the AAA server to indicate to the access > > network that the request failed because the location information is > > missing? > > See RFC 3576 Error-Cause attribute, value 402 (Missing Attribute) I don't think that we can use the Error-Cause attribute. It is only available in COA ACK/NAK messages. So the AAA has no way to tell the NAS that it is missing the location attribute. I don't think that this attribute can be placed in an Access-Reject message. What do you think Bernard? -- to 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, 09 Nov 2004 23:30:09 +0000 Date: Tue, 9 Nov 2004 15:29:45 -0800 (PST) From: Bernard Aboba To: MORAND Lionel RD-CORE-ISS cc: Hannes Tschofenig , geopriv@ietf.org, "Adrangi, Farid" , radiusext@ops.ietf.org, BOURDON Gilles RD-CORE-ISS , FOUQUART Philippe RD-CORE-ISS Subject: Re: [Geopriv]: Another review of the geopriv radius location attributes draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > ==> How does the AAA server instruct the access network to send location > information attributes within the new Access-Request? Is there any > specific attribute in the COA indicating that the location information > is requested? Or do you assume that any Access-Request sent by the NAS > will contain the location information attribute and so case 1 and 2 are > the same? RFC 3576 does not use attributes in the CoA-Request in order to request attributes in a subsequent Access-Request. Nor does it make sense to include location attributes in a CoA-Request. The session to which the CoA applies is not selected using location attributes, nor is the request that the NAS change its location -- "Please move NAS17483 to Cleveland, Ohio." > ==> Is there a way for the AAA server to indicate to the access network > that the request failed because the location information is missing? See RFC 3576 Error-Cause attribute, value 402 (Missing Attribute) > ==> Is it so sure that NAS is always the source of location information? > Couldn't we have scenarios where the location information is added by > the RADIUS proxy in the visited network, because the NAS is not able to > retrieve the user's location for instance? This seems quite likely, in fact. > ==> (1) I don't understand the end of this paragraph! What kind of user > location are you referring to here? Whatever the precision and the > nature of the location information, the location of the user could > always be returned to the home network. Maybe you are talking about the > location of the user's end point (which could be far away from the NAS)? I was confused about this as well. > ==> What is the meaning of the fourth value? How could it be possible to > have less than the NAS or the visited RADIUS location information? I don't understand this either. -- to 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, 09 Nov 2004 21:51:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Geopriv]: Another review of the geopriv radius location attributes draft Date: Tue, 9 Nov 2004 22:50:06 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026018B4220@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [Geopriv]: Another review of the geopriv radius location attributes draft Thread-Index: AcTE+2bf+xE2cxhKTVmGRCyXJej64wBqQwEw From: "MORAND Lionel RD-CORE-ISS" To: "Hannes Tschofenig" , , "Adrangi, Farid" Cc: , "BOURDON Gilles RD-CORE-ISS" , "FOUQUART Philippe RD-CORE-ISS" Hi, Here are "some" comments and questions on the location attributes draft. As general comments: - User location, network location, etc. should be clearly defined or clarifed each time they are used. - It seems that it is assumed that only the NAS can insert the location information. However, it is likely that this information will be also introduced by a local RADIUS server acting as a proxy (e.g. when the exact location information is not available at the NAS).=20 - It is not described whether this location information will be included in every access-request or only when some criteria are met e.g. based on a given realm. It'd be intersting to spell out these criteria.=20 - If the use of location info in access-request could be optional, a COA explicitly requesting this info (when not received in the initial access-request) could be used by the Home RADIUS server. ************* 1. Introduction Wireless LAN (WLAN) Access Networks (AN) are being deployed in public places such as airports, hotels, shopping malls, and coffee shops by a diverse set of incumbent operators such as cellular carriers (GSM and CDMA), Wireless Internet Service Providers (WISP), and fixed broadband operators.[skip] =20 [skip] Although the proposed attributes in this draft are intended for wireless LAN deployments, they can also be used in other wireless and wired networks where location-aware services are required. =3D=3D> the need goes beyond location-based services for these networks. = The location information may be needed in any roaming situation, to enable the home network to authorize/deny access based on the user's location (network and/or geographical location), whatever the access network technology. Proposal: replace "where location-aware services are required" by "whenever location information is necessary" **************** 3.2 Mid-session Delivery Mid-session delivery method uses the Change of Authorization (COA) message as defined in [RFC3576]. In accordance to [RFC3576], at anytime during the session the AAA server may send the access network a COA message containing session identification attributes (see [RFC3576] for the possible options). The COA message may instruct the access network to generate an Authorize-Only Access-Request (Access-Request with Service-Type set to "Authorize-Only") in which case it is instructing the access network to send the location information attributes. =3D=3D> How does the AAA server instruct the access network to send = location information attributes within the new Access-Request? Is there any specific attribute in the COA indicating that the location information is requested? Or do you assume that any Access-Request sent by the NAS will contain the location information attribute and so case 1 and 2 are the same? ***************** 4.1 Use Case 1 - Use of Location Information in AAA An Operator requires Location Informaion for Authorization and Billing purposes. The operator may deny service if Location Information is not available. Or it may offer limited service. The NAS delivers Location Information to the Home AAA server. =3D=3D> Is there a way for the AAA server to indicate to the access = network that the request failed because the location information is missing? The RADIUS server authenticates and authroizes the session. If the user's location policies are available to the RADIUS server, the RADIUS server may deliver those policies in an Access Accept. This information may be needed if intermediaries or other elements want to act as Location Servers (see Section 4.2). In the absence of receiving the policies intermediaries MUST NOT divulge the location information. =3D=3D> (1) the attributes that convey the policies in the Access-Accept = are not described.=20 =3D=3D> (2) As stated in the section 6 (Policy-Information attribute), policies can also be put by the access network and propagated with Access-Request or Accounting-request. Location Information may also be reported in accouning messages. > edit "accounting" Accounting messages are generated when the session starts, stops and periodically. Accounting messages may also be generated when the user roams during handoff. This information may be needed by the billing system to calculate the users bill. For example, there may be different tarrif rates applied based on the location and their maybe different tax rates applied based on the location. Unless otherwise specified, location information in the accounting stream may not be transmitted to third parties. The location information in the accounting stream MUST only be sent in the proxy chain to the home network (unless specified otherwise). =3D=3D> Do the user's location policies received in the Access-Accept = (in the authorization phase) also apply to Accounting messages? ******************* 4.2 Scenario 2 - Use of Location Information for other Services Location Servers are entities that receive the user's location information and transmit it to other entities. For the purpose of this scenario Location servers are the NAS, and RADIUS servers. The RADIUS servers are in the home network, in the visited network, or in broker networks. Unless otherwise specified, excluding the proxy chain from the NAS to the Home RADIUS, the Location Server may not transmit the location information to other parties. =3D=3D> I think you mean: "Unless otherwise specified, the location = servers MUST NOT transmit the location information to other parties outside the proxy chain between the NAS and the Home RADIUS server".=20 Upon authentication and authorization, the Home RADIUS may transmit the Rule set in an Access-Accept to the other Location Server allowing them to transmit location information. Then and only then they are allowed to share the information. =3D=3D> Is it possible to discriminate parties allowed to distribute the location information to third parties e.g. only the local access network is allowed and not intermediary networks (e.g. brokers)? Note since the NAS is the source of all Location information that is disimenated by RADIUS, the NAS could tag the location information with the location rules or a reference for the location rules received in an Access-Accept. All location information in the Accounting Stream will now be tagged. =3D=3D> Is it so sure that NAS is always the source of location = information? Couldn't we have scenarios where the location information is added by the RADIUS proxy in the visited network, because the NAS is not able to retrieve the user's location for instance? *********************** 5.1 Operator-Name Attribute This attribute contains an operator name which uniquely identifies the ownership of an access network. The Attribute value is a non-NULL terminated string whose Length MUST NOT exceed 253 bytes. The attribute value is comprised of the prefix and the identity, separated by a colon. The prefix identifies the operator type; example: GSM, CDMA, and REALM. The identity uniquely identifies the operator name within the scope of the operator type. =3D=3D> What is the exact meaning of "operator type"? The operator name = is supposed to identify the owner of the access network. Therefore, instead of GSM, CDMA and REALM, would it be better to define something more generic describing the type of access network connected to the NAS? This document defines three operator type prefixes which are: GSM, CDMA, and REALM. The GSM prefix can be used to indicate operator names based on GSMA TADIG codes. REALM can be used by any domain name acquired from IANA. Possible forthcoming operator types MUST be associated with an ogranization responsible for assigning/managing operator names. =3D=3D> Is it really needed to have IANA assigned numbers for prefix (as currently defined)? Prefix and name are just text information. It should be up to the RADIUS end-points to use a common language. Ones could decide to have something based on pref+ID, others something else (e.g. country code+operator/network code). ************************** 5.2 Location-Information Attribute This document describes two formats for conveying location information: civil and geospatial location information. Section 5.2.1 defines the civil location information format. Section 5.2.2 defines the geospatial location information format. Additionally, the Precision field provides further information about the location information provided via Radius. For large networks information about the location of the user can be provided in different degrees of accuracy. This field gives a hint. Ideally the location of the user is returned to the home network but in some cases it might not be available. It has to be noted that the user does not provide the location information itself. =3D=3D> (1) I don't understand the end of this paragraph! What kind of = user location are you referring to here? Whatever the precision and the nature of the location information, the location of the user could always be returned to the home network. Maybe you are talking about the location of the user's end point (which could be far away from the NAS)? =3D=3D> (2) only two formats of location information are defined at this stage: civil and geospatial. What about some "location ID" that could be sent to the AAA server to retrieve location info? I mean that the location info attribute may convey either explicit ("self-explicit") location information or any identifier if there is a mean for the receiver to extract explicit information from this ID, such as the CellID in GSM. ***************************** 6. Policy-Information Attribute In some environments it is possible for the user to attach information about its privacy preferences. These preferences allow the visited network, intermediate RADIUS proxies and the home network to authorize the distribution of the user's location information. =3D=3D> How do these privacy preferences distributed by the Policy-Information attribute in the Access-Request interact with the policies being delivered by the Home RADIUS server in the Access-Accept? ***************************** 9.1 Operator-Name Attribute Operator-Name Attribute SHOULD be sent in Access-Request, and Accounting-Request records where the Acc-Status-Type is set to Start, Interim, or Stop. A summary of the Operator-Name Attribute is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Operator-Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: To Be Assigned by IANA - Operator-Name Length: >=3D 3 Operator-Name: The text field contains an Access Network Operator Name in prefix-based format as describe above. Example: REALM:anyisp.com =3D=3D> If the prefix is put in the "Operator-Name" field in text format = and if it keeps the current signification, there is no reason IMHO to have IANA-assigned numbers. Otherwise, we could have a separate field describing the operator type (whaterver the meaning of this parameter) as defined below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Operator-Type | Operator-Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ************************************* 9.2 Location-Information Attribute Location-Information attribute SHOULD be sent in Access-Request, and Accounting-Request records where the Acc-Status-Type is set to Start, Interim or Stop if available. The Location-Information Attribute has two variations depending on civil or geospatial location information. The format is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Code | Precision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location-Info ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (8 bits): To Be Assigned by IANA - Location-Information Length (8 bits): >=3D 3 Code (8 bits): Describes which location format is carried in this attribute: (0) describes civil location information (1) describes geospatial location information All other bites of the Code field is reserved and required for alignment. =3D=3D> it is proposed to add a value (2) for location ID Precision (8 bits): Describes which location this attribute refers to: (0) describes the location of the NAS (1) describes the location of the AAA server (2) describes the location of the end host (user) (3) describes the location of the network =3D=3D> What is the meaning of the fourth value? How could it be = possible to have less than the NAS or the visited RADIUS location information? BR, Lionel -- to 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, 08 Nov 2004 16:09:45 +0000 Date: Mon, 8 Nov 2004 08:09:16 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Slides from IETF61 Presentations available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is the link: http://www.drizzle.com/~aboba/RADEXT/IETF61/ -- to 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, 08 Nov 2004 14:35:57 +0000 Message-ID: <418F83BE.20609@piuha.net> Date: Mon, 08 Nov 2004 16:33:34 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Nelson, David" Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" Subject: Re: alternatives for carrying eap lower layer information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson, David wrote: > Jari writes ... > > >>Yes, that was my question. I can certainly see this happening, >>but I'm uncertain if RFC 2868 is able to cope with it. > > > I don't think it would. Since service provisioning in RADIUS is a > result of authentication (and authorization) I'm unsure how RADIUS would > address the set-up of a tunnel that is pre-requisite to the > authentication process. That's what the incoming tunnel in this "two > tunnel" scenario would be, right? Well, RADIUS *is* helping to create the incoming tunnel too -- just think of IKEv2 EAP authentication in a situation where the IKEv2 GW doesn't have the user database internally. Now, if the GW is also doing some sort of mandatory tunneling for the traffic, then we are in essence doing both at the same time. Note: I do not have a good example why both tunnels would be needed at the same time, but I'm sure the innovative service providers or SDOs will come up with some network scenario where they need this :-) --Jari -- to 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, 08 Nov 2004 14:21:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: alternatives for carrying eap lower layer information Date: Mon, 8 Nov 2004 06:20:47 -0800 Message-ID: <53A5D324B48C8C468F0A44D13E6BB262010477EC@exchange2.corp.ipass.com> Thread-Topic: alternatives for carrying eap lower layer information Thread-Index: AcTFlHONXue4o9O2REqYzRsyiMHN/QABg8YA From: "Blair T. Bullock" To: jari.arkko@piuha.net cc: radiusext@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sorry if this comment is not very salient to this thread.... I like that level of clarification of virtual transport since it seems to be a trend to make everything a VIRTUAL N-P-T simply because it is not of a single distinct interface type and may also encompass non-physical transport which is not explicitly defined. Such as an Access Gateway that feeds both ENET and 802.11 Access Points, but uses L2TP for transport.... What N-P-T is it?! Aw, heck let's just call it Virtual. =3D^( =20 What I don't get is why include Auth Methods such as PANA and PEAP? The Nas-Port-Type should describe the consumed (inbound) service as stated in this thread. Today it is commonly used to differentiate and bill consumed services at different rates based on Media used by the STA, but unfortunately we have cases where dial, Wi-Fi and Ethernet NAS set all N-P-T to Virtual; regardless. PEAP can be used over Ethernet and Wi-Fi, so to claim a N-P-T of PEAP is just as ambiguous as to the consumed service is it not? Could these virtual transport and multi-use protocol extensions allow this to break-down into an ambiguous mess? Thanks for your time,=20 Blair -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Jari Arkko Sent: Monday, November 08, 2004 5:06 AM To: Bernard Aboba Cc: 'radiusext@ops.ietf.org'; David Mariblanca (EE/EEM) Subject: Re: alternatives for carrying eap lower layer information Bernard Aboba wrote: > There are multiple problems being discussed here:=20 >=20 > a. Ability to differentiate tunneled EAP methods (PEAP, EAP-IKEv2, etc.) from non-tunneled EAP methods.=20 >=20 > b. Ability to differentiate EAP lower layers from one another (EAP-IKEv2). >=20 > In terms of problem a), the EAP peer and server know what EAP method is being negotiated (and whether it is tunneled), but the NAS is presumed to be a pass-through. Therefore, I am not clear how the NAS would obtain information on the EAP method to put into an attribute, unless it gets this from the RADIUS server. =20 Yes, it seems you are right. The endpoints of the two methods should always be the same, so there is no need to tell the distinction to anyone. > In terms of problem b), it seems that the problem arises in part from the allocation of a single NAS-Port-Type (Virtual) to all tunnels. In contrast, in RFC 2868 the combination of Tunnel-Type and Tunnel-Medium-Type attributes enables description of virtually any tunnel type over any medium. I'd suggest that this approach is more sound than trying to allocate a NAS-Port-Type value for every conceivable combination.=20 I think you are right on this one also. But are you suggesting that these attributes be used, or just that the same idea of separating this into two steps makes sense? I think you must mean the latter, because it seems that RFC 2868 is targeted towards mandatory tunneling, i.e., something that happens after the traffic leaves the NAS. What we are talking about here is a service provided as a tunnel, something that happens before the traffic enters the NAS. This might lead to a confusion if the same attributes were used, or am I missing something? Presumably you could have both a virtual service coming in and a mandatory tunnel going out... If I am right we should do the following: 1. Use the NAS-Port-Type as the primary differentiator between different kinds of incoming connections to NAS. If its 802.11, use value 19. If its IKEv2 or any other sort of non-physical interface, use 5 (Virtual). Allocate a new value for PANA. 2. Then, if 5 (Virtual) was used above, define a new attribute that indicates the type of the virtual device. NAS-Virtual-Port-Type 1 (IKEv2) 2 ... 3. Optionally, define another attribute that also defines the type of protocol that this virtual service run on top of (e.g., IPv4 or IPv6). This would work for me, I think. The crucial question is whether the RFC 2868 attributes can be used for this purpose or if new ones are needed because the mandatory tunneling vs. incoming usage collides. Opinions? --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 08 Nov 2004 13:47:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: alternatives for carrying eap lower layer information Date: Mon, 8 Nov 2004 08:44:51 -0500 Message-ID: Thread-Topic: alternatives for carrying eap lower layer information Thread-Index: AcTFl+e6KZPYsiKcTz2xs9ei3/RdOAAALLeg From: "Nelson, David" To: Cc: , "David Mariblanca \(EE/EEM\)" Jari writes ... > Yes, that was my question. I can certainly see this happening, > but I'm uncertain if RFC 2868 is able to cope with it. I don't think it would. Since service provisioning in RADIUS is a result of authentication (and authorization) I'm unsure how RADIUS would address the set-up of a tunnel that is pre-requisite to the authentication process. That's what the incoming tunnel in this "two tunnel" scenario would be, right? -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 08 Nov 2004 13:36:13 +0000 Message-ID: <418F75D2.7060901@piuha.net> Date: Mon, 08 Nov 2004 15:34:10 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Nelson, David" Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" Subject: Re: alternatives for carrying eap lower layer information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson, David wrote: > Is the potential for confusion because one might have *both* an incoming > tunnel service (potentially terminating at the NAS) and an outgoing > tunnel service for the same connection? Yes, that was my question. I can certainly see this happening, but I'm uncertain if RFC 2868 is able to cope with it. --Jari -- to 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, 08 Nov 2004 13:24: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: alternatives for carrying eap lower layer information Date: Mon, 8 Nov 2004 08:23:18 -0500 Message-ID: Thread-Topic: alternatives for carrying eap lower layer information Thread-Index: AcTFlB9cQdjVSz1uT7GLDe31MUzYgwAAUsaQ From: "Nelson, David" To: Cc: , "David Mariblanca \(EE/EEM\)" Jari Writes... > The crucial question is whether the RFC 2868 attributes can > be used for this purpose or if new ones are needed because > the mandatory tunneling vs. incoming usage collides. Opinions? Is the potential for confusion because one might have *both* an incoming tunnel service (potentially terminating at the NAS) and an outgoing tunnel service for the same connection? Re-use of attributes seems OK to me as long as the semantics are the same (or at least analogous) and the context of interpretation is unambiguous. If there is the potential for confusion, it would be preferable to have a distinct attribute. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 08 Nov 2004 13:08:30 +0000 Message-ID: <418F6F49.10000@piuha.net> Date: Mon, 08 Nov 2004 15:06:17 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: "'radiusext@ops.ietf.org'" , "David Mariblanca (EE/EEM)" Subject: Re: alternatives for carrying eap lower layer information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > There are multiple problems being discussed here: > > a. Ability to differentiate tunneled EAP methods (PEAP, EAP-IKEv2, etc.) from non-tunneled EAP methods. > > b. Ability to differentiate EAP lower layers from one another (EAP-IKEv2). > > In terms of problem a), the EAP peer and server know what EAP method is being negotiated (and whether it is tunneled), but the NAS is presumed to be a pass-through. Therefore, I am not clear how the NAS would obtain information on the EAP method to put into an attribute, unless it gets this from the RADIUS server. Yes, it seems you are right. The endpoints of the two methods should always be the same, so there is no need to tell the distinction to anyone. > In terms of problem b), it seems that the problem arises in part from the allocation of a single NAS-Port-Type (Virtual) to all tunnels. In contrast, in RFC 2868 the combination of Tunnel-Type and Tunnel-Medium-Type attributes enables description of virtually any tunnel type over any medium. I'd suggest that this approach is more sound than trying to allocate a NAS-Port-Type value for every conceivable combination. I think you are right on this one also. But are you suggesting that these attributes be used, or just that the same idea of separating this into two steps makes sense? I think you must mean the latter, because it seems that RFC 2868 is targeted towards mandatory tunneling, i.e., something that happens after the traffic leaves the NAS. What we are talking about here is a service provided as a tunnel, something that happens before the traffic enters the NAS. This might lead to a confusion if the same attributes were used, or am I missing something? Presumably you could have both a virtual service coming in and a mandatory tunnel going out... If I am right we should do the following: 1. Use the NAS-Port-Type as the primary differentiator between different kinds of incoming connections to NAS. If its 802.11, use value 19. If its IKEv2 or any other sort of non-physical interface, use 5 (Virtual). Allocate a new value for PANA. 2. Then, if 5 (Virtual) was used above, define a new attribute that indicates the type of the virtual device. NAS-Virtual-Port-Type 1 (IKEv2) 2 ... 3. Optionally, define another attribute that also defines the type of protocol that this virtual service run on top of (e.g., IPv4 or IPv6). This would work for me, I think. The crucial question is whether the RFC 2868 attributes can be used for this purpose or if new ones are needed because the mandatory tunneling vs. incoming usage collides. Opinions? --Jari -- to 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, 08 Nov 2004 06:27:01 +0000 Date: Sun, 7 Nov 2004 22:26:31 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Presentations, please Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As usual, in RADEXT WG we will be preloading the presentations onto a single laptop. So if you're going to be presenting tommorrow, please send in your presentations ASAP. the wireless network has been somewhat unreliable so if you have a USB dongle, you might want to bring it as well. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 08 Nov 2004 00:52:24 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: New version of IEEE 802 Attributes Draft Available Date: Sun, 07 Nov 2004 20:03:11 -0500 Message-Id: <20041108010311.3C79D16FAB@mail.nitros9.org> http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt > 2.1. Egress-VLANID > > Description > > The Egress-VLANID attribute represents an allowed IEEE 802 Egress > VLANID for this port. The Egress-VLANID contains two parts: the > first part is the VLANID, the second part indicates if this VLANID > is allowed for tagged or untagged packets. The text following this doesn't define the attribute format, or where the VLANID goes. ASCII art would be appreciated. Section 1.2 talks about possibly using the "extended attribute" format, and says that the following lengths are calculated using the short form. If so, for consistency, ASCII art of the attributes showing the short form would be good, even if there isn't consensus that it's the proper format to use. Also, the data types are "Integer32" and "UInt32". Are these RADIUS types, or new types? It should be clarified as to where these types come from. >2.3. VLAN-Name > > Description ... > The VLAN-Name attribute contains two parts; the first part is the > VLAN name, the second part indicates if frames on the VLAN for > this port are to be represented in tagged or untagged format. I suggest arranging the attribute so that the "tagged/untagged" information is at the same offset in the attribute as the Egress-VLANID attribute. Putting the value after variable-length "String" data makes it harder to parse. Putting the value in a different place than in the Egress-VLANID attribute creates more "special-case" considerations in the code. > 2.4. User-Priority-Table ... > Data-Type > > UInt64 Q: Is this the first proposed 64-bit integer data type in RADIUS? >2.12. Origin-Realm > > Description > > The Origin-Realm attribute contains the realm of the originator of > a message, as described in [RFC3588], Section 6.4. Add missing text: This attribute is defined as an Extended RADIUS attribute. > 3.1. Accounting-EAP-Auth-Method ... >Value > > The Value field is eight octets. In case of expanded types > defined in [RFC3748] Section 5.7, the least significant 32 bits > contain the Vendor-Type field, and the next 24 bits contain the > Vendor-Id field. Leaving 8 bits of... what? Again, ASCII art, even using the proposed format from Appendix A would help clarify the attribute. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 08 Nov 2004 00:48:23 +0000 Date: Sun, 7 Nov 2004 16:48:14 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Final RADEXT Agenda for IETF 61 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RADEXT WG Agenda Monday, November 8, 2004 0900 - 1130 Chairs: Bernard Aboba David Nelson Preliminaries (10 minutes) Minutes Bluesheets Agenda Bash Document Status WG Milestones Documents in WG Last Call RFC 2486bis, Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt RADIUS Extension for Digest Authentication, Wolfgang Beck (15 minutes) http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt Location RADIUS Location Attributes - Hannes Tschofenig (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-01.txt LAN Applications LAN attributes - Paul Congdon (10 minutes) http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt Bandwidth Attributes - Farid Adrangi (5 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-01.txt Re-direction Support - Avi Lior (5 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt EAP lower layer attribues for AAA protocols - Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-01.txt Accounting Chargeable User Identity - Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt RADIUS Prepaid - Avi Lior (10 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-06.txt Management IPv6 support in the RADIUS MIBs - Dave Nelson (2 minutes) http://www.ietf.org/rfc/rfc2618.txt http://www.ietf.org/rfc/rfc2619.txt http://www.ietf.org/rfc/rfc2620.txt http://www.ietf.org/rfc/rfc2621.txt RFC 3576 MIBs - M. Chiba (5 minutes) http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt Wrapup -- to 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, 08 Nov 2004 00:05:12 +0000 Date: Sun, 7 Nov 2004 16:04:51 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: New version of IEEE 802 Attributes Draft Available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A new version of the IEEE 802 attributes draft has been prepared. Paul Congdon has asked me to make the new version of the document available for your examination: http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt Please send comments to the RADEXT WG mailing list. -- to 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, 07 Nov 2004 20:29:32 +0000 Message-ID: <418E8523.8000900@piuha.net> Date: Sun, 07 Nov 2004 22:27:15 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Henning Schulzrinne Cc: "'radiusext@ops.ietf.org'" , Hannes Tschofenig , geopriv@ietf.org Subject: Re: [Geopriv] review of the geopriv radius location attributes draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> draft-ietf-simple-rpid-04.txt section 3.5. > > > I believe there was agreement on that earlier. Great! > See also > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt, > Section 2.2.3. While the two are the same, there is no reference to the > PIDF-LO registry. Since it seems silly to have two different ones, this > should be called out. OK, I didn't realize that. Yes, it should be the same. --Jari -- to 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, 07 Nov 2004 18:54:19 +0000 Message-ID: <418E6F3D.1040500@cs.columbia.edu> Date: Sun, 07 Nov 2004 13:53:49 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) MIME-Version: 1.0 To: jari.arkko@piuha.net CC: "'radiusext@ops.ietf.org'" , Hannes Tschofenig , geopriv@ietf.org Subject: Re: [Geopriv] review of the geopriv radius location attributes draft Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jari Arkko wrote: > >> 0 Reserved >> 1 Coffee Shop ... >> 14 Educational Institute >> 15 Public Place >> 16 Other > > > This list feels a bit restrictive. What about "Car" > or "Healt Institute" or a coffee shop in an airport? > Suggestion: use the value set (and IANA process) from > draft-ietf-simple-rpid-04.txt section 3.5. I believe there was agreement on that earlier. >> Method (8 bits): >> Describes the way that the location information was >> derived or discovered. The following values are currently >> defined: >> (0) Global Positioning System (GPS) >> (1) GPS with assistance (A-GPS) >> (2) Manual configured information >> (3) Provided by DHCP >> (4) Triangulation: triangulated from time-of-arrival, >> signal strength or similar measurements >> (5) Cell: location of the cellular radio antenna >> (6) IEEE 802.11 WLAN access point > > > I'd like to make this list a bit more technology independent. > Or, its OK to give the location information determination > method (such as A-GPS), but I don't think you should tie it > to the access technology. Suggest changing the last 2 items > to "(5) Cell: location of the network's antenna". Or use > a macro/microcell distinction if that feels better. See also http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt, Section 2.2.3. While the two are the same, there is no reference to the PIDF-LO registry. Since it seems silly to have two different ones, this should be called out. -- to 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, 07 Nov 2004 16:26:16 +0000 Message-ID: <418E3CE9.802@piuha.net> Date: Sun, 07 Nov 2004 17:19:05 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "'radiusext@ops.ietf.org'" , Hannes Tschofenig , geopriv@ietf.org Subject: review of the geopriv radius location attributes draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hannes et al, I read your document on the way here and I think it looks overall pretty good. I did have a couple of issues that I wanted to raise, however. Here they are: Substantial: > During a protocol run it is possible to return Location-Information > attributes which provide both location information elements. If only > one location information element is provided then civil location MUST > be included in the request. Additionally, geospatial location MAY be > provided. Why is the civil location the one that needs to be always provided? What if the access device is a mobile router that has a GPS attached to it? Then it would have easy access to geospatial location but the street address would require a huge database... Suggestion: s/MUST/SHOULD/. > 0 Reserved > 1 Coffee Shop > 2 Hotel > 3 Airport > 4 Mall > 5 Restaurant > 6 Bus > 7 Library > 8 Convention Center > 9 School > 10 Office > 11 Airplane > 12 Train > 13 Ship > 14 Educational Institute > 15 Public Place > 16 Other This list feels a bit restrictive. What about "Car" or "Healt Institute" or a coffee shop in an airport? Suggestion: use the value set (and IANA process) from draft-ietf-simple-rpid-04.txt section 3.5. > Time-to-Live (64 bits): > NTP timestamp for the 'time-to-live' field. It is not clear to me if this field contains the "time of death" of this information, or if this is some sort of a duration value. > Method (8 bits): > Describes the way that the location information was > derived or discovered. The following values are currently > defined: > (0) Global Positioning System (GPS) > (1) GPS with assistance (A-GPS) > (2) Manual configured information > (3) Provided by DHCP > (4) Triangulation: triangulated from time-of-arrival, > signal strength or similar measurements > (5) Cell: location of the cellular radio antenna > (6) IEEE 802.11 WLAN access point I'd like to make this list a bit more technology independent. Or, its OK to give the location information determination method (such as A-GPS), but I don't think you should tie it to the access technology. Suggest changing the last 2 items to "(5) Cell: location of the network's antenna". Or use a macro/microcell distinction if that feels better. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Code | Precision | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sighting Time ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sighting Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Time-to-Live ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Time-to-Live | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Method | Location-Info ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > time-to-live: This field gives a hint until when it should be > considered current. Note that the time-to-live field is different > than the 'retention-expires' rule. The data type of this field is > a string and the format is a 64 bit NTP timestamp [14]. The format, the talk about 64 bits, and "string" appear inconsistent. I think you mean that the value is a 64 bit integer, not a string. > Note Well (variable): > This field contains a URI with human readable > privacy instructions. Putting human readable strings about "policy" into max 253 byte fields sounds like a bad idea. Do we really need this? Suggestion: remove or replace with a URL reference. > One way to ensure that the visited network and intermediate networks > are incapable to learn the user identity is to use EAP methods that > hide the user's identity either actively or passively. Some EAP > methods (such as [16]) protect the user's identity against passive > adversaries by utilizing temporal identities. In some cases the > visited network is still able to retrieve the plaintext identity of > the user and user identity confidentiality is only provided against > eavesdroppers at the wireless link. Depending on the movement > patters of the user, the network topology and available roaming > agreements it is possible that a AAA broker is able to see both the > plaintext user identity and subsequent temporal identities. > Associating location information and the user identity is possible in > these cases. > > It is assumed that the true username is not carried within the > initial EAP-Identity Request/Response message exchange. Support for > username privacy is supported with [17]. > > For stronger security and privacy protection active user identity > confidentiality is highly suggested. EAP methods such as [18] or > [19] provide such a protection. > > Unfortunately, most users are not educated about the importance of > user identity confidentiality and many EAP methods do not provide > active user identity confidentiality. User identity confidentiality > is often treated as an exotic feature which mainly aims to prevent > eavesdroppers on the wireless link to learn the user identity of the > attached users. Awareness for this threat type does often not exist. > In many cases it is even not possible for users to freely select > their favorite authentication and key exchange protocol (based on > their security requirements). Instead the choice is often > predetermined by a given architecture. There seems to be several problems with the above text. First of all, I do not necessarily agree that [18] and [19] provide better identity privacy than [16] and [17]. The privacy results depend highly on configuration in all of the cases. For instance, [16] says that clients can refuse to give a cleartext identity. Depending on configuration and back-end side implementation, this is possible in some networks and not possible in some others. Similarly, [18] depends highly on the configuration of the trusted public key/CA. If it is the single server's key then you are very safe. If its the Verisign general purpose CA, anyone with a web side cert can get you to reveal your identity. The second issue is that this is IMHO the wrong document to talk about identity privacy. You should talk about location privacy, but identity privacy is a larger subject than something that EAP methods can do. For instance, we have identity privacy problems at the MAC, EAP, PPP, IP, ND, and application layers. Suggestion: remove the above text and associated references. > Knowing > the final recipient of the location information is in fact impossible > for RADIUS entities. I'd like the document to talk a little bit about the use of Diameter Redirect functionality and how that affects the issues talked about in the security considerations section. Editorial: > rule se. s/se./set./ > Location Information may also be reported in accouning messages. s/accouning/accounting/ > change their policies using the authroization framework defined in s/authroization/authorization/ > network to which the user has a contractal relationship. The main s/contractal/contractual/ > F. Adrangi > Intel Corporatation s/Corporatation/Corporation/ > network to the home AAA server. To embedd a Location Object into s/embedd/embed/ > location information. The location infomration may refer to network s/infomration/information/ > The home network operator requires location informaion for s/informaion/information/ > is useable on constrained devices. s/useable/usable/ > issues in more details. s/details/detail/ > defined in Section 4.6 of [12] which is reused by [5] we define our I think its 3.5 of [12], if you look at rev -04. --Jari -- to 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, 06 Nov 2004 00:50:20 +0000 Date: Fri, 5 Nov 2004 16:50:02 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT Agenda for IETF 61 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Since RADEXT WG is meeting first thing Monday morning, we are requesting that presenters send in their slides to myself and David ASAP. Thanks in advance! Here is the agenda for the meeting: RADEXT WG Agenda Monday, November 8, 2004 0900 - 1130 Chairs: Bernard Aboba David Nelson Preliminaries (15 minutes) Minutes Bluesheets Agenda Bash Liaison Requests WG Milestones Document Status Documents in WG Last Call RFC 2486bis, Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt RADIUS Extension for Digest Authentication, Wolfgang Beck (15 minutes) http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt Other documents RFC 3576 MIBs - M. Chiba (10 minutes) http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt Chargeable User Identity, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt LAN attributes, Paul Congdon (10 minutes) http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt Redirection, Avi Lior (5 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt Prepaid Extensions, Avi Lior (10 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-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: Fri, 05 Nov 2004 16:19:53 +0000 Date: Fri, 5 Nov 2004 08:18:40 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: IETF 61 Agenda - Take Two Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please send agenda items to myself and David Nelson ASAP. RADEXT WG Agenda Monday, November 8, 2004 0900 - 1130 Chairs: Bernard Aboba David Nelson Preliminaries (15 minutes) Minutes Bluesheets Agenda Bash Liaison Requests WG Milestones Document Status Documents in WG Last Call RFC 2486bis, Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt RADIUS Extension for Digest Authentication, Wolfgang Beck (15 minutes) http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt Other documents RFC 3576 MIBs - M. Chiba (10 minutes) http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt Chargeable User Identity, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt LAN attributes, Paul Congdon (10 minutes) http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt Redirection, Avi Lior (5 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt Prepaid Extensions, Avi Lior (10 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-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: Thu, 04 Nov 2004 20:01:10 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: [Issue 7] Message Authenticator Date: Thu, 04 Nov 2004 15:11:30 -0500 Message-Id: <20041104201130.7262916C91@mail.nitros9.org> Avi Lior wrote: > I think that Message-Authenticator should be mandatory. I agree. Alan Dekok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 04 Nov 2004 16:56:38 +0000 Date: Thu, 4 Nov 2004 08:56:15 -0800 (PST) From: Bernard Aboba To: Avi Lior cc: radiusext@ops.ietf.org Subject: RE: [Issue 7] Message Authenticator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > In this email you say: "Message-Authenticator was not required in RFC 2865, > so that it was not sent by legacy RADIUS-clients." > > On the issues list you say: > [Bernard Aboba] Use of Message Authenticator is required by RFC 2865. The issues list has a typo. It was required by RFC 2869 only for messages with EAP-Message attributes. -- to 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, 04 Nov 2004 13:36:33 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: RE: [Issue 7] Message Authenticator Date: Thu, 4 Nov 2004 08:35:53 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Bernard, I think that Message-Authenticator should be mandatory. Points of clarification: In this email you say: "Message-Authenticator was not required in RFC 2865, so that it was not sent by legacy RADIUS-clients." On the issues list you say: [Bernard Aboba] Use of Message Authenticator is required by RFC 2865. Can you please clarify these seemly contrary statements. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: November 3, 2004 11:35 PM > To: radiusext@ops.ietf.org > Subject: Re: [Issue 7] Message Authenticator > > > Wolfgang Beck wrote: > > "RFC 2869 is informational. I see that it is useful but > I hesitate to make it mandatory. > > new text: > 'Informational RfC 3579 [RFC3579], section 3.2 describes > a Message-Authenticator attribute which MAY be used to > protect the integrity of RADIUS messages.'" > > Omitting Message-Authenticator enables an attacker to forge > Access-Request packets. The reason RFC 3579 could not make > use of Message-Authenticator mandatory for all RADIUS packets > (just for packets containing an EAP-Message attribute) was > because Message-Authenticator was not required in RFC 2865, > so that it was not sent by legacy RADIUS-clients. > > That problem does not occur here; Digest Authentication is a > new RADIUS capability. > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 04 Nov 2004 12:05:29 +0000 Message-ID: <418A1A90.8010801@piuha.net> Date: Thu, 04 Nov 2004 14:03:28 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: [Issue 15] Editorial NITs with RFC 2486bis-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here's a new revision that addresss both the examples and nits: http://www.arkko.com/publications/nai/naibis.txt http://www.arkko.com/publications/nai/naibisdiff.html Sufficient examples? Anything else? --Jari -- to 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, 04 Nov 2004 11:41:49 +0000 Message-ID: <418A14C0.9000904@piuha.net> Date: Thu, 04 Nov 2004 13:38:40 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: [Issue 15] Editorial NITs with RFC 2486bis-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Bernard, Thanks for the nits check. Inline: > Section 1.1: You need an extra line space between definitions. Yes. XML2RFC changed in this respect a number of revisions ago. I have now put in the extra lines. > Change: "ISP- provided" to "ISP-provided" Ok. > Section 3, 4 and 5 probably do not require a page break (e.g. can start in > the middle of the page). Ok. Hmm... I don't seem to be able to control XML2RFC well enough prevent this from happening. I'll leave it to the RFC Editor. > There is no reference to [8] in the document (RFC 2486). The reference has been added to parts that discuss RFC 2486. > BTW, what is the status of the SASLPrep document? > > The reference is normative, meaning that RFC 2486bis can't be published > until it is resolved. I think it is already an RFC. Checking... no, but its in the RFC Editor's queue. So no problem. --Jari -- to 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, 04 Nov 2004 11:41:41 +0000 Message-ID: <418A0C55.8090809@piuha.net> Date: Thu, 04 Nov 2004 13:02:45 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: [Issue 16] Special Characters in RFC 2486bis-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > In RFC 2486, "jari.arkko@ericsson.com" is a valid NAI, and it would appear > that this is also true in RFC 2486bis, due to the following rules: > > username = dot-string > dot-string = string > dot-string =/ dot-string "." string > > Or am I missing something? No -- you are not missing anything. My mistake on reading the ABNF. Sorry! But the ABNF is correct. > At a minimum, I think we may need additional examples of legal and illegal > NAIs. Hmm... I'm not completely sure about that. But I see that you have some nits e-mail about the document too, so if I have to submit a new one anyway I could add a firstname.lastname example. We already have legal/illegal special character examples. --Jari -- to 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, 04 Nov 2004 08:51:12 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: CUI: WG Work Item Date: Thu, 4 Nov 2004 10:50:55 +0200 Message-ID: <07B14A720C46C344AC96AAA64F5D6A313BEC4A@FITMS201MB.tcad.telia.se> Thread-Topic: CUI: WG Work Item Thread-Index: AcTCK4Ga4rsga3CiTzyHv4P6JDvi+gAFxUqA From: To: Cc: Bernard,=20 I also think CUI is suitable for a WG item. Currently, the concept of CUI has been adopted by several well established roaming organizations and also it has already been experimented among number of operators. Thus there seems to be real need for it in various roaming scenarios where existing mechanisms were not considered to be sufficient. Should there be open issues or shortcomings in the latest Draft those could be resolved within this WG. Br, Jouni --=20 Jouni Korhonen - Senior Researcher Emerging Technologies and Innovations TeliaSonera Finland > > Over the last month, there has been considerable discussion of the > Chargeable User Identity document. > > Given the considerable amount of discussion, it would appear that WG > participants have had sufficient time to determine whether this document > is suitable for becoming a RADEXT WG work item: > > http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user -identity-02.txt > > Therefore, we are going to call for Consensus on whether the document is > suitable for becoming a WG work item. > > If you believe that the document is suitable please send mail with "CUI: > WG Work Item" in the subject, detailing why you think the draft is > suitable for becoming a RADEXT WG Work item. > > If you believe that there are major problems with the draft or that the > draft is unnecessary, please send mail with "CUI: unsuitable" in the > subject line, and in the body explain your objections. > > Thank you! -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 04 Nov 2004 06:46:31 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: CUI:WG Work Item Date: Thu, 4 Nov 2004 08:46:01 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D431F72@esebe056.ntc.nokia.com> Thread-Topic: Call for Consensus: Adoption of CUI as a RADEXT WG Work Item Thread-Index: AcTCK5ANTgn+ww2vR6+61FKUpMmbtAADhP/g From: To: , > If you believe that the document is suitable please send mail with = "CUI: > WG Work Item" in the subject, detailing why you think the draft is > suitable for becoming a RADEXT WG Work item. Bernard,=20 I think this is suitable for a WG item. I think such a mechanism is = needed in some roaming scenarios, such as ones being developed in GSMA. The = current mechanisms are insufficient. =20 I think the draft could better explain the problem and usage of the CUI, = and perhaps contain a section on applicability of this mechanism. I've been busy with other things recently, but if needed, I can = contribute to=20 resolving any open issues with this draft. 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, 04 Nov 2004 05:23:59 +0000 Date: Wed, 3 Nov 2004 21:23:46 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Call for review of draft-ietf-geopriv-radius-lo-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The following document is a WG work item of the GEOPRIV WG: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-01.txt Since this document carries GEOPRIV information in RADIUS, we are asking participants in the RADEXT WG to review the document. If you have GEOPRIV-related comments, please post these to the GEOPRIV WG mailing list. However, if your comments relate to the draft's use of RADIUS, please post those comments to the RADEXT WG mailing list. As usual, please put [Issue] in the Subject line, and post the issues in the format specified on the RADEXT WG Issues list, so that they can be tracked: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 04 Nov 2004 05:01:32 +0000 Date: Wed, 3 Nov 2004 21:01:25 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Call for Consensus: Adoption of CUI as a RADEXT WG Work Item Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Over the last month, there has been considerable discussion of the Chargeable User Identity document. Given the considerable amount of discussion, it would appear that WG participants have had sufficient time to determine whether this document is suitable for becoming a RADEXT WG work item: http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt Therefore, we are going to call for Consensus on whether the document is suitable for becoming a WG work item. If you believe that the document is suitable please send mail with "CUI: WG Work Item" in the subject, detailing why you think the draft is suitable for becoming a RADEXT WG Work item. If you believe that there are major problems with the draft or that the draft is unnecessary, please send mail with "CUI: unsuitable" in the subject line, and in the body explain your objections. Thank you! -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 04 Nov 2004 04:54:50 +0000 Date: Wed, 3 Nov 2004 20:54:34 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Verification of WG consensus on Digest Issues 3, 4, 5, 6, 8, 11 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The RADEXT WG Issue list is posted here: http://www.drizzle.com/~aboba/RADEXT/ For Issues 3, 4, 5, 6, 8, 11 we have a proposed resolution, included in the -04 draft: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt However, review of the WG mailing list did not disclose discussion of the proposed resolutions, so that WG consensus could not be determined. If you have read the -04 document and approve of the proposed resolutions to Issues 3, 4, 5, 6, 8, and 11, as embodied in the -04 document, please send email to this list with "Digest: Agree" in the subject. This is particularly important if you are the submitter of the Issue in question. If you do not agree with the proposed resolutions, please send email with [Issue #] in the title, detailing your objections to the proposed resolutions. -- to 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, 04 Nov 2004 04:34:51 +0000 Date: Wed, 3 Nov 2004 20:34:37 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: [Issue 7] Message Authenticator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Wolfgang Beck wrote: "RFC 2869 is informational. I see that it is useful but I hesitate to make it mandatory. new text: 'Informational RfC 3579 [RFC3579], section 3.2 describes a Message-Authenticator attribute which MAY be used to protect the integrity of RADIUS messages.'" Omitting Message-Authenticator enables an attacker to forge Access-Request packets. The reason RFC 3579 could not make use of Message-Authenticator mandatory for all RADIUS packets (just for packets containing an EAP-Message attribute) was because Message-Authenticator was not required in RFC 2865, so that it was not sent by legacy RADIUS-clients. That problem does not occur here; Digest Authentication is a new RADIUS capability. -- to 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, 04 Nov 2004 03:58:39 +0000 Date: Wed, 3 Nov 2004 19:58:20 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: [Issue 15] Editorial NITs with RFC 2486bis-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 15: Editorial NITs with RFC 2486bis-01 Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 29, 2004 Reference: Document: RFC2486bis-01 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: Section 1.1: You need an extra line space between definitions. For example, change: " This document frequently uses the following terms: Network Access Identifier" To: " This document frequently uses the following terms: Network Access Identifier" Change: "ISP- provided" to "ISP-provided" Section 3, 4 and 5 probably do not require a page break (e.g. can start in the middle of the page). There is no reference to [8] in the document (RFC 2486). BTW, what is the status of the SASLPrep document? The reference is normative, meaning that RFC 2486bis can't be published until it is resolved. -- to 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, 04 Nov 2004 03:46:28 +0000 Date: Wed, 3 Nov 2004 19:46:09 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: [Issue 16] Special Characters in RFC 2486bis-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In RFC 2486, "jari.arkko@ericsson.com" is a valid NAI, and it would appear that this is also true in RFC 2486bis, due to the following rules: username = dot-string dot-string = string dot-string =/ dot-string "." string Or am I missing something? At a minimum, I think we may need additional examples of legal and illegal NAIs. -------------------------------------------------------------------- Issue 16: Special Characters in RFC 2486bis-01 Submitter: Paola Pappalardo Submitter email address: misspaola@tiscali.it Date first submitted: October 29, 2004 Reference: http://ops.ietf.org/lists/radiusext/2004/msg00804.html Document: RFC2486bis-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I have to handle the Network Access Identifier (NAI) for my work. I have read the RFC 2486 and I'm a little confused about the use of special characters, like "<" / ">" / "(" / ")" / "[" / "]" / "\" / "." / "," / ";" / ":" / "@" / %x22 / Ctl, in the NAI username. Can you help me? Can you please give some examples of valid NAI containing special characters? [Jari Arkko] The issue is what "special" characters, not just alphabets and digits can appear in NAIs. The realm part rules are according to the usual DNS, which I think allows only "-" and ".". The user name part allows more special characters, but disallows some others. A couple of valid examples: jari_arkko@ericsson.com user%%%%%@example.com A couple of invalid examples: jari.arkko@ericsson.com user>luser@example.com Nevertheless, there's an escape mechanism that allows even special characters. Example: jari\.arkko@ericsson.com If you read the new draft you will see that the ABNF syntax is hopefully easier to read than in RFC 2486, because the treatment of each character has been listed on its own line, and you do not have read the comments to find out what actual characters are allowed. -- to 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, 04 Nov 2004 01:18:07 +0000 Date: Wed, 3 Nov 2004 17:17:31 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG Agenda for IETF 61 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We finally have a confirmed slot at IETF 61. Here is a preliminary agenda for the RADEXT WG meeting. Please send agenda items to myself and David Nelson ASAP. RADEXT WG Agenda Monday, November 8, 2004 0900 - 1130 Chairs: Bernard Aboba David Nelson Preliminaries (15 minutes) Minutes Bluesheets Agenda Bash Liaison Requests WG Milestones Document Status Documents in WG Last Call RFC 2486bis, Jari Arkko (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt RADIUS Extension for Digest Authentication, Wolfgang Beck (15 minutes) http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt Other documents RFC 3576 MIBs - M. Chiba (5 minutes) http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt Chargeable User Identity, Farid Adrangi (5 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-radius-chargeable-user-identity-02.txt LAN attributes, Paul Congdon (5 minutes) http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-02.txt Redirection, Avi Lior (5 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt Prepaid Extensions, Avi Lior (5 minutes) http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-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, 02 Nov 2004 15:07:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Meeting Slot at IETF 61 Date: Tue, 2 Nov 2004 10:06:24 -0500 Message-ID: Thread-Topic: RADEXT Meeting Slot at IETF 61 Thread-Index: AcTARbWVE4PB1X7rQK+EXxuH/r4/lwAp2/+A From: "Nelson, David" To: > I will post an update to the list if our meeting schedule > changes in the Final Agenda. It has changed in the "Almost Final" Agenda. The RADEXT WG is now scheduled to meet on Monday November 8, 2004 from 09:00 to 11:30 (AM) EST (the morning meeting slot). -- to 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, 01 Nov 2004 19:06:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RADEXT Meeting Slot at IETF 61 Date: Mon, 1 Nov 2004 14:05:04 -0500 Message-ID: Thread-Topic: RADEXT Meeting Slot at IETF 61 Thread-Index: AcTARbWVE4PB1X7rQK+EXxuH/r4/lw== From: "Nelson, David" To: The RADEXT WG will be meeting at the 61st IETF in Washington, DC on Monday November 8, 2004 from 19:30 to 22:00 PM EST (evening meeting slot). The latest IETF 61 Draft Agenda is posted at: http://www.ietf.org/meetings/agenda_61.html I will post an update to the list if our meeting schedule changes in the Final Agenda. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: