Subject: Extended-Space attribute draft available
From: Barney Wolff <[email-masked]>
To: [email-masked]
Date: Mon, 27 Feb 2006 21:09:21 -0500

Greg Weber and I have written a draft defining an Extended-Space
attribute.  Here's the abstract:

   The RADIUS protocol is being extended beyond the wildest imaginations
   of its original designers.  These extensions are pushing up against
   the existing limitations on the numbers, length, base types and
   grouping of RADIUS attributes.  This document specifies a method of
   relaxing those limitations.

While it works its way to the IETF draft directory, you're welcome
to retrieve it here:

http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.txt
http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.html

This draft is a companion piece the the design guidelines draft, and,
we hope, will be adopted as a RADEXT work item.

Comments and corrections are welcome, and if necessary I can try to
get a -01 version in before next week's deadline.

Barney Wolff

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 27 Feb 2006 23:50:32 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-rules-00.txt 
Date: Mon, 27 Feb 2006 18:50:02 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: Filter Attributes 
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-rules-00.txt
	Pages		: 28
	Date		: 2006-2-27
	
In certain scenarios it is desirable to limit user access using      
filters or redirection.  This document proposes additional 
attributes for this purpose, for use with the Remote 
Authentication Dial In User Server (RADIUS).  The attributes 
described in this document are expected to be useful in a variety 
of environments, including enterprise and service provider 
scenarios. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-filter-rules-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-filter-rules-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-filter-rules-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-rules-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 27 Feb 2006 22:32:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility work item
Date: Mon, 27 Feb 2006 17:34:45 -0500
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

You are right about that free radius dictionaries.

FWIW there are many more then the list you have posted.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Friday, February 24, 2006 6:47 PM
> To: Nelson, David
> Cc: [email-masked]
> Subject: Re: Crypto-agility work item
>=20
> ...
> > Are there others I've overlooked?
>=20
> $ grep encrypt=3D freeradius/share/dictionary* | sed ....
>=20
> User-Password				2	string encrypt=3D1
> Tunnel-Password				69	string=09
> has_tag,encrypt=3D2
> MS-CHAP-MPPE-Keys			12	octets  encrypt=3D1
> MS-MPPE-Send-Key			16	octets	encrypt=3D2
> MS-MPPE-Recv-Key			17	octets	encrypt=3D2
>=20
>   Message-Authenticator doesn't need any flags in the=20
> implementation, so it isn't listed here.  The 'encrypt=3D1'=20
> means "like User-Password",
> 2 means "like Tunnel-Password", and (below) 3 means "like=20
> Ascend-Send-Secret".
>=20
>   We also have encrypted VSA's.
>=20
> 3GPP2-MN-HA-Shared-Key			58	string encrypt=3D2
> Ascend-Send-Secret			214	string	encrypt=3D3
> Ascend-Receive-Secret			215	string	encrypt=3D3
> X-Ascend-Send-Secret			214	string encrypt=3D3
> X-Ascend-Receive-Secret			215	string encrypt=3D3
> ERX-LI-Action				58	integer	encrypt=3D2
> ERX-Med-Dev-Handle			59	octets	encrypt=3D2
> ERX-Med-Ip-Address			60	ipaddr	encrypt=3D2
> ERX-Med-Port-Number			61	integer	encrypt=3D2
> Lucent-Send-Secret			214	string encrypt=3D3
> Lucent-Receive-Secret			215	string encrypt=3D3
>=20
>   It looks like that's it.  The FreeRADIUS dictionaries=20
> aren't authoritative, but they do have a large number of=20
> vendor dictionaries.
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Fri, 24 Feb 2006 23:40:26 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Crypto-agility work item 
cc: [email-masked]
Date: Fri, 24 Feb 2006 18:47:11 -0500
Message-Id: <[email-masked]>

...
> Are there others I've overlooked?

$ grep encrypt= freeradius/share/dictionary* | sed ....

User-Password				2	string encrypt=1
Tunnel-Password				69	string	has_tag,encrypt=2
MS-CHAP-MPPE-Keys			12	octets  encrypt=1
MS-MPPE-Send-Key			16	octets	encrypt=2
MS-MPPE-Recv-Key			17	octets	encrypt=2

  Message-Authenticator doesn't need any flags in the implementation,
so it isn't listed here.  The 'encrypt=1' means "like User-Password",
2 means "like Tunnel-Password", and (below) 3 means "like
Ascend-Send-Secret".

  We also have encrypted VSA's.

3GPP2-MN-HA-Shared-Key			58	string encrypt=2
Ascend-Send-Secret			214	string	encrypt=3
Ascend-Receive-Secret			215	string	encrypt=3
X-Ascend-Send-Secret			214	string encrypt=3
X-Ascend-Receive-Secret			215	string encrypt=3
ERX-LI-Action				58	integer	encrypt=2
ERX-Med-Dev-Handle			59	octets	encrypt=2
ERX-Med-Ip-Address			60	ipaddr	encrypt=2
ERX-Med-Port-Number			61	integer	encrypt=2
Lucent-Send-Secret			214	string encrypt=3
Lucent-Receive-Secret			215	string encrypt=3

  It looks like that's it.  The FreeRADIUS dictionaries aren't
authoritative, but they do have a large number of vendor dictionaries.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 21:48:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility work item
Date: Fri, 24 Feb 2006 16:47:58 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> The existing RADIUS security mechanisms include:
>=20
> -- The MD5-based stream cipher used to obscure the User-Password
> attribute.
>=20
> -- The MD5-based MAC used to create the Response-Authenticator header
> field.
>=20
> -- The HMAC-MD5 MAC used to create the Message-Authenticator
attribute.

I neglected to mention:

-- The MD5 based stream cipher used to obscure MS-MPPE-Send-Key and
MS-MPPE-Recv-Key attributes.

-- The MD5 based stream cipher used to obscure the Tunnel-Password
attribute.

Are there others I've overlooked?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Fri, 24 Feb 2006 21:24:15 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Crypto-agility work item 
cc: [email-masked]
Date: Fri, 24 Feb 2006 16:30:53 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> There are other ways of securing RADIUS, most notably running it over a
> protected transport, such as IPsec, TLS, DTLS, etc.  I don't consider
> these as RADIUS security mechanisms, however, as they are external to
> RADIUS.

  In my experience, that's why people add security mechanisms to
RADIUS.  They can't trust that the external security mechanisms exist,
or that they work.  e.g. the IETF where the wireless sniffer grabbed
someone's userid & password, because their admin had un-checked the
"use encryption" box on the VPN box.  There was no warning or
notification to the end applications (or user) that traffic was being
sent in the clear.

> When we discuss new cryptographic algorithms for existing RADIUS
> security mechanisms do we mean simply replacing MD5 or HMAC-MD5, as they
> appear above, with some other algorithm?

  I would say that is a good first step.

> Do we anticipate the creation of new attributes, such as a
> Message-Authentication-Code attribute, to replace/supplement the
> Message-Authenticator attribute?

  That is an option.  I'm not sure how else we would add security to
RADIUS.

> Since the scope of this work includes key-wrap, we anticipate the
> definition of new attributes, for key distribution, that are protected
> by reversible encryption, using one or more algorithms.

  It would seem so.

> Do we anticipate that other new attributes, similarly protected, could
> be defined for use in transmission of other information besides keys?

  If we're defining encryption methods using new algorithms, we might
as well use them for attributes other than keys.  It would be minimal
additional work, either in the spec or implementations, and could have
significant utility in deployments.

> Do we anticipate defining, by reference to other work, how key agreement
> for the KEK (and other keys) shared by RADIUS clients and servers is
> accomplished in an interoperable fashion?

  I would guess so.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 21:05:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility work item
Date: Fri, 24 Feb 2006 16:04:57 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> The focus is on negotiation of cryptographic algorithms for
> existing RADIUS security mechanisms.=20

Let's poke into this a little deeper.

The existing RADIUS security mechanisms include:

-- The MD5-based stream cipher used to obscure the User-Password
attribute.

-- The MD5-based MAC used to create the Response-Authenticator header
field.

-- The HMAC-MD5 MAC used to create the Message-Authenticator attribute.

There are other ways of securing RADIUS, most notably running it over a
protected transport, such as IPsec, TLS, DTLS, etc.  I don't consider
these as RADIUS security mechanisms, however, as they are external to
RADIUS.

When we discuss new cryptographic algorithms for existing RADIUS
security mechanisms do we mean simply replacing MD5 or HMAC-MD5, as they
appear above, with some other algorithm?

Do we anticipate the creation of new attributes, such as a
Message-Authentication-Code attribute, to replace/supplement the
Message-Authenticator attribute?

Since the scope of this work includes key-wrap, we anticipate the
definition of new attributes, for key distribution, that are protected
by reversible encryption, using one or more algorithms.

Do we anticipate that other new attributes, similarly protected, could
be defined for use in transmission of other information besides keys?

Do we anticipate defining, by reference to other work, how key agreement
for the KEK (and other keys) shared by RADIUS clients and servers is
accomplished in an interoperable fashion?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 20:06:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Crypto-agility work item
Date: Fri, 24 Feb 2006 12:06:20 -0800

The fundamental goal of this work is to develop an openly specified, secure, 
interoperable mechanism for the negotiation of cryptographic algorithms 
within RADIUS.  This includes algorithms for per-packet authentication and 
integrity protection, as well as keywrap.

The focus is on negotiation of cryptographic algorithms for existing RADIUS 
security mechanisms.  It is not about fundamental changes to the RADIUS 
security model, or changes to AAA key management models (that work is 
occurring in EAP WG).

While this work item may enable implementations to satisfy FIPS 140-2 
requirements,  there are no guarantees that NIST will bless the resulting 
specification, or that the algorithms to be supported will remain on the 
list of FIPS 140-2 approved algorithms indefinitely.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 15:09:25 +0000
Content-class: urn:content-classes:message
Subject: RADIUS Keywrap (was RE: RADEXT Milestone revisions)
Date: Fri, 24 Feb 2006 10:09:02 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Glen Zorn writes...
=20
> Just humor a moron a bit longer: how do you expect to "address
modularity
> of cipher suites" in RADIUS w/o modifying (at the very least the
> processing of) the RADIUS headers?

At a very simplistic level, adding new attributes is OK; changing the
headers or PDU format is not.  There are other things that are out of
scope, of course, such as new commands.

> Neither do I.  Are you saying now that key management _is_ in scope of
the
> radext charter?

No. I think that the definition new key management protocol(s) for use
between RADIUS entities (clients, servers, proxies) is out of scope for
RADEXT.  I would not suggest that RADEXT invent its own key management
protocol, in any event.  I'm quite certain our friends in the Security
Area would frown upon any such effort.  Surely there are existing RFCs
for such protocols that could have been referenced.  What would satisfy
my concerns would be a reference to existing key agreement protocols.  I
would like to see statement similar to: "Agreement of the KEK among
RADIUS entities is not specified in this document.  The following
existing key agreement protocols are potentially suitable for this use:
<insert list here>.  To obtain global interoperability, the following
method <insert protocol here> SHALL be mandatory to implement for RADIUS
Keywrap."

> Rather than, oh, say, discussing them on the list.

Let's do so now.  Starting with the issue around key agreement protocols
for the KEK, and any other keys required in your draft that SHOULD NOT
be derived from the RADIUS shared secret.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 07:00:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter compatibility of VLAN-00
Date: Fri, 24 Feb 2006 02:00:42 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Friday, February 24, 2006 1:52 AM
> To: Greg Weber (gdweber)
> Cc: [email-masked]; [email-masked]
> Subject: RE: Diameter compatibility of VLAN-00
>=20
> >I agree, but does 4072 say anything about future
> >RADIUS attributes?  I don't see this in section 5,
> >but I'll have to look again at section 6.
>=20
> That should probably be in RFC 4005, since that deals with=20
> RADIUS/Diameter=20
> gateways.
>=20
> >Certainly hope not, or we don't have a very extensible
> >framework.  :-)
>=20
> While RFC 3588 indicates that a new application ID is not=20
> required to add=20
> optional attributes to Diameter, addition of mandatory=20
> attributes do require=20
> a new application ID.  =20

Yes, you made a similar comment earlier which I did=20
fully grok.  Why is adding a RADIUS attribute to a=20
Diameter application equated with 'mandatory'? =20
I would think that RADIUS attributes carried in Diameter
do not have the 'required' bit set in the attribute header,
as RADIUS does not have the 'required' concept.  No?

Greg

> This has proven to be something of a=20
> problem since=20
> there have been quite a few occasions where it has been=20
> necessary to add new=20
> attributes and allocating a new application ID ever time is=20
> not convenient. =20
> As a result, I'm not entirely clear that the VLAN attributes=20
> can be added to=20
> Diameter EAP or NASREQ without allocation of an application=20
> ID, although=20
> that hardly seems logical.
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 06:56:53 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter compatibility of VLAN-00
Date: Thu, 23 Feb 2006 22:56:45 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Greg Weber (gdweber)" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Not sure I see the need to break new ground here... If there is an
existing mechanism to allow Diameter support we should continue to use
it.  I'd rather reference the mechanism that start including portions of
text that are trying to represent it...  Pass by reference, not by value
for better portability in this case. =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Greg Weber=20
> (gdweber)
> Sent: Thursday, February 23, 2006 10:30 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Diameter compatibility of VLAN-00
>=20
>=20
> I guess I am just observing that this is an opportunity to=20
> set a precedent.  I do not feel strongly about this issue for=20
> this particular draft, but in general, how do we comply with=20
> this part of the charter:
>   "RADEXT WG work items MUST contain a Diameter=20
>    compatibility section, outlining how
>    interoperability with Diameter will be=20
>    maintained."
> Saying, essentially, this RADIUS attribute can be used with=20
> so-and-so application may not be a clear specification given=20
> some of the complicated Diameter applications that may occur.=20
>  I don't think a Diameter AVP table is out of the question- do you?
>=20
> Greg
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, February 24, 2006 1:13 AM
> > To: Greg Weber (gdweber); [email-masked]
> > Cc: [email-masked]
> > Subject: RE: Diameter compatibility of VLAN-00
> >=20
> > Are you suggesting havinging Diameter AVP tables in the draft?
> >=20
> > John
> >=20
> > >> How would this work?
> > >>=20
> > >> Fix the typo.
> > >>=20
> > >> Insert a section 4 that says the following:
> > >>=20
> > >> 4.  Diameter Considerations
> > >>=20
> > >>    Diameter needs to define identical attributes with=20
> the same Type
> > >>    values.  The attributes should be available as part of
> > the NASREQ
> > >>    application [RFC4005], as well as the Diameter EAP application
> > >>    [RFC4072].
> > >>=20
> > >> Add Informative references to [RFC4005] and [RFC4072].
> > >
> > >It might be beneficial to set a more useful and=20
> informative precedent=20
> > >than was established with CUI, e.g. which messages in which=20
> > >applications may contain the attribute.  This would seem to be=20
> > >analogous to the rigor of the typical RADIUS attribute=20
> table found in=20
> > >most RADIUS drafts.  Disagree?
> > >
> > >Greg
> > >
> > >>=20
> > >> --------------------------------------------------------------
> > >> ---------------------------
> > >> Description of issue: Diameter compatibility of VLAN-00 Submitter
> > >> name: Greg Weber Submitter email address: [email-masked]
> > >Date first
> > >> submitted: February 21, 2006
> > >> Reference: NA
> > >> Document: VLAN-00
> > >> Comment type: Editorial
> > >> Priority: S
> > >> Section: NA
> > >> Rationale/Explanation of issue:
> > >>=20
> > >>   In the RADEXT charter, I see:
> > >>     "...all RADEXT WG work items MUST contain a Diameter
> > >>      compatibility section, outlining how interoperability
> > >>      with Diameter will be maintained."
> > >>=20
> > >>   The VLAN draft does not contain a Diameter compatibility
> > >>   section, but does mention (in the abstract) that these
> > >>   attributes can be used with Diameter.
> > >>=20
> > >> Requested change:
> > >>   The table of attributes in section 3 shows which attributes
> > >>   may be in which RADIUS messages.  Maybe another similar
> > >>   table is needed in a Diameter Compatibility section showing
> > >>   which Diameter applications/messages may include these
> > attributes.
> > >>=20
> > >>   Also, I see one typo that wasn't in the previous version :)
> > >>     Section 1.3:  'Unsupported Attribute"' ->
> > >>                   '"Unsupported Attribute"' (missing=20
> double quote).
> > >>=20
> > >>=20
> > >>=20
> > >> --
> > >> to unsubscribe send a message to
> > [email-masked] with
> > >> the word 'unsubscribe' in a single line as the message text body.
> > >> archive: <http://psg.com/lists/radiusext/>
> > >>=20
> > >
> > >--
> > >to unsubscribe send a message to
> > >[email-masked] with the word 'unsubscribe' in a=20
> > >single line as the message text body.
> > >archive: <http://psg.com/lists/radiusext/>
> > >
> >=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 06:52:00 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: Diameter compatibility of VLAN-00
Date: Thu, 23 Feb 2006 22:51:54 -0800

>I agree, but does 4072 say anything about future
>RADIUS attributes?  I don't see this in section 5,
>but I'll have to look again at section 6.

That should probably be in RFC 4005, since that deals with RADIUS/Diameter 
gateways.

>Certainly hope not, or we don't have a very extensible
>framework.  :-)

While RFC 3588 indicates that a new application ID is not required to add 
optional attributes to Diameter, addition of mandatory attributes do require 
a new application ID.   This has proven to be something of a problem since 
there have been quite a few occasions where it has been necessary to add new 
attributes and allocating a new application ID ever time is not convenient.  
As a result, I'm not entirely clear that the VLAN attributes can be added to 
Diameter EAP or NASREQ without allocation of an application ID, although 
that hardly seems logical.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 06:48:45 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: RADEXT Milestone revisions
Date: Thu, 23 Feb 2006 22:48:36 -0800

>Neither do I.  Are you saying now that key management _is_ in scope of the 
>radext charter?

Negotiation of cryptographic algorithms is in scope.  This would include 
keywrap algorithms.

>Rather than, oh, say, discussing them on the list.  So much for the "heart 
>of the IETF process", I >guess.

Actually, a discussion was started on the list:
http://ops.ietf.org/lists/radiusext/2005/msg00730.html

However, a number of questions came up during that discussion that were not 
answered.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 06:44:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter compatibility of VLAN-00
Date: Fri, 24 Feb 2006 01:44:34 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Friday, February 24, 2006 1:33 AM
> To: Greg Weber (gdweber); [email-masked]
> Cc: [email-masked]
> Subject: RE: Diameter compatibility of VLAN-00
>=20
> It would seem awkward for this document to Update RFC 4005=20
> and 4072. =20

I agree, but does 4072 say anything about future=20
RADIUS attributes?  I don't see this in section 5,
but I'll have to look again at section 6.=20

> I'm also not entirely clear whether it would be necessary to=20
> change the ABNFs in those documents.

Certainly hope not, or we don't have a very extensible
framework.  :-)

Greg

>=20
>=20
> >From: "Greg Weber (gdweber)" <[email-masked]>
> >To: <[email-masked]>
> >CC: <[email-masked]>, <[email-masked]>
> >Subject: RE: Diameter compatibility of VLAN-00
> >Date: Fri, 24 Feb 2006 01:30:27 -0500
> >
> >
> >I guess I am just observing that this is an opportunity
> >to set a precedent.  I do not feel strongly about this
> >issue for this particular draft, but in general, how do
> >we comply with this part of the charter:
> >   "RADEXT WG work items MUST contain a Diameter
> >    compatibility section, outlining how
> >    interoperability with Diameter will be
> >    maintained."
> >Saying, essentially, this RADIUS attribute can be used
> >with so-and-so application may not be a clear specification
> >given some of the complicated Diameter applications that
> >may occur.  I don't think a Diameter AVP table is out of
> >the question- do you?
> >
> >Greg
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Friday, February 24, 2006 1:13 AM
> > > To: Greg Weber (gdweber); [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: Diameter compatibility of VLAN-00
> > >
> > > Are you suggesting havinging Diameter AVP tables in the draft?
> > >
> > > John
> > >
> > > >> How would this work?
> > > >>
> > > >> Fix the typo.
> > > >>
> > > >> Insert a section 4 that says the following:
> > > >>
> > > >> 4.  Diameter Considerations
> > > >>
> > > >>    Diameter needs to define identical attributes with=20
> the same Type
> > > >>    values.  The attributes should be available as part of
> > > the NASREQ
> > > >>    application [RFC4005], as well as the Diameter EAP=20
> application
> > > >>    [RFC4072].
> > > >>
> > > >> Add Informative references to [RFC4005] and [RFC4072].
> > > >
> > > >It might be beneficial to set a more useful and informative
> > > >precedent than was established with CUI, e.g. which messages
> > > >in which applications may contain the attribute.  This would
> > > >seem to be analogous to the rigor of the typical RADIUS
> > > >attribute table found in most RADIUS drafts.  Disagree?
> > > >
> > > >Greg
> > > >
> > > >>
> > > >> --------------------------------------------------------------
> > > >> ---------------------------
> > > >> Description of issue: Diameter compatibility of=20
> VLAN-00 Submitter
> > > >> name: Greg Weber Submitter email address: [email-masked]
> > > >Date first
> > > >> submitted: February 21, 2006
> > > >> Reference: NA
> > > >> Document: VLAN-00
> > > >> Comment type: Editorial
> > > >> Priority: S
> > > >> Section: NA
> > > >> Rationale/Explanation of issue:
> > > >>
> > > >>   In the RADEXT charter, I see:
> > > >>     "...all RADEXT WG work items MUST contain a Diameter
> > > >>      compatibility section, outlining how interoperability
> > > >>      with Diameter will be maintained."
> > > >>
> > > >>   The VLAN draft does not contain a Diameter compatibility
> > > >>   section, but does mention (in the abstract) that these
> > > >>   attributes can be used with Diameter.
> > > >>
> > > >> Requested change:
> > > >>   The table of attributes in section 3 shows which attributes
> > > >>   may be in which RADIUS messages.  Maybe another similar
> > > >>   table is needed in a Diameter Compatibility section showing
> > > >>   which Diameter applications/messages may include these
> > > attributes.
> > > >>
> > > >>   Also, I see one typo that wasn't in the previous version :)
> > > >>     Section 1.3:  'Unsupported Attribute"' ->
> > > >>                   '"Unsupported Attribute"' (missing=20
> double quote).
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> to unsubscribe send a message to
> > > [email-masked] with
> > > >> the word 'unsubscribe' in a single line as the message=20
> text body.
> > > >> archive: <http://psg.com/lists/radiusext/>
> > > >>
> > > >
> > > >--
> > > >to unsubscribe send a message to
> > > >[email-masked] with the word 'unsubscribe' in
> > > >a single line as the message text body.
> > > >archive: <http://psg.com/lists/radiusext/>
> > > >
> > >
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 06:33:08 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Diameter compatibility of VLAN-00
Date: Thu, 23 Feb 2006 22:33:04 -0800

It would seem awkward for this document to Update RFC 4005 and 4072.  I'm 
also not entirely clear whether it would be necessary to change the ABNFs in 
those documents.

>From: "Greg Weber (gdweber)" <[email-masked]>
>To: <[email-masked]>
>CC: <[email-masked]>, <[email-masked]>
>Subject: RE: Diameter compatibility of VLAN-00
>Date: Fri, 24 Feb 2006 01:30:27 -0500
>
>
>I guess I am just observing that this is an opportunity
>to set a precedent.  I do not feel strongly about this
>issue for this particular draft, but in general, how do
>we comply with this part of the charter:
>   "RADEXT WG work items MUST contain a Diameter
>    compatibility section, outlining how
>    interoperability with Diameter will be
>    maintained."
>Saying, essentially, this RADIUS attribute can be used
>with so-and-so application may not be a clear specification
>given some of the complicated Diameter applications that
>may occur.  I don't think a Diameter AVP table is out of
>the question- do you?
>
>Greg
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, February 24, 2006 1:13 AM
> > To: Greg Weber (gdweber); [email-masked]
> > Cc: [email-masked]
> > Subject: RE: Diameter compatibility of VLAN-00
> >
> > Are you suggesting havinging Diameter AVP tables in the draft?
> >
> > John
> >
> > >> How would this work?
> > >>
> > >> Fix the typo.
> > >>
> > >> Insert a section 4 that says the following:
> > >>
> > >> 4.  Diameter Considerations
> > >>
> > >>    Diameter needs to define identical attributes with the same Type
> > >>    values.  The attributes should be available as part of
> > the NASREQ
> > >>    application [RFC4005], as well as the Diameter EAP application
> > >>    [RFC4072].
> > >>
> > >> Add Informative references to [RFC4005] and [RFC4072].
> > >
> > >It might be beneficial to set a more useful and informative
> > >precedent than was established with CUI, e.g. which messages
> > >in which applications may contain the attribute.  This would
> > >seem to be analogous to the rigor of the typical RADIUS
> > >attribute table found in most RADIUS drafts.  Disagree?
> > >
> > >Greg
> > >
> > >>
> > >> --------------------------------------------------------------
> > >> ---------------------------
> > >> Description of issue: Diameter compatibility of VLAN-00 Submitter
> > >> name: Greg Weber Submitter email address: [email-masked]
> > >Date first
> > >> submitted: February 21, 2006
> > >> Reference: NA
> > >> Document: VLAN-00
> > >> Comment type: Editorial
> > >> Priority: S
> > >> Section: NA
> > >> Rationale/Explanation of issue:
> > >>
> > >>   In the RADEXT charter, I see:
> > >>     "...all RADEXT WG work items MUST contain a Diameter
> > >>      compatibility section, outlining how interoperability
> > >>      with Diameter will be maintained."
> > >>
> > >>   The VLAN draft does not contain a Diameter compatibility
> > >>   section, but does mention (in the abstract) that these
> > >>   attributes can be used with Diameter.
> > >>
> > >> Requested change:
> > >>   The table of attributes in section 3 shows which attributes
> > >>   may be in which RADIUS messages.  Maybe another similar
> > >>   table is needed in a Diameter Compatibility section showing
> > >>   which Diameter applications/messages may include these
> > attributes.
> > >>
> > >>   Also, I see one typo that wasn't in the previous version :)
> > >>     Section 1.3:  'Unsupported Attribute"' ->
> > >>                   '"Unsupported Attribute"' (missing double quote).
> > >>
> > >>
> > >>
> > >> --
> > >> to unsubscribe send a message to
> > [email-masked] with
> > >> the word 'unsubscribe' in a single line as the message text body.
> > >> archive: <http://psg.com/lists/radiusext/>
> > >>
> > >
> > >--
> > >to unsubscribe send a message to
> > >[email-masked] with the word 'unsubscribe' in
> > >a single line as the message text body.
> > >archive: <http://psg.com/lists/radiusext/>
> > >
> >

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 06:30:53 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter compatibility of VLAN-00
Date: Fri, 24 Feb 2006 01:30:27 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

I guess I am just observing that this is an opportunity
to set a precedent.  I do not feel strongly about this
issue for this particular draft, but in general, how do
we comply with this part of the charter:
  "RADEXT WG work items MUST contain a Diameter=20
   compatibility section, outlining how
   interoperability with Diameter will be=20
   maintained."
Saying, essentially, this RADIUS attribute can be used
with so-and-so application may not be a clear specification
given some of the complicated Diameter applications that
may occur.  I don't think a Diameter AVP table is out of
the question- do you?

Greg

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> Sent: Friday, February 24, 2006 1:13 AM
> To: Greg Weber (gdweber); [email-masked]
> Cc: [email-masked]
> Subject: RE: Diameter compatibility of VLAN-00
>=20
> Are you suggesting havinging Diameter AVP tables in the draft?
>=20
> John
>=20
> >> How would this work?
> >>=20
> >> Fix the typo.
> >>=20
> >> Insert a section 4 that says the following:
> >>=20
> >> 4.  Diameter Considerations
> >>=20
> >>    Diameter needs to define identical attributes with the same Type
> >>    values.  The attributes should be available as part of=20
> the NASREQ
> >>    application [RFC4005], as well as the Diameter EAP application
> >>    [RFC4072].
> >>=20
> >> Add Informative references to [RFC4005] and [RFC4072].
> >
> >It might be beneficial to set a more useful and informative=20
> >precedent than was established with CUI, e.g. which messages=20
> >in which applications may contain the attribute.  This would=20
> >seem to be analogous to the rigor of the typical RADIUS=20
> >attribute table found in most RADIUS drafts.  Disagree?
> >
> >Greg
> >
> >>=20
> >> --------------------------------------------------------------
> >> ---------------------------
> >> Description of issue: Diameter compatibility of VLAN-00 Submitter=20
> >> name: Greg Weber Submitter email address: [email-masked]=20
> >Date first=20
> >> submitted: February 21, 2006
> >> Reference: NA
> >> Document: VLAN-00
> >> Comment type: Editorial
> >> Priority: S
> >> Section: NA
> >> Rationale/Explanation of issue:
> >>=20
> >>   In the RADEXT charter, I see:
> >>     "...all RADEXT WG work items MUST contain a Diameter
> >>      compatibility section, outlining how interoperability
> >>      with Diameter will be maintained."
> >>=20
> >>   The VLAN draft does not contain a Diameter compatibility
> >>   section, but does mention (in the abstract) that these
> >>   attributes can be used with Diameter.
> >>=20
> >> Requested change:
> >>   The table of attributes in section 3 shows which attributes
> >>   may be in which RADIUS messages.  Maybe another similar
> >>   table is needed in a Diameter Compatibility section showing
> >>   which Diameter applications/messages may include these=20
> attributes.
> >>=20
> >>   Also, I see one typo that wasn't in the previous version :)
> >>     Section 1.3:  'Unsupported Attribute"' ->
> >>                   '"Unsupported Attribute"' (missing double quote).
> >>=20
> >>=20
> >>=20
> >> --
> >> to unsubscribe send a message to=20
> [email-masked] with=20
> >> the word 'unsubscribe' in a single line as the message text body.
> >> archive: <http://psg.com/lists/radiusext/>
> >>=20
> >
> >--
> >to unsubscribe send a message to=20
> >[email-masked] with the word 'unsubscribe' in=20
> >a single line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
> >
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 06:14:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter compatibility of VLAN-00
Date: Fri, 24 Feb 2006 08:12:56 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Are you suggesting havinging Diameter AVP tables in the draft?

John

>> How would this work?
>>=20
>> Fix the typo.
>>=20
>> Insert a section 4 that says the following:
>>=20
>> 4.  Diameter Considerations
>>=20
>>    Diameter needs to define identical attributes with the same Type
>>    values.  The attributes should be available as part of the NASREQ
>>    application [RFC4005], as well as the Diameter EAP application
>>    [RFC4072].
>>=20
>> Add Informative references to [RFC4005] and [RFC4072].
>
>It might be beneficial to set a more useful and informative=20
>precedent than was established with CUI, e.g. which messages=20
>in which applications may contain the attribute.  This would=20
>seem to be analogous to the rigor of the typical RADIUS=20
>attribute table found in most RADIUS drafts.  Disagree?
>
>Greg
>
>>=20
>> --------------------------------------------------------------
>> ---------------------------
>> Description of issue: Diameter compatibility of VLAN-00 Submitter=20
>> name: Greg Weber Submitter email address: [email-masked]=20
>Date first=20
>> submitted: February 21, 2006
>> Reference: NA
>> Document: VLAN-00
>> Comment type: Editorial
>> Priority: S
>> Section: NA
>> Rationale/Explanation of issue:
>>=20
>>   In the RADEXT charter, I see:
>>     "...all RADEXT WG work items MUST contain a Diameter
>>      compatibility section, outlining how interoperability
>>      with Diameter will be maintained."
>>=20
>>   The VLAN draft does not contain a Diameter compatibility
>>   section, but does mention (in the abstract) that these
>>   attributes can be used with Diameter.
>>=20
>> Requested change:
>>   The table of attributes in section 3 shows which attributes
>>   may be in which RADIUS messages.  Maybe another similar
>>   table is needed in a Diameter Compatibility section showing
>>   which Diameter applications/messages may include these attributes.
>>=20
>>   Also, I see one typo that wasn't in the previous version :)
>>     Section 1.3:  'Unsupported Attribute"' ->
>>                   '"Unsupported Attribute"' (missing double quote).
>>=20
>>=20
>>=20
>> --
>> to unsubscribe send a message to [email-masked] with=20
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>
>>=20
>
>--
>to unsubscribe send a message to=20
>[email-masked] with the word 'unsubscribe' in=20
>a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 05:53:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Diameter compatibility of VLAN-00
Date: Fri, 24 Feb 2006 00:53:27 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, February 24, 2006 12:37 AM
> To: [email-masked]
> Subject: Re: Diameter compatibility of VLAN-00
>=20
> How would this work?
>=20
> Fix the typo.
>=20
> Insert a section 4 that says the following:
>=20
> 4.  Diameter Considerations
>=20
>    Diameter needs to define identical attributes with the same Type
>    values.  The attributes should be available as part of the NASREQ
>    application [RFC4005], as well as the Diameter EAP application
>    [RFC4072].
>=20
> Add Informative references to [RFC4005] and [RFC4072].

It might be beneficial to set a more useful and informative
precedent than was established with CUI, e.g. which messages
in which applications may contain the attribute.  This would
seem to be analogous to the rigor of the typical RADIUS
attribute table found in most RADIUS drafts.  Disagree?

Greg

>=20
> --------------------------------------------------------------
> ---------------------------
> Description of issue: Diameter compatibility of VLAN-00
> Submitter name: Greg Weber
> Submitter email address: [email-masked]
> Date first submitted: February 21, 2006
> Reference: NA
> Document: VLAN-00
> Comment type: Editorial
> Priority: S
> Section: NA
> Rationale/Explanation of issue:
>=20
>   In the RADEXT charter, I see:
>     "...all RADEXT WG work items MUST contain a Diameter
>      compatibility section, outlining how interoperability
>      with Diameter will be maintained."
>=20
>   The VLAN draft does not contain a Diameter compatibility
>   section, but does mention (in the abstract) that these
>   attributes can be used with Diameter.
>=20
> Requested change:
>   The table of attributes in section 3 shows which attributes
>   may be in which RADIUS messages.  Maybe another similar
>   table is needed in a Diameter Compatibility section showing
>   which Diameter applications/messages may include these attributes.
>=20
>   Also, I see one typo that wasn't in the previous version :)
>     Section 1.3:  'Unsupported Attribute"' ->
>                   '"Unsupported Attribute"' (missing double quote).
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 05:37:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Diameter compatibility of VLAN-00
Date: Thu, 23 Feb 2006 21:37:04 -0800

How would this work?

Fix the typo.

Insert a section 4 that says the following:

4.  Diameter Considerations

   Diameter needs to define identical attributes with the same Type
   values.  The attributes should be available as part of the NASREQ
   application [RFC4005], as well as the Diameter EAP application
   [RFC4072].

Add Informative references to [RFC4005] and [RFC4072].

-----------------------------------------------------------------------------------------
Description of issue: Diameter compatibility of VLAN-00
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: February 21, 2006
Reference: NA
Document: VLAN-00
Comment type: Editorial
Priority: S
Section: NA
Rationale/Explanation of issue:

  In the RADEXT charter, I see:
    "...all RADEXT WG work items MUST contain a Diameter
     compatibility section, outlining how interoperability
     with Diameter will be maintained."

  The VLAN draft does not contain a Diameter compatibility
  section, but does mention (in the abstract) that these
  attributes can be used with Diameter.

Requested change:
  The table of attributes in section 3 shows which attributes
  may be in which RADIUS messages.  Maybe another similar
  table is needed in a Diameter Compatibility section showing
  which Diameter applications/messages may include these attributes.

  Also, I see one typo that wasn't in the previous version :)
    Section 1.3:  'Unsupported Attribute"' ->
                  '"Unsupported Attribute"' (missing double quote).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 05:24:47 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: RADEXT WG last call on the VLAN and Priroity Attributes document
Date: Thu, 23 Feb 2006 21:24:17 -0800

Correction:  the VLAN/Priority document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt

----------------------------------------------------------------------------------------------------------

This is an announcement of RADEXT WG last call on the VLAN and Priority 
Attributes document, prior to sending it on to the IESG for consideration as 
a Proposed Standard.

RADEXT WG last call will last until Friday, March 17, 2006. Please send your
comments to the RADEXT WG mailing list ([email-masked]) in the format
described on the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Feb 2006 00:48:29 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Thu, 23 Feb 2006 16:47:46 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <mailto:[email-masked]> supposedly scribbled:

> Glen Zorn writes...
>=20
>> For the record, I didn't say that "keywrap" is out of scope, I said
>> that our draft is out of scope.
>=20
> I see that as a distinction without any difference.  Would you care
> to elaborate? =20

Not really: the document is & has been publicly available for some time; =
if it's not self-explanatory there is a serious problem.

> Is your keywrap draft about more than just keywrap?=20

>=20
>> Is that a WG document?
>=20
> The WLAN Attributes ID is an individual submission in pre-WG review,
> as a WLAN Attributes RFC is a WG milestone.=20

I see.  So all we really had to do was associate it with WLAN (kind of =
like wrapping up, say, oil drilling in a wildlife refuge with a military =
budget proposal) & everything would have been OK?  This technology is =
not specific to WLANs; the smallest possible enclosing scope might be =
EAP.  Limiting it to the delivery of EAP-related keying material is far =
too restrictive, IMHO, but that's neither here nor there.

>=20
>> Or are we to assume that anything one of the Chairs proposes is
>> automatically in scope?
>=20
> No, of course not.  The inference I had hoped to convey is that the
> chairs would likely be particularly careful about limiting the scope
> of their submissions to the scope of the WG charter. =20

See above.

>=20
>> The interesting questions are how this scope change occurred w/o a
>> change in the charter...
>=20
> The issue is a matter of interpretation, as to whether or not new
> keywap mechanisms, specifically new cipher suites for keywrap, are a
> new security mechanism for RADIUS.  The initial interpretation was
> that they were.  After a fair amount of discussion of this issue on
> the list, and a discussion with Russ Housley, I decided that they
> were not.  A new security mechanism for RADIUS would have PDU-wide
> scope,=20

What does that mean?  Can't change the header?  No new messages?  If =
that is the case, then why is draft-zorn-radius-encattr-02.txt out of =
scope?

> while a new cipher suite for keywrap affects only individual
> attributes.      =20
> Additionally, the discussion in SAAG of the need to address
> modularity of cipher suites in IETF protocols, arising out of the
> hash attacks, played into the revised interpretation. =20

Just humor a moron a bit longer: how do you expect to "address =
modularity of cipher suites" in RADIUS w/o modifying (at the very least =
the processing of) the RADIUS headers?  Is that not "PDU-wide scope"?  =
Have the rules changed?  Would it be too much to ask that the rules be =
clearly stated?  (More stupidity: I thought that that was what the WG =
charter was for.)

> I believe that
> this was all explained in previous postings to the list. =20

Instead of revising the interpretation of the charter, how about =
revising the charter, so that the WG may be spared the need to follow =
these theological discussions?
=20
>=20
>> Perhaps it also captured the fact that the conversation was an offer
>> of cooperation by myself and his "take it to the list" response was
>> in the nature of a rather curt rebuff to that offer.
>=20
> No.  That nuance did not come through.  Generally speaking, however,
> a request to discuss technical issues, the relative merits of various
> solution approaches and Internet Draft submissions on the WG mailing
> list is not considered a "rebuff".  I believe it to be at the very
> heart of the IETF process.  No?=20

Since we're talking about roles, the conversation in question was not =
between a WG member & a WG chair, but between two individual =
contributors, just in case that wasn't clear.
  =20
>=20
>> What issues would those be?  The only one I recall is the one raised
>> again by Hannes, which is patently out of scope.
>=20
> I'll review the minutes, but I recall that other issues were raised.=20
> I raised one issue about how the KEK management would occur. Your
> response was that was out of scope of the document.  I never found
> that a satisfying answer. =20

Neither do I.  Are you saying now that key management _is_ in scope of =
the radext charter?
=20
>=20
> Following up on issues, and pro-actively driving their discussion on
> the list, is incumbent upon document authors, in seeking to advance
> their drafts. =20
>=20
>> Every indication is that our draft_is considered to be unacceptable
>> by the chairs.  Bernard undoubtedly had reasons to ignore work by WG
>> members that had been in progress for more than a year at the in
>> favor of proposing a novel scheme but I, at least, am not privy to
>> them.=20
>=20
> I believe that Bernard has technical issues with your draft.  That
> fact that he chose to propose an alternate solution underscores that
> assumption. =20

Rather than, oh, say, discussing them on the list.  So much for the =
"heart of the IETF process", I guess.

> However, it is not fair to assume that *both* co-chairs
> share the same opinion in this matter.  We often agree, and typically
> work out any disagreements off-list. =20

I'm not assuming anything, merely observing your actions.
 =20
>=20
> In the case where one co-chair is acting in the capacity of an
> individual WG member, by submitting an Internet Draft for
> consideration as a WG work item, that co-chair recuses himself from
> acting in the capacity of chair in determining consensus on that
> submission.  Just as I recused myself and asked Bernard to determine
> consensus on the revised MIB IDs, I would expect Bernard to recuse
> himself and ask me to determine consensus on the WLAN ID.  (As a
> process point, we're probably in trouble on the Issues & Fixes ID, as
> both co-chairs are co-authors. :-)      =20

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Feb 2006 15:52:24 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Thu, 23 Feb 2006 10:51:50 -0500
From: "Nelson, David" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Cc: <[email-masked]>

Glen Zorn writes...
=20
> For the record, I didn't say that "keywrap" is out of scope, I said
that
> our draft is out of scope.

I see that as a distinction without any difference.  Would you care to
elaborate?  Is your keywrap draft about more than just keywrap?

> Is that a WG document?

The WLAN Attributes ID is an individual submission in pre-WG review, as
a WLAN Attributes RFC is a WG milestone.

> Or are we to assume that anything one of the Chairs proposes is
> automatically in scope?

No, of course not.  The inference I had hoped to convey is that the
chairs would likely be particularly careful about limiting the scope of
their submissions to the scope of the WG charter.

> The interesting questions are how this scope change occurred w/o a=20
> change in the charter...

The issue is a matter of interpretation, as to whether or not new keywap
mechanisms, specifically new cipher suites for keywrap, are a new
security mechanism for RADIUS.  The initial interpretation was that they
were.  After a fair amount of discussion of this issue on the list, and
a discussion with Russ Housley, I decided that they were not.  A new
security mechanism for RADIUS would have PDU-wide scope, while a new
cipher suite for keywrap affects only individual attributes.
Additionally, the discussion in SAAG of the need to address modularity
of cipher suites in IETF protocols, arising out of the hash attacks,
played into the revised interpretation.  I believe that this was all
explained in previous postings to the list.

> Perhaps it also captured the fact that the conversation was an offer
of
> cooperation by myself and his "take it to the list" response was in
the
> nature of a rather curt rebuff to that offer.

No.  That nuance did not come through.  Generally speaking, however, a
request to discuss technical issues, the relative merits of various
solution approaches and Internet Draft submissions on the WG mailing
list is not considered a "rebuff".  I believe it to be at the very heart
of the IETF process.  No?

> What issues would those be?  The only one I recall is the one raised
again
> by Hannes, which is patently out of scope.

I'll review the minutes, but I recall that other issues were raised.  I
raised one issue about how the KEK management would occur. Your response
was that was out of scope of the document.  I never found that a
satisfying answer.

Following up on issues, and pro-actively driving their discussion on the
list, is incumbent upon document authors, in seeking to advance their
drafts.=20

> Every indication is that our draft_is considered to be unacceptable by
> the chairs.  Bernard undoubtedly had reasons to ignore work by WG
members
> that had been in progress for more than a year at the in favor of
> proposing a novel scheme but I, at least, am not privy to them.

I believe that Bernard has technical issues with your draft.  That fact
that he chose to propose an alternate solution underscores that
assumption.  However, it is not fair to assume that *both* co-chairs
share the same opinion in this matter.  We often agree, and typically
work out any disagreements off-list.

In the case where one co-chair is acting in the capacity of an
individual WG member, by submitting an Internet Draft for consideration
as a WG work item, that co-chair recuses himself from acting in the
capacity of chair in determining consensus on that submission.  Just as
I recused myself and asked Bernard to determine consensus on the revised
MIB IDs, I would expect Bernard to recuse himself and ask me to
determine consensus on the WLAN ID.  (As a process point, we're probably
in trouble on the Issues & Fixes ID, as both co-chairs are co-authors.
:-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Feb 2006 09:13:40 +0000
Date: Thu, 23 Feb 2006 10:09:54 +0100
From: Julien Bournelle <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: RADEXT Milestone revisions

Hi all,

 A quick comment below,

On Tue, Feb 21, 2006 at 06:13:07PM +0100, Tschofenig, Hannes wrote:
> Hi David, 
> 
> > Hannes Tschofenig writes...
> > 
> > > wouldn't be something like radius domain of interopretation 
> > for isakmp
> > > be appropriate here.
> > 
> > I don't know.  We're talking about keywrap for specific uses, e.g.
> > 802.11.  OTOH, there is a charter prohibition on developing a new
> > security model for RADIUS.
> 
> Here is my understanding what is going on with the keywrap:
> 
> The Problem: 
>  
> EAP-derived keying material has to be sent confidentiality protected
> from the RADIUS server to the RADIUS client. 
> Intermediate proxies MUST NOT see the EAP-derived keying material.

 I'm not sure that this is really important but
 I was thinking that maybe it could be sufficient to require that the
 keying material MUST be confidentiality protected between the home AAA
 server to the Visited AAA server. The reason is that even if the Keying
 material is protected from the home AAA server to the NAS, the NAS may
 send the keying material to its local AAA server. 

 Just my 2 cents,

 -- Julien

> 
> The Solution: 
> 
> KeyWrap keys* need to be available at the RADIUS server and the RADIUS
> client to allow protected key transport between these two endpoints. 
> 
> *: These keys can either be static or dynamically established. Key
> management is known to be difficult. 
> 
> The Open Question: 
> 
> Is an out-of-band based key management really an option? 
> My argument is that you also have to care about the key management.
> Dealing also with the encryption of the EAP-derived keying material is
> not enough. 
> 
> > 
> > > there is also a rule that says "adding manpower to a late project
> > makes
> > > it later."
> > 
> > Yes.  "The Mythical Man-Month".  :-)  It is a balance, to be sure.
> >  
> > > in ecrit we scheduled an interim meeting that helped a lot 
> > to speedup
> > > the work on the document.
> > > you might also want to think about it.
> > 
> > This is something that we could consider.  Sometimes a couple 
> > of days of
> > face-time is very  helpful.  The other alternative is teleconferences.
> 
> yes, we also investigated this option. the problem is: the rules for
> official phone conferences and interim meetings are the same. this gives
> very little time for phone conferences and a face-to-face meeting is
> more efficient. 
> these rules are also probably something to revisit. 
>  
> > While providing less bandwidth, teleconferences have the 
> > benefit of not
> > requiring travel (and travel budget).
> sure. 
> 
> i am willing to host a meeting in munich, if you would like to schedule
> one.
> 
> ciao
> hannes
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Feb 2006 00:43:46 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Wed, 22 Feb 2006 16:43:16 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <mailto:[email-masked]> supposedly scribbled:

> Glen Zorn writes...
>=20
>> Since the WG Chairs informed us that our draft was outside the scope
>> of the charter, we requested publication of
> draft-zorn-radius-keywrap-09.txt
>> as an Informational RFC yesterday.
>=20
> For the record, this isn't an accurate portrayal of the situation.
> Early on, the chairs did indicate that all of your proposed
> extensions to RADIUS, including the keywrap draft, were out of scope.

In that case, you wouldn't mind if I request publication of the rest of =
those documents?

> Prior to IETF 63, however, we stated that keywrap was indeed in
> scope.  I posted that opinion to the list. =20

For the record, I didn't say that "keywrap" is out of scope, I said that =
our draft is out of scope.

> Further evidence that the
> keywrap work is in scope is obtained by its inclusion in Bernard's
> WLAN attributes draft.   =20

Is that a WG document?  Or are we to assume that anything one of the =
Chairs proposes is automatically in scope?  Or maybe keywrap magically =
became in scope when Bernard included it in a draft?  The interesting =
questions are how this scope change occurred w/o a change in the charter =
and whether the ADs share your opinion on this reversal. =20

> We discussed the pros and cons of each approach, and speculated about
> requirements for NIST certification at IETF 63.  Going out of the
> meeting, the action item was to continue discussion on the list.  I
> know that you discussed this draft with Bernard immediately after the
> closing of the RADEXT session at IETF 64, because the streaming audio
> captured your conversation. =20

Perhaps it also captured the fact that the conversation was an offer of =
cooperation by myself and his "take it to the list" response was in the =
nature of a rather curt rebuff to that offer.

> Bernard advised you to discuss the draft
> on the list, and address any issue that had been raised at IETF 63.=20

What issues would those be?  The only one I recall is the one raised =
again by Hannes, which is patently out of scope.
=20
>=20
> While you may have other reasons to choose to pursue advancement of
> your keywrap draft as an individual submission Informational RFC, the
> work being out of scope for RADEXT is certainly not one of them. =20

Every indication is that _our draft_ is considered to be unacceptable by =
the chairs.  Bernard undoubtedly had reasons to ignore work by WG =
members that had been in progress for more than a year at the in favor =
of proposing a novel scheme but I, at least, am not privy to them.

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 23:47:48 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Wed, 22 Feb 2006 15:47:34 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>

Tschofenig, Hannes <mailto:[email-masked]> supposedly =
scribbled:

> Hi Glen,
>=20
>>> ok. that's a different story. i remember these two proposals. what i
>>> disliked with them was that they do not provide a solution for
>>> dynamic authentication and key management.
>>=20
>> What do you mean by "dynamic authentication and key management"?
>=20
> Let me give you two examples:
>=20
> 1) IPsec
>=20
> IPsec AH and IPsec ESP can be used with manually configured IPsec SAs.
> You just need to create two SAs (symmetric key, algorithms, ..) at
> each end point (if you want to protect the traffic in both
> directions). =20
>=20
> Alternatively, you can use IKEv2 (or IKEv2) to establish these
> security associations. The advantage: you use a signaling protocol
> for authentication and key management. =20
>=20
> 2) TLS
>=20
> The TLS Record Layer provides protection of the data traffic. In
> order to be used you need to have fresh keying material suitable for
> the record layer available. =20
>=20
> Since the TLS Record Layer and the TLS Handshake protocol are tightly
> coupled within TLS you need to run the Handshake protocol to run the
> authentication and key exchange protocol to establish the necessary
> keying material.  =20
>=20
> Currently it seems that you worry about the actual protection of the
> keying material delivery but you don't worry about the other part of
> the story. =20

On the contrary, I'm quite concerned about the stuff you're talking =
about; problem is, the IETF is apparently not.

>=20
>=20
> Ciao
> Hannes
>>=20
>>> why isn't something
>>> tackling this issue? this would also solve the aspect of algorithm
>>> negotiation. wouldn't be something like radius domain of
>>> interopretation for isakmp be appropriate here.
>>=20
>> ...
>>=20
>> ~gwz
>>=20
>> Why is it that most of the world's problems can't be solved by simply
>>   listening to John Coltrane? -- Henry Gabriel

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 20:50:32 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-vlan-00.txt 
Date: Wed, 22 Feb 2006 15:50:02 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS VLAN and Priority Attributes

	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-vlan-00.txt
	Pages		: 13
	Date		: 2006-2-22
	
This document proposes additional attributes for dynamic VLAN
assignment and prioritization, for use by IEEE 802.1X authenticators.
These attributes are usable within either RADIUS or Diameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-radext-vlan-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-vlan-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-vlan-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-vlan-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 15:05:39 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Wed, 22 Feb 2006 10:05:14 -0500
From: "Nelson, David" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Cc: <[email-masked]>

Glen Zorn writes...
=20
> Since the WG Chairs informed us that our draft was outside the scope
of
> the charter, we requested publication of
draft-zorn-radius-keywrap-09.txt
> as an Informational RFC yesterday.

For the record, this isn't an accurate portrayal of the situation.
Early on, the chairs did indicate that all of your proposed extensions
to RADIUS, including the keywrap draft, were out of scope.  Prior to
IETF 63, however, we stated that keywrap was indeed in scope.  I posted
that opinion to the list.  Further evidence that the keywrap work is in
scope is obtained by its inclusion in Bernard's WLAN attributes draft.
We discussed the pros and cons of each approach, and speculated about
requirements for NIST certification at IETF 63.  Going out of the
meeting, the action item was to continue discussion on the list.  I know
that you discussed this draft with Bernard immediately after the closing
of the RADEXT session at IETF 64, because the streaming audio captured
your conversation.  Bernard advised you to discuss the draft on the
list, and address any issue that had been raised at IETF 63.

While you may have other reasons to choose to pursue advancement of your
keywrap draft as an individual submission Informational RFC, the work
being out of scope for RADEXT is certainly not one of them.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 14:33:52 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Wed, 22 Feb 2006 15:33:29 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

> >Some early versions of the ieee802 draft (when it wasn't a WG draft)
> >had the Redirect-Host attribute. Would there be any chance of taking
> >it back and include e.g. to the redirection attributes draft?
> >
> >Actually I don't remember why it got dropped out of the WG draft
> >in the first place.
>=20
> As I recall, the Redirect-Host attribute was somewhat=20
> different in usage=20
> from the redirection attributes, since it related to RADIUS=20
> re-direction (a=20
> la Diameter) rather than redirection of data packets.

Yep.

> If I remember correctly, the WG feedback was that this was=20
> something that=20
> probably would only be implemented in Diameter.

I was just asking because recently e.g. in 3GPP use cases have
popped up that would have use for Redirect-Host also in RADIUS
(and then remembered early draft revision having the attribute).

cheers,
	Jouni

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 10:39:28 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Milestone revisions
Date: Wed, 22 Feb 2006 11:38:29 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Glen,=20

> > ok. that's a different story. i remember these two proposals. what i
> > disliked with them was that they do not provide a solution for
> > dynamic authentication and key management.=20
>=20
> What do you mean by "dynamic authentication and key management"?

Let me give you two examples:

1) IPsec

IPsec AH and IPsec ESP can be used with manually configured IPsec SAs.
You just need to create two SAs (symmetric key, algorithms, ..) at each
end point (if you want to protect the traffic in both directions).=20

Alternatively, you can use IKEv2 (or IKEv2) to establish these security
associations. The advantage: you use a signaling protocol for
authentication and key management.=20

2) TLS

The TLS Record Layer provides protection of the data traffic. In order
to be used you need to have fresh keying material suitable for the
record layer available.=20

Since the TLS Record Layer and the TLS Handshake protocol are tightly
coupled within TLS you need to run the Handshake protocol to run the
authentication and key exchange protocol to establish the necessary
keying material.=20

Currently it seems that you worry about the actual protection of the
keying material delivery but you don't worry about the other part of the
story.=20
=20

Ciao
Hannes
>=20
> > why isn't something
> > tackling this issue? this would also solve the aspect of algorithm
> > negotiation. wouldn't be something like radius domain of
> > interopretation for isakmp be appropriate here.
>    =20
> ...
>=20
> ~gwz
>=20
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 06:18:31 +0000
Content-class: urn:content-classes:message
Subject: RE: [Dime] RE: RADEXT Agenda for IETF65, Take Two
Date: Wed, 22 Feb 2006 08:18:09 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

David,

My opinion is:

>> One of the items on the DIME WG agenda will probably be RFC 3588bis,=20
>> which includes the definition of the NAS-Filter-Rule syntax.
>> However, the DIME WG milestones involve bringing RFC 3588 to Draft=20
>> Standard, which typically precludes addition of new features.
>
>Does that mean that DIME has to choose between advancing to=20
>the base Diameter protocol to DS and maintaining compatibility=20
>with RADIUS Extensions?  Both are charter items for DIME. =20
>Tough choice.
>
>I think it would be a mistake for RADEXT to standardize a=20
>non-interoperable extension to NAS-Filter-Rule, and that our=20
>charter requirement of maintaining Diameter compatibility=20
>would potentially preclude such action, in any event.

Better to do what is correct.  The DiME wg would like feedback about
the NAS-Filter-Rule - is the communitity happy with the current
definition,
or does it want to be improved or changed.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 05:29:34 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 21:28:51 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>

Tschofenig, Hannes <> supposedly scribbled:

...

> ok. that's a different story. i remember these two proposals. what i
> disliked with them was that they do not provide a solution for
> dynamic authentication and key management.=20

What do you mean by "dynamic authentication and key management"?

> why isn't something
> tackling this issue? this would also solve the aspect of algorithm
> negotiation. wouldn't be something like radius domain of
> interopretation for isakmp be appropriate here.
   =20
...

~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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 05:29:26 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 21:28:57 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> supposedly scribbled:

> Hannes Tschofenig writes...
>=20
>> i know about these activites. i wasn't quite sure how it effects the
>> http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt
>> document.
>=20
> There are two proposals that deal with key management and
> distribution via RADIUS, Bernard's draft and a draft from Glen Zorn.=20
> These were discussed in more depth at IETF 63. =20
>=20

Since the WG Chairs informed us that our draft was outside the scope of =
the charter, we requested publication of =
draft-zorn-radius-keywrap-09.txt as an Informational RFC yesterday.

~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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 00:30:48 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 16:30:32 -0800

>Does that mean that DIME has to choose between advancing to the base
>Diameter protocol to DS and maintaining compatibility with RADIUS
>Extensions?

Not necessarily.  It may be possible to bring RFC 3588bis to Draft Standard 
while handling NAS-Filter-Rule extensions in another document, at Proposed 
Standard.

At this point, I'm not clear about what will be covered in the Diameter 
Interop event (for example, how will interop testing of the 
"NAS-Filter-Rule" feature be handled?)

>I think it would be a mistake for RADEXT to standardize a
>non-interoperable extension to NAS-Filter-Rule, and that our charter
>requirement of maintaining Diameter compatibility would potentially
>preclude such action, in any event.

Right. The original NAS-Filter-Rule syntax was defined in RFC 3588, and the 
NAS-Filter-Rule attribute is defined in RFC 4005, so that changes to the 
syntax cannot evolve independently without impacting Diameter.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Feb 2006 00:09:34 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: [Issue] Diameter compatibility of VLAN-00
Date: Tue, 21 Feb 2006 16:09:04 -0800

Good point.  For example, RFC 4372 Section 4 says:

"   Diameter needs to define an identical attribute with the same Type
   value.  The CUI should be available as part of the NASREQ application
   [RFC4005]."

Something along those lines might work here.  Since the RADIUS Type values 
would already have been allocated, Diameter would inherit these attributes, 
but still needs to define their behavior.
It seems like these attributes would be used primarily with the Diameter EAP 
application (wouldn't CUI be used there too?), and perhaps Diameter NASREQ.

One question comes to mind though.

Diameter requires a new application ID to be allocated when mandatory 
attributes are added.  I'm not sure whether use of these attributes with 
Diameter EAP or Diameter NASREQ would require that, however.

>From: "Greg Weber (gdweber)" <[email-masked]>
>To: <[email-masked]>
>Subject: [Issue]  Diameter compatibility of VLAN-00
>Date: Tue, 21 Feb 2006 17:34:42 -0500
>
>
>Description of issue: Diameter compatibility of VLAN-00
>Submitter name: Greg Weber
>Submitter email address: [email-masked]
>Date first submitted: February 21, 2006
>Reference: NA
>Document: VLAN-00
>Comment type: Editorial
>Priority: S
>Section: NA
>Rationale/Explanation of issue:
>
>   In the RADEXT charter, I see:
>     "...all RADEXT WG work items MUST contain a Diameter
>      compatibility section, outlining how interoperability
>      with Diameter will be maintained."
>
>   The VLAN draft does not contain a Diameter compatibility
>   section, but does mention (in the abstract) that these
>   attributes can be used with Diameter.
>
>Requested change:
>   The table of attributes in section 3 shows which attributes
>   may be in which RADIUS messages.  Maybe another similar
>   table is needed in a Diameter Compatibility section showing
>   which Diameter applications/messages may include these attributes.
>
>   Also, I see one typo that wasn't in the previous version :)
>     Section 1.3:  'Unsupported Attribute"' ->
>                   '"Unsupported Attribute"' (missing double quote).
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 21 Feb 2006 23:03:24 +0000
From: "Alan DeKok" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
Subject: Re: RADIUS-Geopriv: Request for review 
cc: [email-masked], [email-masked]
Date: Tue, 21 Feb 2006 18:10:04 -0500
Message-Id: <[email-masked]>

On Sun, Feb 12, 2006 at 10:10:45PM +0100, Tschofenig, Hannes wrote:

> I have submitted an update for the RADIUS-Geopriv draft. Before it
> appears on the draft announcement list please find it at:
>
> http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.txt
> http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.html

  The Operator-Name attribute does not follow existing RADIUS data
types.  Packing multiple pieces of data into one attribute should be
discouraged.

  The Location-Information attribute is even more complicated.  And
the format of the attribute changes depending on field values.  This
is a recipe for disaster.  At the minimum, the Location-Info field
should be removed from Location-Information, and replaced with two new
attributes: Location-Civic-Information and
Location-Geospatial-Information.

  And defining the resolution & latitude data as non-byte aligned is
another recipe for disaster.  It would cost almost nothing to align
the fields, and would significantly increase inter-operability and
decrease deployment problems.

  If the unaligned data is taken from another standard, then the
fields should be left undefined here.  Rather than explicitely
describing them, the attribute contents should instead be a normitive
reference to another data structure.  And I don't see any normitive
reference to a document describing these fields, so it looks like the
geospatial attribute format was created specifically for this I-D.

  In that case, it is even more of a requirement that the format be
fixed before this document moves forward.

  For the Requested-Info attribute, it would be best to describe it as
a bit array, rather than saying things like "a numerical value of this
attribute is 8".  If it's a bit array, then the fields have offsets
with the array, but have no numerical value.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 22:34:02 +0000
Content-class: urn:content-classes:message
Subject: [Issue]  Diameter compatibility of VLAN-00
Date: Tue, 21 Feb 2006 17:34:42 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Diameter compatibility of VLAN-00
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: February 21, 2006
Reference: NA
Document: VLAN-00
Comment type: Editorial
Priority: S
Section: NA
Rationale/Explanation of issue:

  In the RADEXT charter, I see:
    "...all RADEXT WG work items MUST contain a Diameter=20
     compatibility section, outlining how interoperability=20
     with Diameter will be maintained."

  The VLAN draft does not contain a Diameter compatibility
  section, but does mention (in the abstract) that these=20
  attributes can be used with Diameter.

Requested change:
  The table of attributes in section 3 shows which attributes
  may be in which RADIUS messages.  Maybe another similar
  table is needed in a Diameter Compatibility section showing
  which Diameter applications/messages may include these attributes.

  Also, I see one typo that wasn't in the previous version :)
    Section 1.3:  'Unsupported Attribute"' ->=20
                  '"Unsupported Attribute"' (missing double quote).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 22:17:30 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 14:17:19 -0800

>Some early versions of the ieee802 draft (when it wasn't a WG draft)
>had the Redirect-Host attribute. Would there be any chance of taking
>it back and include e.g. to the redirection attributes draft?
>
>Actually I don't remember why it got dropped out of the WG draft
>in the first place.

As I recall, the Redirect-Host attribute was somewhat different in usage 
from the redirection attributes, since it related to RADIUS re-direction (a 
la Diameter) rather than redirection of data packets.

If I remember correctly, the WG feedback was that this was something that 
probably would only be implemented in Diameter.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 21:46:46 +0000
Content-class: urn:content-classes:message
Subject: New WG Milestones on-line
Date: Tue, 21 Feb 2006 16:46:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The RADEXT WG Charter page at
http://www.ietf.org/html.charters/radext-charter.html has been updated
with the current documents and milestone dates.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 21:45:29 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 22:45:11 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi,

> With respect to the new milestones for the 802-related documents, they
> are:
>=20
> April 2006   RADIUS VLAN and Priority Attributes draft submitted as a
>              Proposed Standard RFC (reduced in scope)
>=20
> Oct 2006     RADIUS Filtering Attributes draft submitted as a Proposed
>              Standard RFC (split out from VLAN & Priority draft)
>=20
> Dec 2006     RADIUS Redirection Attributes draft submitted as=20
> a Proposed
>              Standard RFC (split out from VLAN & Priority draft)

Some early versions of the ieee802 draft (when it wasn't a WG draft)
had the Redirect-Host attribute. Would there be any chance of taking
it back and include e.g. to the redirection attributes draft?

Actually I don't remember why it got dropped out of the WG draft
in the first place.

> The original plan for agenda item D.2.1 was to review and discuss any
> WGLC issues on the VLAN & Priority draft.  If there is time left over,
> other 802-related issues could also be discussed in that slot.
>=20
> It is my opinion that the work on Filtering Attributes will require
> coordination with the DIME WG.  The work on Redirection is=20
> dependent on
> the Filtering work.

Cheers,
	Jouni

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 21:03:14 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 16:02:21 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba writes...
=20
> One of the items on the DIME WG agenda will probably be RFC 3588bis,
> which includes the definition of the NAS-Filter-Rule syntax. =20
> However, the DIME WG milestones involve bringing RFC 3588 to Draft
> Standard, which typically precludes addition of new features.

Does that mean that DIME has to choose between advancing to the base
Diameter protocol to DS and maintaining compatibility with RADIUS
Extensions?  Both are charter items for DIME.  Tough choice.

I think it would be a mistake for RADEXT to standardize a
non-interoperable extension to NAS-Filter-Rule, and that our charter
requirement of maintaining Diameter compatibility would potentially
preclude such action, in any event.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 20:18:05 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 12:17:49 -0800

>Will there also be time available for other items?

Unless there are a lot of unforseen issues posted relating to the 
VLAN/Priority draft, it seems unlikely that discussion of this item will 
take 30 minutes.  The rest of the time can be devoted to other features of 
the IEEE 802 document.

>It is my opinion that the work on Filtering Attributes will require 
>coordination with the DIME WG.

One of the items on the DIME WG agenda will probably be RFC 3588bis, which 
includes the definition of the NAS-Filter-Rule syntax.  However, the DIME WG 
milestones involve bringing RFC 3588 to Draft Standard, which typically 
precludes addition of new features.

The NEA BOF may also be discussing filtering issues.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 18:47:44 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 13:46:53 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Mauricio Sanchez writes...
=20
> Does D.2.1 incorporate all the topics of the ieee802 draft (now
split)?

It *could*, *if* all those issues can be thoroughly covered in the
allotted time.  The theme for RADEXT at IETF 65 is "Getting to Done",
which means focusing sufficient time on short-term deliverables to
support the new milestone dates, which will appear on the RADEXT WG web
page later today (or so the Secretariat informs me).  Having negotiated
and established new deliverable dates, the chairs obviously wish to
avoid any future schedule slips.

With respect to the new milestones for the 802-related documents, they
are:

April 2006   RADIUS VLAN and Priority Attributes draft submitted as a
             Proposed Standard RFC (reduced in scope)

Oct 2006     RADIUS Filtering Attributes draft submitted as a Proposed
             Standard RFC (split out from VLAN & Priority draft)

Dec 2006     RADIUS Redirection Attributes draft submitted as a Proposed
             Standard RFC (split out from VLAN & Priority draft)

The original plan for agenda item D.2.1 was to review and discuss any
WGLC issues on the VLAN & Priority draft.  If there is time left over,
other 802-related issues could also be discussed in that slot.

It is my opinion that the work on Filtering Attributes will require
coordination with the DIME WG.  The work on Redirection is dependent on
the Filtering work.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 18:32:26 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 10:31:54 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Does D.2.1 incorporate all the topics of the ieee802 draft (now split)?

MS=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, February 20, 2006 9:13 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RADEXT Agenda for IETF65, Take Two
>=20
>=20
> Agenda for the RADEXT WG Meeting at IETF 65 TUESDAY, March=20
> 21, 2006 0900-1130 Morning Session I
>=20
> A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes)
>=20
> B. Agenda Bashing
>=20
> C. Milestone Revisions (5 minutes)
>=20
> D. Document Status
>=20
> D.1 Documents in IESG review (20 minutes):
>=20
> D.1.1  RADIUS Digest Authentication: 10 minutes for=20
> discussion of IESG review.
> =20
> D.1.2  RFC 3576 MIBs: 5 minutes for discussion of IESG review.
> =20
> D.1.2  RFC 2618bis-2621bis: 5 minutes for discussion of IESG review.
> =20
> D.2  Documents in WGLC issue resolution (30 minutes):
>=20
> D.2.1  VLAN/Priority: 30 minutes for discussion of WGLC issues.
> =20
> D.3  Documents in Pre-WG review (60 minutes):
>=20
> D.3.1  WLAN Attributes: 10 minutes for discussion of current status.
> =20
> D.3.2  Design Guidelines:  30 minutes to discuss the open=20
> issues, including any "capabilities" discussion. It this=20
> document ready for formal acceptance as a WG work item?
> =20
> D.3.3  Issues & Fixes:  10 minutes discussion.  It this=20
> document ready for formal acceptance as a WG work item?
>=20
> D.3.4  Prepaid Extensions:  10 minutes for discussion of=20
> revised (-10) draft.
>=20
> D.4  Documents requiring cross-WG review (25 minutes):
>=20
> D.4.1  GEOPRIV-RADIUS:  20 minutes to discuss the status of=20
> the solution being crafted by Emile & Hannes.
> =20
> D.4.2  RADIUS Prefix Delegation: 5 Minutes to discuss the=20
> review was posted to the mailing list.
>=20
> E. Wrap-Up (5 minutes)
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 18:30:08 +0000
Content-class: urn:content-classes:message
Subject: RE: QoS and IEEE 802
Date: Tue, 21 Feb 2006 13:29:23 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hannes Tschofenig writes...

> it is interesting to hear that you think that the generic RADIUS QoS
will
> also be done in Dime.

That is my understanding of the agreement among the affected WG Chairs
and Area Directors, coming out of the discussion of where to do this
work, held at IETF 63.

DIME will coordinate with RADEXT as may be necessary.  That's not to say
that the generic QoS solution for RADIUS will be at parity with that for
Diameter.  That remains to be discussed.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 18:17:21 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT WG last call on the VLAN and Priority Attributes document
Date: Tue, 21 Feb 2006 19:16:40 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

i guess it was unnecessary for me to ask what will go into the document. =
i should have just waited a few more minutes.=20

i always thought that i quickly write ietf drafts....

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> Gesendet: Dienstag, 21. Februar 2006 18:57
> An: [email-masked]
> Betreff: RADEXT WG last call on the VLAN and Priority=20
> Attributes document
>=20
> This is an announcement of RADEXT WG last call on the VLAN=20
> and Priority=20
> Attributes document, prior to sending it on to the IESG for=20
> consideration as=20
> a Proposed Standard.
>=20
> When it shows up on the IETF archive, the document will be=20
> available here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-pri
> ority-00.txt
>=20
> Until then, it is available for inspection here:
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-pr
> iority-00.txt
>=20
> RADEXT WG last call will last until Friday, March 17, 2006. =20
> Please send=20
> your
> comments to the RADEXT WG mailing list ([email-masked])=20
> in the format
> described on the RADEXT Issues list:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 18:09:16 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 10:09:00 -0800

The crypto-agility work item will focus on the negotiation of cryptographic 
algorithms within existing RADIUS security mechanisms.

As has been discussed recently in SAAG, the recent attacks against popular 
hashes such as MD5 and SHA1 have raised awareness of this problem.  The IETF 
will be undertaking work on crypto-agility within a number of protocols, 
including TLS.  It has been suggested that the issue is serious in RADIUS 
because the protocol uses straight MD5 in places, rather than HMAC-MD5 or 
HMAC-SHA1.  Given the rate of advance of hash attacks, and the lag time 
involved in producing standards, it is best to get work on RADIUS 
crypto-agility underway sooner rather than later.

Note that this work item does not require solving all the security problems 
in RADIUS, just providing support for the negotiation of algorithms within 
exitsing security mechanisms.  For example, issues relating to end-to-end 
encryption of RADIUS attributes or integration of RADIUS and Kerberos are 
out of scope.  It is also not an explicit goal to enable RADIUS to be 
certified for FIPS 140-2, although support for negotiation of FIPS approved 
algorithms is likely to be an end result.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:57:23 +0000
Content-class: urn:content-classes:message
Subject: AW: QoS and IEEE 802
Date: Tue, 21 Feb 2006 18:34:29 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi David,=20

it is interesting to hear that you think that the generic RADIUS QoS =
will also be done in Dime.=20
Fine for me.=20

Ciao
Hannes

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Nelson, David
> Gesendet: Dienstag, 21. Februar 2006 18:07
> An: [email-masked]
> Cc: [email-masked]
> Betreff: RE: QoS and IEEE 802
>=20
> Hannes Tschofenig writes...
>=20
> > > draft-ietf-radext-vlan-priority-00.txt
> > > draft-ietf-radext-filter-rules-00.txt
> > > draft-ietf-radext-redirection-00.txt
> >=20
> > Is the first document about QoS (is priority QoS for you)?
>=20
> No.  The draft includes IEEE 802.1 priority queues.  It does=20
> not extend
> to anything like RSVP or DiffServ.  We agreed that the "full" QoS work
> would take place in the DIME WG, with coordination with RADEXT as
> needed.
>=20
> > What are your thoughts about a common QoS approach?=20
> Different IEEE 802
> > standards specify different QoS parameters and require RADIUS
> > interaction. There is work in 3GPP2 and ongoing work in Wimax.
> Recently
> > someone posted a draft about the DSL proposal in this area.=20
> I ask this
> > question because I noticed that you seem to like a unified approach.
>=20
> Yes, a unified approach would be highly desirable.  As indicated, DIME
> has the lead on this.
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:57:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG last call on the VLAN and Priority Attributes document
Date: Tue, 21 Feb 2006 09:56:39 -0800

This is an announcement of RADEXT WG last call on the VLAN and Priority 
Attributes document, prior to sending it on to the IESG for consideration as 
a Proposed Standard.

When it shows up on the IETF archive, the document will be available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-priority-00.txt

Until then, it is available for inspection here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-priority-00.txt

RADEXT WG last call will last until Friday, March 17, 2006.  Please send 
your
comments to the RADEXT WG mailing list ([email-masked]) in the format
described on the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 21 Feb 2006 17:45:19 +0000
From: "Alan DeKok" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
Subject: Re: AW: AW: RADEXT Milestone revisions 
cc: "Nelson, David" <[email-masked]>, [email-masked]
Date: Tue, 21 Feb 2006 12:52:17 -0500
Message-Id: <[email-masked]>

"Tschofenig, Hannes" <[email-masked]> wrote:
> This work tried to accomplish a different goal. It tried to develop a
> solution for initial enrollment between the RADIUS client and the RADIUS
> server if they are in the same administrative domain. BUT: The problem
> we are dealing with appears if you consider cases where the RADIUS
> client and the RADIUS server are in different administrative domains.

  I think the problems are related.

  The client has to somehow start a trust session with a server.  It
doesn't really matter if the server is in the same administrative
domain or another one.  The "bootstrap" problem still exists.  And the
bootstrap of the remote trust first depends on bootstrapping local
trust.  So why not use the same process for both?

  Within the same domain, the client kickstart proposal works.  Going
across domains, the "local" admin can get a key from the "remote"
admin, and give it to the client.  The client can then use a procedure
similar to kickstart to initiate a session with the remote
administrative domain.

  The problem then is that the client has to manage trust with a large
number of remote domains, and that trust may not be tied to any one
authentication session.  That's a serious problem.

> In the first place I wanted to better understand the problem that needs
> to be solved.

  Exactly.  If it's end-to-end encryption, Diameter would appear to be
the solution.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:44:21 +0000
Content-class: urn:content-classes:message
Subject: AW: AW: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 18:43:51 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Bernard,=20

I wasn't aware of this work. It would be good to know whether there is =
interesting to solve the key management aspect given the limitations of =
RADIUS.=20

Are you (and Glen) going to provide a solution as part of the keywrap =
work?=20

Ciao
Hannes
=20

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> Gesendet: Dienstag, 21. Februar 2006 18:30
> An: [email-masked]
> Betreff: Re: AW: RADEXT Milestone revisions
>=20
> >There was also the Kerberos & RADIUS draft, but I can't find=20
> a link to it,=20
> >either.
>=20
> Here it is:
> http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt
>=20
> Note that this approach was discussed in AAA WG, and rejected=20
> in favor of=20
> CMS.  However, there was subsequently not enough interest in=20
> CMS to proceed.=20
>   I believe that the approach described in the document was=20
> in the process=20
> of being implemented.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:41:19 +0000
Content-class: urn:content-classes:message
Subject: RE: QoS and IEEE 802
Date: Tue, 21 Feb 2006 09:41:01 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>, <[email-masked]>

Yes, I was talking about 2.4.

If there is to be a separate draft-ietf-radext-vlan-priority-00.txt
draft.  I would suggest it contain the following attributes from the
following current sections:

	2.1.      Egress-VLANID=20
      2.2.      Ingress-Filters=20
      2.3.      Egress-VLAN-Name=20
      2.4.      User-Priority-Table

Paul
=20
> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[email-masked]]=20
> Sent: Tuesday, February 21, 2006 9:34 AM
> To: Congdon, Paul T (ProCurve); [email-masked]
> Subject: AW: QoS and IEEE 802
>=20
> Hi Paul,=20
>=20
> thanks for your quick response.=20
>=20
> > > Is the first document about QoS (is priority QoS for you)?=20
> >=20
> > The 802 priority attributes define a standard mechanism to=20
> configure=20
> > the standard 802.1 priority regeneration table.  They do=20
> not deal with=20
> > bandwidth allocations, reservations, schedulers, markers, meters...
> > They simply make a mapping of the incoming priority of a=20
> frame to one=20
> > of the eight 802 classes of service.  This is fairly simple and in=20
> > support of an existing standard, so I would argue they do=20
> not need to=20
> > become part of a larger common QoS approach.  There are no current=20
> > open issues related to this attribute.
> >=20
>=20
> Do you refer to the Section 2.4. User-Priority-Table ?
>=20
> I will take a look at the referenced document ([IEEE802.1D]).=20
> a few references are missing, btw.
>=20
> Is the content of this attribute going to be dumped into=20
> > draft-ietf-radext-vlan-priority-00.txt
> What else will go into this draft?=20
>=20
> Ciao
> Hannes
>=20
> > Paul
> >=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:34:54 +0000
Content-class: urn:content-classes:message
Subject: AW: QoS and IEEE 802
Date: Tue, 21 Feb 2006 18:34:28 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Congdon, Paul T \(ProCurve\)" <[email-masked]>, <[email-masked]>

Hi Paul,=20

thanks for your quick response.=20

> > Is the first document about QoS (is priority QoS for you)?=20
>=20
> The 802 priority attributes define a standard mechanism to=20
> configure the
> standard 802.1 priority regeneration table.  They do not deal with
> bandwidth allocations, reservations, schedulers, markers, meters...
> They simply make a mapping of the incoming priority of a=20
> frame to one of
> the eight 802 classes of service.  This is fairly simple and=20
> in support
> of an existing standard, so I would argue they do not need to become
> part of a larger common QoS approach.  There are no current=20
> open issues
> related to this attribute.
>=20

Do you refer to the Section 2.4. User-Priority-Table ?

I will take a look at the referenced document ([IEEE802.1D]). a few
references are missing, btw.

Is the content of this attribute going to be dumped into=20
> draft-ietf-radext-vlan-priority-00.txt
What else will go into this draft?=20

Ciao
Hannes

> Paul
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:34:39 +0000
Content-class: urn:content-classes:message
Subject: AW: AW: RADEXT Milestone revisions 
Date: Tue, 21 Feb 2006 18:34:27 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Alan,=20

> "Tschofenig, Hannes" <[email-masked]> wrote:
> > ok. that's a different story. i remember these two proposals. what i
> > disliked with them was that they do not provide a solution=20
> for dynamic
> > authentication and key management. why isn't something tackling this
> > issue?
>=20
>   Bob Moscowitz and I came up with something related a few years back:
>=20
>   http://www3.ietf.org/proceedings/03nov/slides/radext-4.pdf
>=20
>   I'll try to find a draft of the document, too.  It never went
> anywhere, though.

This work tried to accomplish a different goal. It tried to develop a
solution for initial enrollment between the RADIUS client and the RADIUS
server if they are in the same administrative domain. BUT: The problem
we are dealing with appears if you consider cases where the RADIUS
client and the RADIUS server are in different administrative domains.=20

>=20
>   There was also the Kerberos & RADIUS draft, but I can't find a link
> to it, either.

Interesting. I think I don't know this one.=20

In the first place I wanted to better understand the problem that needs
to be solved.=20

Ciao
Hannes

>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:29:48 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: AW: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 09:29:35 -0800

>There was also the Kerberos & RADIUS draft, but I can't find a link to it, 
>either.

Here it is:
http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt

Note that this approach was discussed in AAA WG, and rejected in favor of 
CMS.  However, there was subsequently not enough interest in CMS to proceed. 
  I believe that the approach described in the document was in the process 
of being implemented.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:13:24 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 18:13:07 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Hi David,=20

> Hannes Tschofenig writes...
>=20
> > wouldn't be something like radius domain of interopretation=20
> for isakmp
> > be appropriate here.
>=20
> I don't know.  We're talking about keywrap for specific uses, e.g.
> 802.11.  OTOH, there is a charter prohibition on developing a new
> security model for RADIUS.

Here is my understanding what is going on with the keywrap:

The Problem:=20
=20
EAP-derived keying material has to be sent confidentiality protected
from the RADIUS server to the RADIUS client.=20
Intermediate proxies MUST NOT see the EAP-derived keying material.

The Solution:=20

KeyWrap keys* need to be available at the RADIUS server and the RADIUS
client to allow protected key transport between these two endpoints.=20

*: These keys can either be static or dynamically established. Key
management is known to be difficult.=20

The Open Question:=20

Is an out-of-band based key management really an option?=20
My argument is that you also have to care about the key management.
Dealing also with the encryption of the EAP-derived keying material is
not enough.=20

>=20
> > there is also a rule that says "adding manpower to a late project
> makes
> > it later."
>=20
> Yes.  "The Mythical Man-Month".  :-)  It is a balance, to be sure.
> =20
> > in ecrit we scheduled an interim meeting that helped a lot=20
> to speedup
> > the work on the document.
> > you might also want to think about it.
>=20
> This is something that we could consider.  Sometimes a couple=20
> of days of
> face-time is very  helpful.  The other alternative is teleconferences.

yes, we also investigated this option. the problem is: the rules for
official phone conferences and interim meetings are the same. this gives
very little time for phone conferences and a face-to-face meeting is
more efficient.=20
these rules are also probably something to revisit.=20
=20
> While providing less bandwidth, teleconferences have the=20
> benefit of not
> requiring travel (and travel budget).
sure.=20

i am willing to host a meeting in munich, if you would like to schedule
one.

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 21 Feb 2006 17:10:47 +0000
From: "Alan DeKok" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
Subject: Re: AW: RADEXT Milestone revisions 
cc: "Nelson, David" <[email-masked]>, [email-masked]
Date: Tue, 21 Feb 2006 12:17:42 -0500
Message-Id: <[email-masked]>

"Tschofenig, Hannes" <[email-masked]> wrote:
> ok. that's a different story. i remember these two proposals. what i
> disliked with them was that they do not provide a solution for dynamic
> authentication and key management. why isn't something tackling this
> issue?

  Bob Moscowitz and I came up with something related a few years back:

  http://www3.ietf.org/proceedings/03nov/slides/radext-4.pdf

  I'll try to find a draft of the document, too.  It never went
anywhere, though.

  There was also the Kerberos & RADIUS draft, but I can't find a link
to it, either.  

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:07:49 +0000
Content-class: urn:content-classes:message
Subject: RE: QoS and IEEE 802
Date: Tue, 21 Feb 2006 12:07:20 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hannes Tschofenig writes...

> > draft-ietf-radext-vlan-priority-00.txt
> > draft-ietf-radext-filter-rules-00.txt
> > draft-ietf-radext-redirection-00.txt
>=20
> Is the first document about QoS (is priority QoS for you)?

No.  The draft includes IEEE 802.1 priority queues.  It does not extend
to anything like RSVP or DiffServ.  We agreed that the "full" QoS work
would take place in the DIME WG, with coordination with RADEXT as
needed.

> What are your thoughts about a common QoS approach? Different IEEE 802
> standards specify different QoS parameters and require RADIUS
> interaction. There is work in 3GPP2 and ongoing work in Wimax.
Recently
> someone posted a draft about the DSL proposal in this area. I ask this
> question because I noticed that you seem to like a unified approach.

Yes, a unified approach would be highly desirable.  As indicated, DIME
has the lead on this.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:02:49 +0000
Content-class: urn:content-classes:message
Subject: RE: QoS and IEEE 802
Date: Tue, 21 Feb 2006 09:02:38 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>, <[email-masked]>

>=20
> Is the first document about QoS (is priority QoS for you)?=20

The 802 priority attributes define a standard mechanism to configure the
standard 802.1 priority regeneration table.  They do not deal with
bandwidth allocations, reservations, schedulers, markers, meters...
They simply make a mapping of the incoming priority of a frame to one of
the eight 802 classes of service.  This is fairly simple and in support
of an existing standard, so I would argue they do not need to become
part of a larger common QoS approach.  There are no current open issues
related to this attribute.

Paul

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 17:01:03 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 12:00:08 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Hannes Tschofenig writes...

> wouldn't be something like radius domain of interopretation for isakmp
> be appropriate here.

I don't know.  We're talking about keywrap for specific uses, e.g.
802.11.  OTOH, there is a charter prohibition on developing a new
security model for RADIUS.

> there is also a rule that says "adding manpower to a late project
makes
> it later."

Yes.  "The Mythical Man-Month".  :-)  It is a balance, to be sure.
=20
> in ecrit we scheduled an interim meeting that helped a lot to speedup
> the work on the document.
> you might also want to think about it.

This is something that we could consider.  Sometimes a couple of days of
face-time is very  helpful.  The other alternative is teleconferences.
While providing less bandwidth, teleconferences have the benefit of not
requiring travel (and travel budget).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 16:57:07 +0000
Content-class: urn:content-classes:message
Subject: QoS and IEEE 802
Date: Tue, 21 Feb 2006 17:56:50 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>

Hi Bernard,=20
Hi David,=20

> a. The work now represented by the IEEE 802 document will be=20
> split into=20
> three separate documents, one focused on VLAN/Priority, one on basic=20
> filtering, and another document on redirection.
>=20
> The pre-approved WG work item draft file names are:
>=20
> draft-ietf-radext-vlan-priority-00.txt
> draft-ietf-radext-filter-rules-00.txt
> draft-ietf-radext-redirection-00.txt

Is the first document about QoS (is priority QoS for you)?=20

What are your thoughts about a common QoS approach? Different IEEE 802
standards specify different QoS parameters and require RADIUS
interaction. There is work in 3GPP2 and ongoing work in Wimax. Recently
someone posted a draft about the DSL proposal in this area. I ask this
question because I noticed that you seem to like a unified approach.=20

Ciao
Hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 16:48:43 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 17:48:21 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

interesting. maybe you want to add this type of background to the draft. =
=20

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> Gesendet: Dienstag, 21. Februar 2006 17:03
> An: [email-masked]
> Betreff: RE: RADEXT Milestone revisions
>=20
> >maybe i haven't paid enough attention to this document. i actually do
> >not quite understand its background. the abstract says:
> >
> >This document proposes additional attributes for use by
> >IEEE 802.11 authenticators.  The attributes defined in this document
> >are compatible with those used within Diameter EAP.
> >http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt
> >
> >how does this relate to existing deployment? aren't we a=20
> little bit late
> >specifying these attributes (although i think they are very useful).
>=20
> 802.11 is developing new standards to enable applications=20
> such as Voice over=20
> WLAN (VoWLAN) (11k and 11r), automative use (WAVE), etc. New=20
> attributes may=20
> be needed for these applications, or there may be a need to=20
> specify how=20
> existing attributes are used with these applications.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 16:38:43 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 17:38:15 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

hi david,=20
=20

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Nelson, David
> Gesendet: Dienstag, 21. Februar 2006 16:41
> An: [email-masked]
> Betreff: RE: RADEXT Agenda for IETF65, Take Two
>=20
> Hannes Tschofenig writes...
> =20
> > do you want to tell us a little bit more about this design team?
>=20
> This is an informal effort, at the suggestion of the WG Chairs, to
> assist the author in moving the document along at a more=20
> rapid pace, as
> it is very late (and was already late when Greg volunteered to work on
> the draft).  As this is still an individual submission draft,=20
> in pre-WG
> review, this is not a formal RADEXT WG Design Team.  The=20
> focus has been
> on maturing the draft to the point of being ready for=20
> consideration as a
> WG work item.
>=20
> > who is part of this design team?
>=20
> Greg Weber, Barney Wolff, Alan DeKok, Emile van Bergen, Dave Nelson
>=20

thanks for the info on this subject.=20
=20

> > i have a collision with the ecrit working group. i have to be at the
> > ecrit meeting.
>=20
> Is there someone else who could present this material, or should we
> attempt to resolve the schedule conflict between RADEXT ECRIT?

i guess we will find someone.=20

ciao
hannes

>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 16:38:35 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 17:38:15 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

hi david,=20

> Hannes Tschofenig writes...
>=20
> > i know about these activites. i wasn't quite sure how it effects the
> > http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt
> > document.
>=20
> There are two proposals that deal with key management and distribution
> via RADIUS, Bernard's draft and a draft from Glen Zorn.  These were
> discussed in more depth at IETF 63.

ok. that's a different story. i remember these two proposals. what i
disliked with them was that they do not provide a solution for dynamic
authentication and key management. why isn't something tackling this
issue? this would also solve the aspect of algorithm negotiation.
wouldn't be something like radius domain of interopretation for isakmp
be appropriate here.=20

> I'll let Bernard address your specific questions on his WLAN draft.
>=20
> > where do you see the main benefit of the document split=20
> with regard to
> > meeting the deadlines?
>=20
> First, there are some elements of each of the drafts selected=20
> for spilt
> that are well-baked, and close to ready for WGLC or=20
> submission to IESG.
> There are other elements which have open issues, that will=20
> require some
> time to work though.  Separating the issues allows the well-baked
> portions to progress immediately.=20
>=20
> > maybe because you want to see new document editors?
>=20
> If additional parallelism of effort and a spreading of workload can be
> achieved, so as to further accelerate the work progress, that=20
> would be a
> side benefit.  It is not clear that we will have additional=20
> editors for
> each of the "child" documents.
>=20
> All of this is a pretty straightforward application=20
> engineering project
> management techniques.  The fact of the matter is that the=20
> RADEXT WG is
> way late in some of its deliverables, and the chairs have prepared a
> "get well" plan, at the request of the ADs.  The document=20
> splits are one
> element of this plan.

i know project management techniques. i hope the best for you that your
document split plan works.=20
there is also a rule that says "adding manpower to a late project makes
it later."

in ecrit we scheduled an interim meeting that helped a lot to speedup
the work on the document. =20
you might also want to think about it.=20

ciao
hannes

>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 16:02:56 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 08:02:45 -0800

>maybe i haven't paid enough attention to this document. i actually do
>not quite understand its background. the abstract says:
>
>This document proposes additional attributes for use by
>IEEE 802.11 authenticators.  The attributes defined in this document
>are compatible with those used within Diameter EAP.
>http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt
>
>how does this relate to existing deployment? aren't we a little bit late
>specifying these attributes (although i think they are very useful).

802.11 is developing new standards to enable applications such as Voice over 
WLAN (VoWLAN) (11k and 11r), automative use (WAVE), etc. New attributes may 
be needed for these applications, or there may be a need to specify how 
existing attributes are used with these applications.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 15:56:00 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 10:55:35 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Hannes Tschofenig writes...

> i know about these activites. i wasn't quite sure how it effects the
> http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt
> document.

There are two proposals that deal with key management and distribution
via RADIUS, Bernard's draft and a draft from Glen Zorn.  These were
discussed in more depth at IETF 63.

I'll let Bernard address your specific questions on his WLAN draft.

> where do you see the main benefit of the document split with regard to
> meeting the deadlines?

First, there are some elements of each of the drafts selected for spilt
that are well-baked, and close to ready for WGLC or submission to IESG.
There are other elements which have open issues, that will require some
time to work though.  Separating the issues allows the well-baked
portions to progress immediately.=20

> maybe because you want to see new document editors?

If additional parallelism of effort and a spreading of workload can be
achieved, so as to further accelerate the work progress, that would be a
side benefit.  It is not clear that we will have additional editors for
each of the "child" documents.

All of this is a pretty straightforward application engineering project
management techniques.  The fact of the matter is that the RADEXT WG is
way late in some of its deliverables, and the chairs have prepared a
"get well" plan, at the request of the ADs.  The document splits are one
element of this plan.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 15:42:34 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 10:41:27 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Hannes Tschofenig writes...
=20
> do you want to tell us a little bit more about this design team?

This is an informal effort, at the suggestion of the WG Chairs, to
assist the author in moving the document along at a more rapid pace, as
it is very late (and was already late when Greg volunteered to work on
the draft).  As this is still an individual submission draft, in pre-WG
review, this is not a formal RADEXT WG Design Team.  The focus has been
on maturing the draft to the point of being ready for consideration as a
WG work item.

> who is part of this design team?

Greg Weber, Barney Wolff, Alan DeKok, Emile van Bergen, Dave Nelson

> i have a collision with the ecrit working group. i have to be at the
> ecrit meeting.

Is there someone else who could present this material, or should we
attempt to resolve the schedule conflict between RADEXT ECRIT?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 15:41:46 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 16:41:16 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

hi david,=20

thanks for the quick reply.=20

> Hannes Tschofenig writes...
> =20
> > what do you mean by crypto-agility?
>=20
> Generally speaking, it means the ability to treat cipher suites as
> modular components of protocols such that they can be changed without
> major upheaval to the protocol.  For example, the recent concerns over
> attacks against certain applications for hash functions used in IETF
> protocols, as discussed in SAAG.  More specifically, it means
> changes/extensions to RADIUS to allow a system using RADIUS to obtain
> FIPS-140 certification.

i know about these activites. i wasn't quite sure how it effects the=20
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt
document.=20

maybe i haven't paid enough attention to this document. i actually do
not quite understand its background. the abstract says:

This document proposes additional attributes for use by
IEEE 802.11 authenticators.  The attributes defined in this document
are compatible with those used within Diameter EAP.
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt

how does this relate to existing deployment? aren't we a little bit late
specifying these attributes (although i think they are very useful).

btw, he abstract does not seem to be inline with section 4. the abstract
says:

"
The attributes defined in this document
are compatible with those used within Diameter EAP.
"

section 4 says: =20
"
EAP-Key-Name attribute is aready defined as a RADIUS attributes within
Diameter EAP=20
New attributes not previously defined in Diameter EAP include EAP-
   Peer-ID, EAP-Server-ID, Allowed-SSID, Allowed-Called-Station-ID, and
   Mobility-Domain-ID.=20
"

>=20
> > > The desired goal would be to complete the split and have new
> > > -00 documents submitted by the -00 deadline of Monday, February
> > > 27.  This is a bit aggressive.
>=20
> > extremely agressive :-)
>=20
> Yes, perhaps.  We were waiting for formal approval from the=20
> ADs prior to
> announcing the documents splits.  OTOH, the initial split is,
> conceptually at least, a large cut and paste operation.

where do you see the main benefit of the document split with regard to
meeting the deadlines?=20
maybe because you want to see new document editors?=20

ciao
hannes

>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 15:26:48 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 16:26:32 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

hi david,=20

> Greg has been working with an informal design team to revise=20
> the draft.
> The plan has been to have the next version ready (well) prior to IETF
> 65, in any event.

do you want to tell us a little bit more about this design team?=20
who is part of this design team?=20
>=20
> > > D.4.1  GEOPRIV-RADIUS:  20 minutes to discuss the status of the
> solution
> > > being crafted by Emile & Hannes.
> >=20
> > I won't be there in person due to lack of funds, so Hannes will have
> to
> > take this up I think.
>=20
> We'll check with Hannes on this.
i have a collision with the ecrit working group. i have to be at the
ecrit meeting.=20

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 15:14:51 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 10:14:34 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Hannes Tschofenig writes...
=20
> what do you mean by crypto-agility?

Generally speaking, it means the ability to treat cipher suites as
modular components of protocols such that they can be changed without
major upheaval to the protocol.  For example, the recent concerns over
attacks against certain applications for hash functions used in IETF
protocols, as discussed in SAAG.  More specifically, it means
changes/extensions to RADIUS to allow a system using RADIUS to obtain
FIPS-140 certification.

> > The desired goal would be to complete the split and have new
> > -00 documents submitted by the -00 deadline of Monday, February
> > 27.  This is a bit aggressive.

> extremely agressive :-)

Yes, perhaps.  We were waiting for formal approval from the ADs prior to
announcing the documents splits.  OTOH, the initial split is,
conceptually at least, a large cut and paste operation.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 15:10:54 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 07:10:44 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>

We are still planning on publishing draft-ietf-radext-ieee802-02.txt
prior to IETF 65.  It is expected to have addressed all current open
items.  There was no prior plan to split the document. =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes
> Sent: Tuesday, February 21, 2006 6:39 AM
> To: Bernard Aboba; [email-masked]
> Subject: AW: RADEXT Milestone revisions
>=20
> hi bernard,=20
>=20
> thanks for suggesting something.=20
>=20
> > As discussed at IETF 64, the O&M Area Directors have become=20
> > increasingly concerned about the rate of progress within the RADEXT=20
> > WG.
> > Several work
> > items are more than a year behind, and so there is a desire to=20
> > substantially increase the rate of progress, by completing=20
> late work=20
> > items as soon as possible.
> >=20
> > To this end, the ADs have recently approved a modification to the=20
> > RADEXT WG milestones which separates several documents into=20
> multiple,=20
> > distinct work
> > items:
> >=20
> > a. The work now represented by the IEEE 802 document will be split=20
> > into three separate documents, one focused on VLAN/Priority, one on=20
> > basic filtering, and another document on redirection.
> >=20
> > The pre-approved WG work item draft file names are:
> >=20
> > draft-ietf-radext-vlan-priority-00.txt
> > draft-ietf-radext-filter-rules-00.txt
> > draft-ietf-radext-redirection-00.txt
>=20
> how does the content of the current=20
> draft-ietf-radext-ieee802-01.txt document relate to these=20
> three documents?
>=20
> i would like to know whether some of these documents above=20
> address the qos aspects (maybe the priority one)?=20
>=20
> >=20
> > b. The Design Guidelines document will be split into two=20
> work items,=20
> > one a Standard track work item relating to extending the RADIUS=20
> > attribute space, and another one a BCP on Design Guidelines.
> >=20
> > The suggested individual submission (pre-WG) draft file names are:
> >=20
> > draft-weber-radius-design-guidelines-nn.txt
> > draft-<editor-radext-extended-attributes-00.txt
> >=20
> > c. The work on WLAN attributes will be split into two work=20
> items, one=20
> > relating purely to WLAN attributes, and another one focused on=20
> > crypto-agility.
>=20
> i guess that this is your document
> http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt
>=20
> what do you mean by crypto-agility?
>=20
>=20
> >=20
> > d. The Issues & Fixes document will be split into two work=20
> items, one=20
> > relating to Issues & Fixes, and other one focussing on=20
> clarifications=20
> > (but not extensions) to RFC 3576.
> >=20
> > The goal of this separation effort is to be able to complete the=20
> > following work items quickly:
> >=20
> > 1. The VLAN/Priority document will be revised and brought=20
> to WG last=20
> > call immediately with a goal of getting it to the IESG in March.
> >=20
> > 2. The Issues & Fixes document will be presented at IETF 65=20
> with the=20
> > goal of making it a WG work item and bringing it an initial WG last=20
> > call quickly.
> >=20
> > 3. The WLAN attributes document will be presented at IETF=20
> 65 with the=20
> > goal of making it a WG work item and bringing it to an=20
> initial WG last=20
> > call quickly.
> >=20
> > As part of this document re-organization, we have the=20
> opportunity to=20
> > further spread the workload by assigning distinct document=20
> editors to=20
> > each of the newly created "child documents".  The chairs will be=20
> > contacting the existing "parent document" editors, as well as=20
> > potential new "child document" editors to assess interest and=20
> > availability. If you are interested in volunteering to edit=20
> a "child=20
> > document", let us know.
> >=20
> > The desired goal would be to complete the split and have new -00=20
> > documents submitted by the -00 deadline of Monday, February=20
> 27.  This=20
> > is a bit aggressive.
> extremely agressive :-)
>=20
> ciao
> hannes
>=20
> > Regards,
> >=20
> > Bernard Aboba
> > Dave Nelson
> > RADEXT WG Chairs
> >=20
> >=20
> >=20
> > --
> > to unsubscribe send a message to=20
> [email-masked] with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 15:00:17 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Agenda for IETF65, Take Two
Date: Tue, 21 Feb 2006 09:58:46 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> > D.3.2  Design Guidelines:  30 minutes to discuss the open issues,
> > including any "capabilities" discussion. It this document ready for
> > formal acceptance as a WG work item?
>=20
> Are you referring to the document as the split proposed by the chairs,
> or the unsplit document?

The *desire* is to have the split documents ready prior to IETF 65.  The
schedule for doing so is admittedly a bit tight, but I remain
optimistic.

> I think the split is a very good idea; I would
> not consider the draft ready as as WG work item it is currently.
> However, it seems that Greg hasn't been able to update it in a while.

Greg has been working with an informal design team to revise the draft.
The plan has been to have the next version ready (well) prior to IETF
65, in any event.

> > D.4.1  GEOPRIV-RADIUS:  20 minutes to discuss the status of the
solution
> > being crafted by Emile & Hannes.
>=20
> I won't be there in person due to lack of funds, so Hannes will have
to
> take this up I think.

We'll check with Hannes on this.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 14:39:59 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Milestone revisions
Date: Tue, 21 Feb 2006 15:39:14 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

hi bernard,=20

thanks for suggesting something.=20

> As discussed at IETF 64, the O&M Area Directors have become=20
> increasingly=20
> concerned about the rate of progress within the RADEXT WG. =20
> Several work=20
> items are more than a year behind, and so there is a desire=20
> to substantially=20
> increase the rate of progress, by completing late work
> items as soon as possible.
>=20
> To this end, the ADs have recently approved a modification to=20
> the RADEXT WG=20
> milestones which separates several documents into multiple,=20
> distinct work=20
> items:
>=20
> a. The work now represented by the IEEE 802 document will be=20
> split into=20
> three separate documents, one focused on VLAN/Priority, one on basic=20
> filtering, and another document on redirection.
>=20
> The pre-approved WG work item draft file names are:
>=20
> draft-ietf-radext-vlan-priority-00.txt
> draft-ietf-radext-filter-rules-00.txt
> draft-ietf-radext-redirection-00.txt

how does the content of the current draft-ietf-radext-ieee802-01.txt
document relate to these three documents?

i would like to know whether some of these documents above address the
qos aspects (maybe the priority one)?=20

>=20
> b. The Design Guidelines document will be split into two work=20
> items, one a=20
> Standard track work item relating to extending the RADIUS=20
> attribute space,=20
> and another one a BCP on Design Guidelines.
>=20
> The suggested individual submission (pre-WG) draft file names are:
>=20
> draft-weber-radius-design-guidelines-nn.txt
> draft-<editor-radext-extended-attributes-00.txt
>=20
> c. The work on WLAN attributes will be split into two work items, one=20
> relating purely to WLAN attributes, and another one focused on=20
> crypto-agility.

i guess that this is your document
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt

what do you mean by crypto-agility?

>=20
> d. The Issues & Fixes document will be split into two work items, one=20
> relating to Issues & Fixes, and other one focussing on=20
> clarifications (but=20
> not extensions) to RFC 3576.
>=20
> The goal of this separation effort is to be able to complete=20
> the following=20
> work items quickly:
>=20
> 1. The VLAN/Priority document will be revised and brought to=20
> WG last call=20
> immediately with a goal of getting it to the IESG in March.
>=20
> 2. The Issues & Fixes document will be presented at IETF 65=20
> with the goal of=20
> making it a WG work item and bringing it an initial WG last=20
> call quickly.
>=20
> 3. The WLAN attributes document will be presented at IETF 65=20
> with the goal=20
> of making it a WG work item and bringing it to an initial WG=20
> last call=20
> quickly.
>=20
> As part of this document re-organization, we have the=20
> opportunity to further=20
> spread the workload by assigning distinct document editors to=20
> each of the=20
> newly created "child documents".  The chairs will be=20
> contacting the existing=20
> "parent document" editors, as well as potential new "child=20
> document" editors=20
> to assess interest and availability. If you are interested in=20
> volunteering=20
> to edit a "child document", let us know.
>=20
> The desired goal would be to complete the split and have new=20
> -00 documents=20
> submitted by the -00 deadline of Monday, February 27.  This is a bit=20
> aggressive.
extremely agressive :-)

ciao
hannes

> Regards,
>=20
> Bernard Aboba
> Dave Nelson
> RADEXT WG Chairs
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 09:14:41 +0000
Date: Tue, 21 Feb 2006 10:14:18 +0100
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: RADEXT Agenda for IETF65, Take Two
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

Hi,

On Mon, Feb 20, 2006 at 12:13:01PM -0500, Nelson, David wrote:

> D.3.2  Design Guidelines:  30 minutes to discuss the open issues,
> including any "capabilities" discussion. It this document ready for
> formal acceptance as a WG work item?

Are you referring to the document as the split proposed by the chairs,
or the unsplit document? I think the split is a very good idea; I would
not consider the draft ready as as WG work item it is currently.
However, it seems that Greg hasn't been able to update it in a while.

> D.3.3  Issues & Fixes:  10 minutes discussion.  It this document ready
> for formal acceptance as a WG work item?
> 
> D.3.4  Prepaid Extensions:  10 minutes for discussion of revised (-10)
> draft.
> 
> D.4  Documents requiring cross-WG review (25 minutes):
> 
> D.4.1  GEOPRIV-RADIUS:  20 minutes to discuss the status of the solution
> being crafted by Emile & Hannes.

I won't be there in person due to lack of funds, so Hannes will have to
take this up I think.

> D.4.2  RADIUS Prefix Delegation: 5 Minutes to discuss the review was
> posted to the mailing list.
> 
> E. Wrap-Up (5 minutes)

Kind regards,

Emile van Bergen.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 09:09:26 +0000
Date: Tue, 21 Feb 2006 10:08:38 +0100
From: Emile van Bergen <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: RADIUS-Geopriv: Request for review
Mail-Followup-To: "Tschofenig, Hannes" <[email-masked]>, [email-masked], [email-masked]

Hi,

On Sun, Feb 12, 2006 at 10:10:45PM +0100, Tschofenig, Hannes wrote:

> I have submitted an update for the RADIUS-Geopriv draft. Before it
> appears on the draft announcement list please find it at:
>
> http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.txt
> http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.html
> 
> I have incorporated the resolutions from the last IETF meeting
> (including follow-up discussions), review comments by Yoshi Ohba and a
> recent review by David Nelson.

I just reviewed the new draft briefly, and I'm glad to see that my
suggested approach towards challenges and capabilities was indeed useful
(although that's clearer from the new design than from the credits ;-))

I have two small suggestions for now, to make things a bit more
evolution-proof:

* Set the value of the Challenge-Capable attribute to 1, reserve all other
  values and and require the value to be non-zero in order for it to be
  interpreted as described. This allows the NAS to be more specific
  later, without loss of compatibility or a change in semantics that
  would require a new attribute.

* In Access-Challenges, I wonder whether Required-Information should be
  optional. The issues I see are as follows:

  - Challenge-Capable has potentially a wider applicability than just
    GEOPRIV. But in order to allow such later applications, and also to
    allow NASes to support challenges for purposeful withheld
    information as in GEOPRIV as well as the old PAP/CHAP-based OTP
    scheme, a mechanism is required to tell the NAS what it should do
    with a challenge following a request containing Challenge-Capable.

  - So, you can either have the NAS scan the challenge for anything that it
    can interpret as the reason for the challenge, and if it does not
    find anything, it should reissue the request as-is, including State,
    of course.

    This allows challenge reasons and required information sets to
    evolve without having to devise a new basic mechanism.

  - You can also require the server to be explicit in any challenge
    to a Challenge-Capable NAS, and create a Challenge-Cause attribute
    on the same architectural level as Challenge-Capable.

    Now, we can either promote Required-Information to that status, by
    *requiring* it in any challenge, and allow the IANA to assign other
    values, or reserve Required-Information for GEOPRIV alone, rename it
    Required-Location-Information and create a separate Challenge-Cause
    attribute.

  - But I think that one of the above two options is required for proper
    closure.

Kind regards,

Emile van Bergen.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked] 
> > [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> > Gesendet: Donnerstag, 26. Januar 2006 05:52
> > An: [email-masked]
> > Betreff: Request for review
> > 
> > A new version of the RADIUS location draft has been posted to 
> > the Internet 
> > Drafts archive:
> > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-
> > lo-05.txt
> > 
> > Please review this document and post comments to the GEOPRIV 
> > (and RADEXT) WG 
> > mailing lists.
> > 
> > In particular, please review conformance to the framework 
> > posted by Emile in 
> > this message to the list:
> > http://ops.ietf.org/lists/radiusext/2006/msg00028.html
> > 
> > FYI, the GEOPRIV WG issue tracker for this document is located at:
> > http://www.tschofenig.com:8080/radius-geopriv/

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Feb 2006 07:11:04 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT Milestone revisions
Date: Mon, 20 Feb 2006 23:10:16 -0800

As discussed at IETF 64, the O&M Area Directors have become increasingly 
concerned about the rate of progress within the RADEXT WG.  Several work 
items are more than a year behind, and so there is a desire to substantially 
increase the rate of progress, by completing late work
items as soon as possible.

To this end, the ADs have recently approved a modification to the RADEXT WG 
milestones which separates several documents into multiple, distinct work 
items:

a. The work now represented by the IEEE 802 document will be split into 
three separate documents, one focused on VLAN/Priority, one on basic 
filtering, and another document on redirection.

The pre-approved WG work item draft file names are:

draft-ietf-radext-vlan-priority-00.txt
draft-ietf-radext-filter-rules-00.txt
draft-ietf-radext-redirection-00.txt

b. The Design Guidelines document will be split into two work items, one a 
Standard track work item relating to extending the RADIUS attribute space, 
and another one a BCP on Design Guidelines.

The suggested individual submission (pre-WG) draft file names are:

draft-weber-radius-design-guidelines-nn.txt
draft-<editor-radext-extended-attributes-00.txt

c. The work on WLAN attributes will be split into two work items, one 
relating purely to WLAN attributes, and another one focused on 
crypto-agility.

d. The Issues & Fixes document will be split into two work items, one 
relating to Issues & Fixes, and other one focussing on clarifications (but 
not extensions) to RFC 3576.

The goal of this separation effort is to be able to complete the following 
work items quickly:

1. The VLAN/Priority document will be revised and brought to WG last call 
immediately with a goal of getting it to the IESG in March.

2. The Issues & Fixes document will be presented at IETF 65 with the goal of 
making it a WG work item and bringing it an initial WG last call quickly.

3. The WLAN attributes document will be presented at IETF 65 with the goal 
of making it a WG work item and bringing it to an initial WG last call 
quickly.

As part of this document re-organization, we have the opportunity to further 
spread the workload by assigning distinct document editors to each of the 
newly created "child documents".  The chairs will be contacting the existing 
"parent document" editors, as well as potential new "child document" editors 
to assess interest and availability. If you are interested in volunteering 
to edit a "child document", let us know.

The desired goal would be to complete the split and have new -00 documents 
submitted by the -00 deadline of Monday, February 27.  This is a bit 
aggressive.

Regards,

Bernard Aboba
Dave Nelson
RADEXT WG Chairs

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Feb 2006 17:14:22 +0000
Content-class: urn:content-classes:message
Subject: RADEXT Agenda for IETF65, Take Two
Date: Mon, 20 Feb 2006 12:13:01 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Agenda for the RADEXT WG Meeting at IETF 65
TUESDAY, March 21, 2006
0900-1130 Morning Session I

A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes)

B. Agenda Bashing

C. Milestone Revisions (5 minutes)

D. Document Status

D.1 Documents in IESG review (20 minutes):

D.1.1  RADIUS Digest Authentication: 10 minutes for discussion of IESG
review.
=20
D.1.2  RFC 3576 MIBs: 5 minutes for discussion of IESG review.
=20
D.1.2  RFC 2618bis-2621bis: 5 minutes for discussion of IESG review.
=20
D.2  Documents in WGLC issue resolution (30 minutes):

D.2.1  VLAN/Priority: 30 minutes for discussion of WGLC issues.
=20
D.3  Documents in Pre-WG review (60 minutes):

D.3.1  WLAN Attributes: 10 minutes for discussion of current status.
=20
D.3.2  Design Guidelines:  30 minutes to discuss the open issues,
including any "capabilities" discussion. It this document ready for
formal acceptance
as a WG work item?
=20
D.3.3  Issues & Fixes:  10 minutes discussion.  It this document ready
for
formal acceptance as a WG work item?

D.3.4  Prepaid Extensions:  10 minutes for discussion of revised (-10)
draft.

D.4  Documents requiring cross-WG review (25 minutes):

D.4.1  GEOPRIV-RADIUS:  20 minutes to discuss the status of the solution
being crafted by Emile & Hannes.
=20
D.4.2  RADIUS Prefix Delegation: 5 Minutes to discuss the review was
posted to the mailing list.

E. Wrap-Up (5 minutes)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Feb 2006 16:52:25 +0000
Content-class: urn:content-classes:message
Subject: RADEXT meeting slot at IETF 65
Date: Mon, 20 Feb 2006 11:50:36 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

As of February 18, 2006, the DRAFT Agenda for IETF 65 has slotted the
RADEXT WG on Tuesday AM.  This is, of course, subject to change.

TUESDAY, March 21, 2006
0800-1800 IETF Registration -
0800-0900 Continental Breakfast -
0900-1130 Morning Session I
APP	eai	      Email Address Internationalization BOF
INT	netlmm	Network-based Localized Mobility Management WG
INT	trill	      Transparent Interconnection of Lots of Links WG
OPS	adslmib	ADSL MIB WG
OPS	radext	RADIUS Extensions WG
RAI	avt	      Audio/Video Transport WG
RAI	ecrit	      Emergency Context Resolution with Internet
Technologies WG
RTG	forces	Forwarding and Control Element Separation WG

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Feb 2006 22:14:32 +0000
Content-class: urn:content-classes:message
Subject: New Editorial Issue (on draft-ietf-geopriv-radius-lo-05.txt)
Date: Wed, 15 Feb 2006 17:13:01 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Description of issue
Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: February 15, 2006
Reference:
Document: RADIUS-GEOPRIV-05
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: 3.2
Rationale/Explanation of issue:

   Improper use of terminology.

Requested change:

   Upon receiving the Authorize-Only message from the access network,
   the RADIUS server MUST respond with either an Access-Accept or an
   Access-Reject message.

s/Authorize-Only message from the access network/Access-Request message
containing the Service-Type hint attribute with a value of
Authorize-Only
from the NAS/

Section: 5
Rationale/Explanation of issue:

   Improper use of terminology.

Requested change:

   Furthermore, the Basic-Policy-Rules and the Extended-
   Policy-Rules attributes are attached to the Location-Information
   attribute turning location information into a Location Object as
   defined in [12].

The term "attached" apparently has a well understood meaning in terms of
GEOPRIV data objects, but its use in connection with RADIUS attributes
is potentially confusing, and my lead the implementer to believe that
RADIUS application-layer reassembly (i.e. concatenation of two
attributes) is being performed.  If this is the intended outcome
(concatenation within the RADIUS client) then this wording may be OK.
Otherwise, if the RADIUS client is supposed to deliver the individual
attributes to GEOPRIV subsequent processing, rewording to that effect
may be required.

Section:  15.2
Rationale/Explanation of issue:

Cut and paste error.  Redundant words.

Requested change:

   Following the policies outline in [10] new Operator-Namespaces will
   be assigned after Expert Review by the RADEXT working group or its
   designated successor.  Updates can be provided based on expert
   approval only.  A designated expert will be appointed by the O&M Area
   Directors.  No mechanism to mark entries entries as "deprecated is
   envisioned.  Based on expert approval it is possible to delete
   entries from the registry.

s/Operator-Namespace/Requested-Info/

s/entries entries/entries/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Feb 2006 22:14:24 +0000
Content-class: urn:content-classes:message
Subject: New Technical Issue (on draft-ietf-geopriv-radius-lo-05.txt)
Date: Wed, 15 Feb 2006 17:13:26 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Description of issue
Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: February 15, 2006
Reference:
Document: RADIUS-GEOPRIV-05
Comment type: 'T'echnical
Priority: '0' Must fix
Section: 5.2
Rationale/Explanation of issue:

Overly complex attribute format.

Requested change:

   This document describes two formats for conveying location
   information: civic and geospatial location information.
   Section 5.2.1 defines the civic location information format.
   Section 5.2.2 defines the geospatial location information format.

Since there are two distinct attribute flied layouts, it would seem that
this attribute should be represented as two distinct attributes, each
with a fixed format.  Variable format attributes are not encompassed
within the standard RADIUS data model.

Section: 9.2, 9.3
Rationale/Explanation of issue:

The attributes described in these sections are quite complex.  It is
highly likely (based on the current draft work) that the RADIUS D3sign
Guidelines BCP will very strongly discourage attributes of this
complexity to be designed using the traditional RFC 2865 attribute
format, but rather use the proposed Extended RADIUS Attribute format (or
similar name) that will be proposed.  This will mean that the
GEORPIV-RADIUS RFC is out of compliance with the RADIUS Design
Guidelines RFC.

Requested change:

The nature of requested change is somewhat dependent upon the relative
schedules of the GEOPRIV-RADIUS draft and the RADIUS Design Guidelines
draft.  The most technically desirable solution would be to use the
Extended RADIUS Attribute format, assuming that draft is sufficiently
well-baked in a timely fashion to allow these attributes to be
re-formatted, prior to WGLC of the GEOPRIV-RADIUS draft.   I understand
that this is a technical issue of major scope.

Section: 9.6
Rationale/Explanation of issue:

Unusual data type.

Requested change:

          Requested-Info (48 bits):
          This text field contains a numerical value that encodes the
          requested information attributes.
          Each value represents a bit position.

Why 48 bits?  This does not correspond with any existing base RADIUS
data types.  Is this a bit-vector?  Does it need to be a bit vector, or
could it be an enumerated type, with multiple instances of the attribute
allow in the appropriate messages?

Section:  Various.
Rationale/Explanation of issue:

Not all data fields within attribute formats have been designated with
an existing base RADIUS data type.

Requested change:

Verify that all fields have a base data type designation.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Feb 2006 13:41:25 +0000
Content-class: urn:content-classes:message
Subject: Diameter Interop URL
Date: Wed, 15 Feb 2006 15:39:36 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C63235.42F8BEAB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

The previous link I gave out for the Diameter Interop event seemed to
disappear.  The correct URL is:

http://www.ulticom.com/html/diameter-interop/index.asp

John

------_=_NextPart_001_01C63235.42F8BEAB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft>Hi all,<BR><BR>The previous link I gave =
out&nbsp;<SPAN=20
class=3D900593813-15022006>for the Diameter Interop event </SPAN>seemed =
to=20
disappear.&nbsp; The correct URL is:<BR><BR><A =
class=3Dmoz-txt-link-freetext=20
title=3Dhttp://www.ulticom.com/html/diameter-interop/index.asp=20
href=3D"http://www.ulticom.com/html/diameter-interop/index.asp">http://ww=
w.ulticom.com/html/diameter-interop/index.asp</A><BR><BR>John<BR></DIV></=
BODY></HTML>

------_=_NextPart_001_01C63235.42F8BEAB--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Feb 2006 00:04:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution of Fixes Issue 141: State Attribute
Date: Tue, 14 Feb 2006 16:04:21 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> The text of Issue 141 is enclosed below.  The proposed resolution is
> as=20
> follows:
>=20
> Insert the following text at the end of Section  2.8:
>=20
> "Since a State attribute is always initially provided by the server
> in an Access-Accept, Access-Challenge, CoA-Request or
> Disconnect-Request, a RADIUS client MUST NOT insert a State attribute
> that it has not previously received from the server."=20

OK w/me.
 =20
>=20
> =
-------------------------------------------------------------------------=
--------------------------------------
> Issue 141: State Attribute
> Submitter name: David Mitton
> Submitter email address: [email-masked] Date first submitted:
> November 11, 2005=20
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg01024.html
> Document: Fixes-01
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>=20
> wrt State attribute; there was a case in the past where a vendor
> decided that their client would sent a State attribute with Null data
> to start a certain proprietary sequence. Non-Vendor's clients would
> fail on this server due to this expectation.  =20
>=20
> You should make it clear that a new Access-Request should not contain
> a State attribute. State should always come from a server, and prior
> context. =20
> Not manufactured by the client.

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Feb 2006 16:39:44 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution of Fixes Issue 141: State Attribute
Date: Tue, 14 Feb 2006 08:38:36 -0800

The text of Issue 141 is enclosed below.  The proposed resolution is as 
follows:

Insert the following text at the end of Section  2.8:

"Since a State attribute is always initially provided by the server in
an Access-Accept, Access-Challenge, CoA-Request or Disconnect-Request, a
RADIUS client MUST NOT insert a State attribute that it has not previously
received from the server."

---------------------------------------------------------------------------------------------------------------
Issue 141: State Attribute
Submitter name: David Mitton
Submitter email address: [email-masked]
Date first submitted: November 11, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg01024.html
Document: Fixes-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

wrt State attribute; there was a case in the past where a vendor decided 
that their client would sent a State attribute with Null data to start a 
certain proprietary sequence. Non-Vendor's clients would fail on this server 
due to this expectation.

You should make it clear that a new Access-Request should not contain a 
State attribute. State should always come from a server, and prior context. 
Not manufactured by the client.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Feb 2006 10:25:08 +0000
Content-class: urn:content-classes:message
Subject: RE: radius dynauth client/server mibs structure
Date: Tue, 14 Feb 2006 15:53:54 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Bert Wijnen" <[email-masked]>

Juergen,

Your comments may be correct. We authors have discussed about your
comments and realized that the comments are not directly related to
these MIBs but in general whether the scalars should be grouped together
or not. The recommended way can best be addressed in the IETF MIB
guidelines. Since there seem to be plenty of MIBs that don't follow your
commented approach, no recommended way in the IETF MIB guidelines and
because it is a stylistic change, we leave the MIBs as they are.

Thanks
Nagi.

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Juergen Schoenwaelder
Sent: Thursday, February 09, 2006 12:03 AM
To: [email-masked]
Cc: Bert Wijnen
Subject: radius dynauth client/server mibs structure

Hi,

I took a quick look at the radius dynauth client/server mibs today:

   draft-ietf-radext-dynauth-client-mib-03.txt
   draft-ietf-radext-dynauth-server-mib-03.txt

While looking at the OID tree, I came up with the following stylistic
change. Currently, the OID tree of the two MIBs basically looks like
this (details of the tables and conformance nodes deleted):

--radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
  |
  +--radiusDynAuthServerMIBObjects(1)
  |  |
  |  +--radiusDynAuthServer(1)
  |     |
  |     +--radiusDynAuthServerDisconInvalidClientAddresses(1)
  |     +--radiusDynAuthServerCoAInvalidClientAddresses(2)
  |     +--radiusDynAuthServerIdentifier(3)
  |     |
  |     +--radiusDynAuthClientTable(4)
  |
  +--radiusDynAuthServerMIBConformance(2)

--radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
  |
  +--radiusDynAuthClientMIBObjects(1)
  |  |
  |  +--radiusDynAuthClient(1)
  |     |
  |     +--radiusDynAuthClientDisconInvalidServerAddresses(1)
  |     +--radiusDynAuthClientCoAInvalidServerAddresses(2)
  |     |
  |     +--radiusDynAuthServerTable(3)
  |
  +--radiusDynAuthClientMIBConformance(2)

I was wondering what the value of having the radiusDynAuthServer and
radiusDynAuthClient nodes is. I do understand if people like to group
related scalars together (so additions are numbered using consecutive
identifiers), but then the OID structure should more look like the
following:

--radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
  |
  +--radiusDynAuthServerMIBObjects(1)
  |  |
  |  +--radiusDynAuthServerScalars(1)
  |  |  |
  |  |  +--radiusDynAuthServerDisconInvalidClientAddresses(1)
  |  |  +--radiusDynAuthServerCoAInvalidClientAddresses(2)
  |  |  +--radiusDynAuthServerIdentifier(3)
  |  |
  |  +--radiusDynAuthClientTable(2)
  |
  +--radiusDynAuthServerMIBConformance(2)

--radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
  |
  +--radiusDynAuthClientMIBObjects(1)
  |  |
  |  +--radiusDynAuthClientScalars(1)
  |  |  |
  |  |  +--radiusDynAuthClientDisconInvalidServerAddresses(1)
  |  |  +--radiusDynAuthClientCoAInvalidServerAddresses(2)
  |  |
  |  +--radiusDynAuthServerTable(2)
  |
  +--radiusDynAuthClientMIBConformance(2)

The benefit of this change is that you can add scalars later while keep
all the scalars rooted together and consecutively numbered while in the
current scheme you end up to have tables intermixed with scalars over
time.

Please note that there is nothing technically wrong with the MIBs as
they are right now. My suggestion is purely stylistic and basically just
increases readability in case updates are done in the future.

I am aware that these MIB modules have passed WG last call and MIB
review and are in the hands of the ADs and as such I do not ask to make
a change just for stylistic reasons. I just wanted to bring this to your
attention and I like to leave it to the editors/chairs to decide whether
you want to make the relatively simple changes at this point in time or
prefer to go ahead with what you have.

/js

--=20
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
Germany

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 12 Feb 2006 21:11:54 +0000
Content-class: urn:content-classes:message
Subject: RADIUS-Geopriv: Request for review
Date: Sun, 12 Feb 2006 22:10:45 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi all,=20

I have submitted an update for the RADIUS-Geopriv draft. Before it =
appears on the draft announcement list please find it at:
http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.txt
http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.html

I have incorporated the resolutions from the last IETF meeting =
(including follow-up discussions), review comments by Yoshi Ohba and a =
recent review by David Nelson.

Ciao
Hannes

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> Gesendet: Donnerstag, 26. Januar 2006 05:52
> An: [email-masked]
> Betreff: Request for review
>=20
> A new version of the RADIUS location draft has been posted to=20
> the Internet=20
> Drafts archive:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-
> lo-05.txt
>=20
> Please review this document and post comments to the GEOPRIV=20
> (and RADEXT) WG=20
> mailing lists.
>=20
> In particular, please review conformance to the framework=20
> posted by Emile in=20
> this message to the list:
> http://ops.ietf.org/lists/radiusext/2006/msg00028.html
>=20
> FYI, the GEOPRIV WG issue tracker for this document is located at:
> http://www.tschofenig.com:8080/radius-geopriv/
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 12 Feb 2006 21:11:46 +0000
Content-class: urn:content-classes:message
Subject: AW: RADEXT Agenda for IETF65
Date: Sun, 12 Feb 2006 22:10:48 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

hi david,=20
hi all,=20

i would like to discuss the following document:

--------------

Prepaid extensions to RADIUS
draft-lior-radius-prepaid-extensions-09.txt

--------------

a draft update will be available soon based on the feedback we received.
this document is not a new item and is also on the charter.=20

ciao
hannes
=20

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Nelson, David
> Gesendet: Freitag, 10. Februar 2006 15:58
> An: [email-masked]
> Betreff: RADEXT Agenda for IETF65
>=20
> Colleagues,
>=20
> The chairs have requested one 2.5 hour meeting slot for RADEXT at
> IETF65.  We'll let you know the assigned slot, once it's been=20
> scheduled.
>=20
> I would normally be sending a message, at about this time, to the WG
> soliciting agenda items, submissions and presentations.  The theme for
> RADEXT at IETF65 will be "Getting to Done", and by that I=20
> mean focusing
> our time and energies on completing the outstanding (and late)
> milestones.  For that reason, the chairs have proposed a rough agenda,
> focused around work items that are nearing completion.  We will be
> soliciting submissions and presentations, and allocating discussion
> slots, as indicated, with the idea of moving our committed work along.
>=20
> Once we have "cleared the decks" of many of these outstanding=20
> items, the
> WG will be in a position to consider some of the important submissions
> and topics that are not currently milestones, and could entertain a
> re-charter discussion to consider these items.  For IETF65,=20
> we will not
> be entertaining discussion of new work items.  Please help us=20
> make some
> needed progress.
>=20
> First draft agenda:
>=20
> RADIUS Digest Authentication: 10 minutes for discussion of=20
> IESG review.
>=20
> RFC 3576 MIBs: 10 minutes for discussion of IESG review.=20
>=20
> RFC 2618bis-2621bis: 10 minutes for discussion of IESG review.
>=20
> VLAN/Priority: 30 minutes for discussion of WGLC issues.
>=20
> WLAN Attributes: 10 minutes for discussion of current status.
>=20
> GEOPRIV-RADIUS:  20 minutes to discuss the status of the solution=20
> being crafted by Emile & Hannes.=20
>=20
> Design Guidelines:  30 minutes to discuss the open issues,=20
> including any
> "capabilities" discussion. It this document ready for formal=20
> acceptance
> as a WG work item?
>=20
> Issues & Fixes:  10 minutes discussion.  It this document ready for
> formal acceptance as a WG work item?
>=20
> RADIUS Prefix Delegation: 5 Minutes to discuss the review was=20
> posted to
> the mailing list.=20
>=20
> Comments on this first draft proposed agenda are solicited, and
> encouraged, keeping within the theme of "Getting to Done".
>=20
> Thanks!
>=20
> Dave Nelson
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Feb 2006 15:25:34 +0000
Content-class: urn:content-classes:message
Subject: FW: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA 
Date: Fri, 10 Feb 2006 10:21:12 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

As a reminder...

There are two (2) Internet-Draft cutoff dates for the 65th=20
IETF Meeting in Dallas, TX, USA:

February 27th: Cutoff Date for Initial (i.e., version -00)=20
Internet-Draft Submissions=20

All initial Internet-Drafts (version -00) must be submitted by Monday,=20
February 27th at 9:00 AM ET. As always, all initial submissions with a=20
filename beginning with "draft-ietf" must be approved by the=20
appropriate WG Chair before they can be processed or announced.  The=20
Secretariat would appreciate receiving WG Chair approval by Monday,=20
February 20th at 9:00 AM ET.

March 6th: Cutoff Date for Revised (i.e., version -01 and higher)=20
Internet-Draft Submissions=20

All revised Internet-Drafts (version -01 and higher) must be submitted=20
by Monday, March 6th at 9:00 AM ET.

Initial and revised Internet-Drafts received after their respective=20
cutoff dates will not be made available in the Internet-Drafts=20
directory or announced until on or after Monday, March 20th at 9:00=20
AM ET, when Internet-Draft posting resumes.  Please do not wait until=20
the last minute to submit.

Thank you for your understanding and cooperation. If you have any=20
questions or concerns, then please send a message to=20
[email-masked].

The IETF Secretariat

FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 65th IETF Meeting can be found at
http://www.ietf.org/meetings/cutoff_dates_65.html.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Feb 2006 14:58:20 +0000
Content-class: urn:content-classes:message
Subject: RADEXT Agenda for IETF65
Date: Fri, 10 Feb 2006 09:57:48 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Colleagues,

The chairs have requested one 2.5 hour meeting slot for RADEXT at
IETF65.  We'll let you know the assigned slot, once it's been scheduled.

I would normally be sending a message, at about this time, to the WG
soliciting agenda items, submissions and presentations.  The theme for
RADEXT at IETF65 will be "Getting to Done", and by that I mean focusing
our time and energies on completing the outstanding (and late)
milestones.  For that reason, the chairs have proposed a rough agenda,
focused around work items that are nearing completion.  We will be
soliciting submissions and presentations, and allocating discussion
slots, as indicated, with the idea of moving our committed work along.

Once we have "cleared the decks" of many of these outstanding items, the
WG will be in a position to consider some of the important submissions
and topics that are not currently milestones, and could entertain a
re-charter discussion to consider these items.  For IETF65, we will not
be entertaining discussion of new work items.  Please help us make some
needed progress.

First draft agenda:

RADIUS Digest Authentication: 10 minutes for discussion of IESG review.

RFC 3576 MIBs: 10 minutes for discussion of IESG review.=20

RFC 2618bis-2621bis: 10 minutes for discussion of IESG review.

VLAN/Priority: 30 minutes for discussion of WGLC issues.

WLAN Attributes: 10 minutes for discussion of current status.

GEOPRIV-RADIUS:  20 minutes to discuss the status of the solution=20
being crafted by Emile & Hannes.=20

Design Guidelines:  30 minutes to discuss the open issues, including any
"capabilities" discussion. It this document ready for formal acceptance
as a WG work item?

Issues & Fixes:  10 minutes discussion.  It this document ready for
formal acceptance as a WG work item?

RADIUS Prefix Delegation: 5 Minutes to discuss the review was posted to
the mailing list.=20

Comments on this first draft proposed agenda are solicited, and
encouraged, keeping within the theme of "Getting to Done".

Thanks!

Dave Nelson

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 09 Feb 2006 21:36:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Allowed Usage
Date: Thu, 9 Feb 2006 16:39:09 -0500
From: "Avi Lior" <[email-masked]>
To: "Greg Weber \(gdweber\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>

There is no reason to include even a flush in a disconnect request.

If you are successful in disconnect, then the flush will happen anyway.
If you are not successful in disconnecting then even if you included
flush nothing will happen.

Avi=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Greg Weber=20
> (gdweber)
> Sent: Wednesday, February 01, 2006 7:42 PM
> To: Bernard Aboba; [email-masked]
> Subject: RE: Issue: Allowed Usage
>=20
>=20
> Also, the textual description of Ingress-Filters says that it=20
> MUST NOT be included in Disconnect-Request messages (and some=20
> other types of messages).  This is not reflected in the Table=20
> of Attributes in Section 4 which may be confusing.  Would any=20
> of these attributes be used in Disconnect-Request messages? =20
> I'd guess not, except maybe a flush rule...  :)
>=20
> Greg
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > Sent: Sunday, January 29, 2006 3:07 PM
> > To: [email-masked]
> > Subject: Issue: Allowed Usage
> >=20
> > Issue : Allowed Usage
> > Submitter names: Bernard Aboba
> > Submitter email address: [email-masked] Date first submitted:=20
> > January 29, 2006
> > Reference:
> > Document: IEEE 802-01
> > Comment type: 'T'echnical |
> > Priority: S
> > Section: Various
> > Rationale/Explanation of issue:
> >=20
> > In Section 4, the Table of Attributes states the following:
> >=20
> >       The following table provides a guide to which=20
> attributes may be
> >       found in which kinds of packets, and in what quantity.
> >=20
> >       Access- Access- Access- Access-   CoA-
> >       Request Accept  Reject  Challenge Req  #   Attribute
> >       0       0+      0       0         0+   TBD Egress-VLANID
> >       0       0-1     0       0         0-1  TBD Ingress-Filters
> >       0       0-1     0       0         0-1  TBD User-Priority-Table
> >=20
> > The Egress-VLAN-Name attribute is not included in this=20
> table, nor is=20
> > it included in the IANA considerations section.
> >=20
> > Section 2.1:
> >=20
> >          Multiple Egress-VLANID attributes can be delivered in an
> >          authentication response; each attribute adds the specified=20
> > VLAN
> >          to the list of allowed egress VLANs for the port.
> >=20
> > This would appear to indicate that the Egress-VLAN-Name=20
> attribute is=20
> > allowed in Access-Challenge, Access-Reject and=20
> Access-Accept packets.
> > Yet, the attribute table in Section 4 does not seem to permit=20
> > inclusion in Reject or Challenge packets.
> >=20
> > Section 2.3:
> >=20
> >          Multiple Egress-VLAN-Name attributes can be delivered in an
> >          authentication response; each attribute adds the=20
> named VLAN=20
> > to
> >          the list of allowed egress VLANs for the port.
> >=20
> > This would appear to indicate that the Egress-VLAN-Name=20
> attribute is=20
> > allowed in Access-Challenge, Access-Reject and=20
> Access-Accept packets.
> > There is no entry in the Attribute Table to confirm this.
> >=20
> > Section 2.4:
> >=20
> > There is no material on permitted usage of the User-Priority-Table=20
> > attribute.
> >=20
> >=20
> >=20
> > --
> > to unsubscribe send a message to=20
> [email-masked] with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 09 Feb 2006 21:18:46 +0000
Content-class: urn:content-classes:message
Subject: RE: [Issue] Authorize Only usage in HTTP redirect
Date: Thu, 9 Feb 2006 16:20:40 -0500
From: "Avi Lior" <[email-masked]>
To: "Greg Weber \(gdweber\)" <[email-masked]>, <[email-masked]>

Greg is right.  The spec is silent about whether or not the
Access-Accept contains a Service-Type or even what value it will have.=20

I don't have a problem with the proposed text.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Greg Weber=20
> (gdweber)
> Sent: Thursday, February 02, 2006 5:54 PM
> To: [email-masked]
> Subject: [Issue] Authorize Only usage in HTTP redirect
>=20
> Description of issue: Authorize Only usage in HTTP redirect=20
> Submitter name: Greg Weber Submitter email address:=20
> [email-masked] Date first submitted: February 2, 2006
> Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html
> Document: IEEE802-01
> Comment type: Technical
> Priority: S
> Section: A.2.2
> Rationale/Explanation of issue:
>=20
> Section A.2.2 Mid-session HTTP Redirection reads:
>=20
>       If HTTP redirection is required to be applied to a service that=20
>       has already been started then the RADIUS server can push the=20
>       redirection rules, and optionally the filter rules, to the NAS=20
>       within a NAS-Filter-Rule(TBD) attribute using a CoA=20
> message. The=20
>       NAS will then commence to apply the redirection rules=20
> and/or the=20
>       filter rules. =20
>       =20
>       Alternatively, the RADIUS server can request that the NAS re-
>       authorize the session using the procedures defined in=20
> [RFC3576].=20
>       The RADIUS server responds with an Access-Accept message (with=20
>       Service-Type(6) set to "Authorize Only" that will contain the=20
>       redirection and optionally filtering rules within a NAS-Filter-
>       Rule(TBD) attribute.=20
>=20
> I don't think "Authorize Only" is a valid Service-Type value=20
> in Access-Accept messages.  The server should be indicating=20
> the assigned Service in the Access-Accept.  Take a look at=20
> the last paragraph of RFC 3576's Section 1.1.  I think that=20
> describes the process your referring to here.
>=20
> Requested change:
>=20
> I suggest replacing the above text with something like:
>=20
> If HTTP redirection is required to be applied to a service=20
> that has already been started, then the RADIUS server may use=20
> either of the procedures defined in [RFC3576]:
>=20
>  - The server may send the NAS a CoA-Request message including
>    a NAS-Filter-Rule which contains redirection rules and
>    optionally filter rules.  The NAS will then apply the new
>    rules to the existing services.
>  - The server may send the NAS a CoA-Request message including
>    a Service-Type attribute with the value of "Authorize Only".
>    This will trigger the NAS to reauthorize the existing service
>    by sending the server an Access-Request message containing a
>    Service-Type attribute with the value of "Authorize Only".
>    The server may then send the NAS new redirection and optionally
>    filter rules within a NAS-Filter-Rule as part of an Access-
>    Accept message.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Feb 2006 19:46:15 +0000
Content-class: urn:content-classes:message
Subject: Issue
Date: Wed, 8 Feb 2006 11:45:47 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: "Glen Zorn \(gwz\)" <[email-masked]>

Description of issue: Typo, (presumably) incorrect phrasing
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: 08 Feb 06
Document: ieee-802
Comment type: E
Priority: 1
Section: 6
Rationale/Explanation of issue: Paragraph 1 says: "Since this document
describes the use of RADIUS for purposes of authentication,
authorization, and accounting in IEEE 802.1X-nabled networks, it is
vulnerable to all of the threats that are present in other RADIUS
applications. For a discussion of these  threats, see [RFC2607],
[RFC3162], [RFC3579], and [RFC3580]."  Are there threats present in
RADIUS applications?  Shouldn't we eradicate these things instead of
referencing them? ;-)=20

Requested change:=20
Change "IEEE 802.1X-nabled" to "IEEE 802.1X-enabled"

Re-word the paragraph to have the correct meaning; suggest "Since this
document describes the use of RADIUS for purposes of authentication,
authorization, and accounting in IEEE 802.1X-enabled networks, it is
vulnerable to the same threats as other RADIUS applications. For a
discussion of these  threats, see [RFC2607], [RFC3162], [RFC3579], and
[RFC3580]."=20

~gwz

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Feb 2006 18:33:01 +0000
Date: Wed, 8 Feb 2006 19:32:31 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Cc: Bert Wijnen <[email-masked]>
Subject: radius dynauth client/server mibs structure
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], Bert Wijnen <[email-masked]>

Hi,

I took a quick look at the radius dynauth client/server mibs today:

   draft-ietf-radext-dynauth-client-mib-03.txt
   draft-ietf-radext-dynauth-server-mib-03.txt

While looking at the OID tree, I came up with the following stylistic
change. Currently, the OID tree of the two MIBs basically looks like
this (details of the tables and conformance nodes deleted):

--radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
  |
  +--radiusDynAuthServerMIBObjects(1)
  |  |
  |  +--radiusDynAuthServer(1)
  |     |
  |     +--radiusDynAuthServerDisconInvalidClientAddresses(1)
  |     +--radiusDynAuthServerCoAInvalidClientAddresses(2)
  |     +--radiusDynAuthServerIdentifier(3)
  |     |
  |     +--radiusDynAuthClientTable(4)
  |
  +--radiusDynAuthServerMIBConformance(2)

--radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
  |
  +--radiusDynAuthClientMIBObjects(1)
  |  |
  |  +--radiusDynAuthClient(1)
  |     |
  |     +--radiusDynAuthClientDisconInvalidServerAddresses(1)
  |     +--radiusDynAuthClientCoAInvalidServerAddresses(2)
  |     |
  |     +--radiusDynAuthServerTable(3)
  |
  +--radiusDynAuthClientMIBConformance(2)

I was wondering what the value of having the radiusDynAuthServer and
radiusDynAuthClient nodes is. I do understand if people like to group
related scalars together (so additions are numbered using consecutive
identifiers), but then the OID structure should more look like the
following:

--radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
  |
  +--radiusDynAuthServerMIBObjects(1)
  |  |
  |  +--radiusDynAuthServerScalars(1)
  |  |  |
  |  |  +--radiusDynAuthServerDisconInvalidClientAddresses(1)
  |  |  +--radiusDynAuthServerCoAInvalidClientAddresses(2)
  |  |  +--radiusDynAuthServerIdentifier(3)
  |  |
  |  +--radiusDynAuthClientTable(2)
  |
  +--radiusDynAuthServerMIBConformance(2)

--radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
  |
  +--radiusDynAuthClientMIBObjects(1)
  |  |
  |  +--radiusDynAuthClientScalars(1)
  |  |  |
  |  |  +--radiusDynAuthClientDisconInvalidServerAddresses(1)
  |  |  +--radiusDynAuthClientCoAInvalidServerAddresses(2)
  |  |
  |  +--radiusDynAuthServerTable(2)
  |
  +--radiusDynAuthClientMIBConformance(2)

The benefit of this change is that you can add scalars later while
keep all the scalars rooted together and consecutively numbered while
in the current scheme you end up to have tables intermixed with
scalars over time.

Please note that there is nothing technically wrong with the MIBs as
they are right now. My suggestion is purely stylistic and basically
just increases readability in case updates are done in the future.

I am aware that these MIB modules have passed WG last call and MIB
review and are in the hands of the ADs and as such I do not ask to
make a change just for stylistic reasons. I just wanted to bring this
to your attention and I like to leave it to the editors/chairs to
decide whether you want to make the relatively simple changes at this
point in time or prefer to go ahead with what you have.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Feb 2006 13:57:31 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: AW: [secdir] draft-ietf-radext-digest-auth06.txt, proposal
Date: Wed, 8 Feb 2006 14:56:52 +0100 

I think we have two options
1. remove the mode where the RADIUS client generates nonces
2. embed a time-stamp into the nonce

Option 1. would be easy but it was rejected by the WG at the 64th IETF.

Here's a proposal for option 1. I am fully aware that I am doing amateur
cryptography.

3.2.5.  Obtaining Nonces

   The RADIUS client has three ways to obtain nonces: it generates them
   locally, it has received one in a Digest-Nextnonce attribute of a
   previously received Access-Accept packet, or it asks the RADIUS
   server for one.  To do the latter, it sends an Access-Request
   containing a Digest-Method and a Digest-URI attribute but without a
   Digest-Nonce attribute.  It adds a Message-Authenticator (see
   [RFC3579]) attribute to the Access-Request packet.  The RADIUS server
   chooses a nonce and responds with an Access-Challenge containing a
   Digest-Nonce attribute.

   The RADIUS client constructs a (Proxy-)Authenticate header using the
   received Digest-Nonce and Digest-Realm attributes to fill the nonce
   and realm directives.  The RADIUS server can send Digest-Qop, Digest-
   Algorithm, Digest-Domain and Digest-Opaque attributes in the Access-
   Challenge carrying the nonce.  If these attributes are present, the
   client MUST use them.

   If the RADIUS client generates nonces, the nonce must contain a time-
   stamp.  The nonce is constructed as follows:

         nonce = base64(concat(ts, hn(concat(random-pad, ts), secret)))

         where

         'base64(x)' encodes string x in base64 (see [RFC3548])

         'concat(a, b)' appends string b to string a

         'ts' is an unsigned integer of 4 bytes in network byte order
         with the number of seconds since January 1, 1970 00:00 UTC.

         'secret' is the shared secret between RADIUS client and server

         'hn(secret, message)' produces a hash of 'message' using the
         pass phrase 'secret'. 'hn' is the HMAC MD5 function described
         in [RFC2104].

         'random-pad' is a string of 56 random characters that is
         uniquely generated for each nonce.

   The time-stamp enables the RADIUS server to reject replayed nonces.
   The clock difference between RADIUS client and RADIUS server MUST NOT
   exceed 10 s.
[...]
3.3.2.  Determining the Age of the Nonce

   If the RADIUS server generates nonces, it will determine the age of a
   nonce by using an embedded time-stamp, or by looking it up in a local
   table.  The RADIUS server MUST check the integrity of the nonce, if
   it embeds the time-stamp in the nonce.  Section 3.3.3 describes how
   the server handles old nonces.

   If the RADIUS client generates nonces, the RADIUS server checks the
   the embedded time-stamp.  The RADIUS server responds to an Access-
   Request with a nonce that is too old or too young with an Access-
   Reject packet.  RADIUS servers logging rejected requests should
   include a hint to the operator that a too big clock difference caused
   the rejection.

   A nonce is considered too young if the received time-stamp is greater
   than the current time plus 11 s, allowing 1 s of packet delay.

   A nonce is considered too old if the received time-stamp is less than
   the current time minus 9 s, allowing 1 s of packet delay.

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Feb 2006 19:09:02 +0000
Content-class: urn:content-classes:message
Subject: RE: digest-auth, nonce replay issue 
Date: Tue, 7 Feb 2006 11:08:15 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
Cc: <[email-masked]>

Beck01, Wolfgang <mailto:[email-masked]> supposedly scribbled:

> Glen wrote
>> However, your the draft doesn't say
>>=20
>>    o  If the Digest-Qop attribute's value is 'auth-int' and at least
>>       one of the following conditions is true, the RADIUS server
>>       SHOULD put a Digest-HA1 attribute into the Access-Accept
>> packet:=20
>>       *  The Digest-Algorithm attribute's value is 'MD5-sess' or
>> 'AKAv1-          MD5-sess'.=20
>>       *  The password was not posted on a mailing list (see Section
>>    9). In all other cases, Digest-Response-Auth or Digest-HA1 MUST
>> NOT be    sent. Since the second condition is, AFAIK, unverifiable,
>> it would make=20
>> sense to simply remove it as extraneous.  However, my guess is that
>> it's there for a reason; therefore, I would advise making it depend
>> upon a form of security that the RADIUS client/server can actually
>> check.
>=20
> If I remove the IPSec-condition, I am sure somebody will complain
> about it.=20

If they complain, let them tell how to verify whether or not the =
condition has been met; if they cannot, their complaint has no validity.

> In an earlier version, I used the phrase 'protected'
> instead of IPSec which would have included future mechanisms, like
> RADIUS attribute encryption.  =20
> On request of the WG, this was replaced with IPSec.

Of course: this being the RADIUS Extensions WG, the last thing we would =
want is actual extensibility...

>=20
> The above section of the draft is already hard to read, so I will add
> something to the referenced Security Considerations, like:=20
>=20
> 'Some parameter combinations require the protection of the RADIUS
> packet against eavesdropping and tampering. Implementations SHOULD
> try to determine automatically whether RADIUS packets will be sent
> and received over IPSec. If this is not possible, the implementation
> checks a configuration parameter telling it whether RADIUS traffic
> will be protected with IPSec. It must be explicitly set by the
> operator. The default value of this parameter tells the
> implementation that the RADIUS packet will not be protected.'

Unfortunately, this still says very little about the actual state of =
IPSec at the time the packets are transmitted or received, which is the =
condition you are checking.  If you make this change, you should also =
note this in the Security Considerations section, & change the =
condition(s) from "The packets between RADIUS client and RADIUS server =
are protected with IPsec (see Section 9)." or similar to "IPSec is =
configured to protect traffic between the RADIUS client and RADIUS =
server (see Section 9)." or similar.=20
     =20
>=20
> Wolfgang

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Feb 2006 13:05:14 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: digest-auth, nonce replay issue 
Date: Mon, 6 Feb 2006 14:04:30 +0100 

Glen wrote
> However, your the draft doesn't say 
> 
>    o  If the Digest-Qop attribute's value is 'auth-int' and at least one
>       of the following conditions is true, the RADIUS server SHOULD put
>       a Digest-HA1 attribute into the Access-Accept packet:
>       *  The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-
>          MD5-sess'.
>       *  The password was not posted on a mailing list (see Section 9).
>    In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
>    sent.
> Since the second condition is, AFAIK, unverifiable, it would 
> make sense to simply remove it as extraneous.  However, my 
> guess is that it's there for a reason; therefore, I would 
> advise making it depend upon a form of security that the 
> RADIUS client/server can actually check.

If I remove the IPSec-condition, I am sure somebody will complain about
it. In an earlier version, I used the phrase 'protected' instead of IPSec
which would have included future mechanisms, like RADIUS attribute encryption.
On request of the WG, this was replaced with IPSec. 

The above section of the draft is already hard to read, so I will add something
to the referenced Security Considerations, like:

'Some parameter combinations require the protection of the RADIUS packet against
eavesdropping and tampering. Implementations SHOULD try to determine automatically
whether RADIUS packets will be sent and received over IPSec. If this is not possible,
the implementation checks a configuration parameter telling it whether RADIUS traffic
will be protected with IPSec. It must be explicitly set by the operator. The default
value of this parameter tells the implementation that the RADIUS packet will not be
protected.'

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 03 Feb 2006 17:15:24 +0000
Content-class: urn:content-classes:message
Subject: RE: digest-auth, nonce replay issue 
Date: Fri, 3 Feb 2006 09:15:08 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
Cc: <[email-masked]>

Beck01, Wolfgang <mailto:[email-masked]> supposedly scribbled:

>> Searching about in the draft, I can't find any place where the words
>> "MUST" and "IPSec" appear in the same sentence
> You are right. I mixed it up with Digest-HA1.
>=20
>> I do find several passages that assume that applications can know
>> whether or not the application traffic is protected by IPSec,
>> something that I was unaware was possible...
> The application can not detect if the password was posted on a
> mailing list either.=20

However, your the draft doesn't say=20

   o  If the Digest-Qop attribute's value is 'auth-int' and at least one
      of the following conditions is true, the RADIUS server SHOULD put
      a Digest-HA1 attribute into the Access-Accept packet:
      *  The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-
         MD5-sess'.
      *  The password was not posted on a mailing list (see Section 9).
   In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
   sent.

It does, however, say this:

   o  If the Digest-Qop attribute's value is 'auth-int' and at least one
      of the following conditions is true, the RADIUS server SHOULD put
      a Digest-HA1 attribute into the Access-Accept packet:
      *  The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-
         MD5-sess'.
      *  The packets between RADIUS client and RADIUS server are
         protected with IPsec (see Section 9).
   In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
   sent.

Since the second condition is, AFAIK, unverifiable, it would make sense =
to simply remove it as extraneous.  However, my guess is that it's there =
for a reason; therefore, I would advise making it depend upon a form of =
security that the RADIUS client/server can actually check.

>=20
> For the argument's sake, an application could consult the local ipsec
> policy database and look if the RADIUS address quadruple is covered
> by an appropriate rule. I am aware that existing APIs are not
> sufficient here and VPN tunnels can't be discovered this way.  =20
>=20
> A pragmatic approach would be to spell out a warning in the manual or
> in the syslog 'If you plan to use such and that option, make sure
> your RADIUS traffic is protected or you'll be doomed'=20

The actual state of operation of IPSec is being used to determine the =
operation of Digest-Auth (either send an Attribute or don't), but that =
state cannot be used because it is undeterminable from the application =
layer.

>=20
>>> However, the RADIUS server has to trust the first timestamp it
>>> receives from a RADIUS client. What if the RADIUS client's clock is
>>> adjusted during operation?
>>=20
>> That's why you have to specify the required level of clock
>> synchronization...=20
> I feel a bit uneasy about this. When some technician plays with the
> time zone, a whole SIP server won't be able to handle calls any
> longer. =20

GMT/UCT.

>=20
>>=20
>> ...
>>=20
>>> Hope this helps,
> It does.
>=20
>=20
> Wolfgang

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 03 Feb 2006 16:24:14 +0000
Content-class: urn:content-classes:message
Subject: RE: digest-auth, nonce replay issue 
Date: Fri, 3 Feb 2006 11:23:28 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Wolfgang Beck writes...

> The application can not detect if the password was posted on a
> mailing list either.

I'm not sure it helps to resort to sarcasm.

> A pragmatic approach would be to spell out a warning in the
> manual or in the syslog 'If you plan to use such and that
> option, make sure your RADIUS traffic is protected or you'll
> be doomed'

I bet the marketing department will have something to say about your
choice of phrasing.  :-)

In point of fact, I understand that there is not a standard API that an
application can use to detect the current IPsec SAs in use for its
network connections.  IMHO, that is a severe failing of IPsec, but
that's a whole different discussion.

The question in this case, I think, is what assurances can the protocol
implementation make, and what assurances depend upon correct
configuration by human operators?  It is important that the Security
Considerations spell all this out in a clear fashion.  If the potential
attacks exceed the expectations of the threat model, then there are
substantial security flaws in the design.

> > That's why you have to specify the required level of clock
> synchronization...
>
> I feel a bit uneasy about this. When some technician plays with the
time
> zone, a whole SIP server won't be able to handle calls any longer.

That would be part of the "assurances that depend upon correct
configuration by human operators", right?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 03 Feb 2006 14:27:51 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: digest-auth, nonce replay issue 
Date: Fri, 3 Feb 2006 15:27:34 +0100 

> Searching about in the draft, I can't find any place where 
> the words "MUST" and "IPSec" appear in the same sentence
You are right. I mixed it up with Digest-HA1.

> I do find several passages that assume that applications can 
> know whether or not the application traffic is protected by 
> IPSec, something that I was unaware was possible...
The application can not detect if the password was posted on a
mailing list either.

For the argument's sake, an application could consult the local
ipsec policy database and look if the RADIUS address quadruple
is covered by an appropriate rule. I am aware that existing APIs
are not sufficient here and VPN tunnels can't be discovered
this way.

A pragmatic approach would be to spell out a warning in the
manual or in the syslog 'If you plan to use such and that
option, make sure your RADIUS traffic is protected or you'll
be doomed'

> > However, the RADIUS server has to trust the first timestamp it 
> > receives from a RADIUS client. What if the RADIUS client's clock is 
> > adjusted during operation?
> 
> That's why you have to specify the required level of clock synchronization...
I feel a bit uneasy about this. When some technician plays with the time zone,
a whole SIP server won't be able to handle calls any longer.

> 
> ...
> 
> > Hope this helps,
It does.

Wolfgang

--
T-Systems Enterprise Services GmbH
Technologiezentrum
Next Generation IP Services and Systems
+49 6151 9372863
Am Kavalleriesand 3
64295 Darmstadt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 03 Feb 2006 13:43:01 +0000
Cc: Laurent Toutain <[email-masked]>, [email-masked]
From: Bruno STEVANT <[email-masked]>
Subject: Proposal for extension of Radius Accounting
Date: Fri, 3 Feb 2006 14:42:05 +0100
To: [email-masked]

Good day all

We at Point6 are working in the Softwires WG on a solution for IPv6  
access for Home Networks, as described in draft-toutain-softwire- 
point6box-00.txt
In this solution we use L2TP/PPP for IPv6 tunneling. Access AAA  
parameters are managed with Radius.

We found an issue with current FreeBSD PPP implementation on Radius  
accounting :
Attributes Acct-{Input,Output}-Octets and Acct-{Input,Output}-Packets  
are only based on accounting informations from IPCP. Since our  
solution only use IPV6CP, we have to modify the code in PPP to send  
IPV6CP accounting information in these Radius attributes.

The basic solution may be just to add IPCP and IPV6CP values and to  
transmit these sums as value for these attributes.
Another solution may also to have separate accounting attributes for  
IPv4 and IPv6. We think this may be only relevant for packets (as it  
is done in system MIBs for instance). Our proposal is to have two  
more attributes for Radius accounting : Acct-IPv6-Input-Packets and  
Acct-IPv6-Output-Packets.

The rational of this proposal is to give operators who deploy dual  
stack access solution some accounting information about IPv6/IPv4  
usage ratio.
We ask the Radext WG to take position on this proposal. Some inputs  
may also come from the Softwires WG.

Regards,
-- 
Bruno STEVANT - Point6

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 03 Feb 2006 01:29:52 +0000
Content-class: urn:content-classes:message
Subject: RE: digest-auth, nonce replay issue 
Date: Thu, 2 Feb 2006 17:29:18 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

[email-masked] <mailto:[email-masked]> =
supposedly scribbled:

...

>> Maybe not: I think that it is only necessary for the attacker to be
>> capable of eavesdropping on the conversation between the RADIUS
>> client & server & then masquerading as the client later, possibly by
>> replaying the Access-Request.=20
>>=20
> RADIUS server and client must use IPSec in the relevant mode anyway,

Searching about in the draft, I can't find any place where the words =
"MUST" and "IPSec" appear in the same sentence.  I do find several =
passages that assume that applications can know whether or not the =
application traffic is protected by IPSec, something that I was unaware =
was possible...

...

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 23:13:58 +0000
Content-class: urn:content-classes:message
Subject: RE: digest-auth, nonce replay issue 
Date: Thu, 2 Feb 2006 15:13:40 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

[email-masked] <mailto:[email-masked]> =
supposedly scribbled:

...

>>> Is the granularity of minutes sufficient?
>>=20
>> Depends upon the expected session length: are all (or a very high
>> percentage of) sessions expected to last more than a minute?  If so,
>> then one minute granularity is fine.  If you're going to use
>> timestamps you need to define the required level of clock
>> synchronization between the client and server...
>>=20
> My intention was to use a 32 bit value that won't overflow in 2038
> (the German pension regulations are about to be changed, I might have
> still to work then..). =20
>=20
> As the Event-Timestamp attribute uses seconds, we can use seconds
> here as well.=20
>=20
> However, the RADIUS server has to trust the first timestamp it
> receives from a RADIUS client. What if the RADIUS client's clock is
> adjusted during operation? =20

That's why you have to specify the required level of clock =
synchronization...

>=20
> In the IESG review, you mentioned a similar problem with CHAP. Do you
> have some pointers how it was solved?=20

AFAIK, it wasn't.

>=20
>=20
> Wolfgang

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 22:54:32 +0000
Content-class: urn:content-classes:message
Subject: [Issue] Handling an unparsable NAS-Filter-Rule
Date: Thu, 2 Feb 2006 17:54:38 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Handling an unparsable NAS-Filter-Rule
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: February 2, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html
Document: IEEE802-01
Comment type: Technical
Priority: S
Section: 1.4, 6
Rationale/Explanation of issue:

The NAS-Filter-Rule represents a *lot* of functionality.
I think we can expect lots of variability in NASes which
support various parts, e.g. maybe all the filtering, but
not HTTP redirection, etc.  I think we maybe need to be
clearer on what is supposed to happen when the NAS gets
a CoA-Request or Access-Request containing directives
that it cannot parse or apply.  In particular, in Section
1.4 "Attribute Interpretation", I see text indicating that
non-understood attributes result in Access-Rejects.  But,
in Section 6 "Security Considerations", I see text like:
"...a NAS could be configured to ... not accept any
redirection rules if it is known they are not used in
this environment."   These would seem to be contradictory.

Requested change:
Need clarification on the intent.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 22:54:21 +0000
Content-class: urn:content-classes:message
Subject: [Issue] Precedence and order for NAS-Filter-Rule
Date: Thu, 2 Feb 2006 17:54:32 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Precedence and order for NAS-Filter-Rule
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: February 2, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html
Document: IEEE802-01
Comment type: Technical
Priority: S
Section: 2.5
Rationale/Explanation of issue:

At the very end of Section 2.5 on NAS-Filter-Rule,
it says that the NAS can apply rules of its own before
rules supplied via the interface in this document.
I didn't understand the ordering and precedence=20
between filters originated from the different sources.
Is that covered somewhere?  If the server sends a=20
flush-rule via CoA-Request, does that remove the=20
NAS originated (configured) rules?  The text is implying
that the rules are applied in specific order based on=20
type, e.g. HTTP filter rules are last.  What if the NAS
defines the HTTP filter rule, and other types come via=20
CoA?  What's the order then?  This seems like an area
of likely implementation confusion.

Requested change:
I think the precedence of locally configured rules
relative to dynamic updates needs to be clarified. =20
It might also be useful to treat this in the examples
of Appendix B.  This seems similar to Issue 107
related to Acct-Interim-Interval.  The NAS owner needs
to be able to protect his resources, and the server
owner needs predictable results for dynamic updates.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 22:54:13 +0000
Content-class: urn:content-classes:message
Subject: [Issue] Tag option in VLAN attributes
Date: Thu, 2 Feb 2006 17:54:20 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Tag option in VLAN attributes
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: February 2, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html
Document: IEEE802-01
Comment type: Technical
Priority: S
Section: 2.1, 2.3
Rationale/Explanation of issue:

The Egress-VLANID attribute proposed in Section 2.1=20
is defined as data type "Integer":

   0                   1                   2                   3=20
   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=20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
  |     Type      |    Length     |  Tag Option   |   Pad (12-bit)

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
    Pad   |    VLANID (12-bit)    | =20
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

I think this is going to be confusing because it similar
formatting to the 'tagging mechanism' defined in RFC 2868.
Also wondering if it's possible to not overload a single
integer with two values?  Won't this make configuring the
value on the server more difficult.  Can each VLAN have=20
an independent tagged/untagged value?  Why are 0x31 & 0x32=20
used? =20

Requested change:
At least, I'd suggest changing "Tag Option" to "VLAN Tag"
or something like that.  Guess I'd have to understand
this better to suggest if the Tag and ID can be separated.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 22:54:08 +0000
Content-class: urn:content-classes:message
Subject: [Issue] Authorize Only usage in HTTP redirect
Date: Thu, 2 Feb 2006 17:54:13 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Authorize Only usage in HTTP redirect
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: February 2, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html
Document: IEEE802-01
Comment type: Technical
Priority: S
Section: A.2.2
Rationale/Explanation of issue:

Section A.2.2 Mid-session HTTP Redirection reads:

      If HTTP redirection is required to be applied to a service that=20
      has already been started then the RADIUS server can push the=20
      redirection rules, and optionally the filter rules, to the NAS=20
      within a NAS-Filter-Rule(TBD) attribute using a CoA message. The=20
      NAS will then commence to apply the redirection rules and/or the=20
      filter rules. =20
      =20
      Alternatively, the RADIUS server can request that the NAS re-
      authorize the session using the procedures defined in [RFC3576].=20
      The RADIUS server responds with an Access-Accept message (with=20
      Service-Type(6) set to "Authorize Only" that will contain the=20
      redirection and optionally filtering rules within a NAS-Filter-
      Rule(TBD) attribute.=20

I don't think "Authorize Only" is a valid Service-Type value in
Access-Accept messages.  The server should be indicating the
assigned Service in the Access-Accept.  Take a look at the last
paragraph of RFC 3576's Section 1.1.  I think that describes the
process your referring to here.

Requested change:

I suggest replacing the above text with something like:

If HTTP redirection is required to be applied to a service that=20
has already been started, then the RADIUS server may use either
of the procedures defined in [RFC3576]:

 - The server may send the NAS a CoA-Request message including
   a NAS-Filter-Rule which contains redirection rules and
   optionally filter rules.  The NAS will then apply the new
   rules to the existing services.
 - The server may send the NAS a CoA-Request message including
   a Service-Type attribute with the value of "Authorize Only".
   This will trigger the NAS to reauthorize the existing service
   by sending the server an Access-Request message containing a
   Service-Type attribute with the value of "Authorize Only".
   The server may then send the NAS new redirection and optionally
   filter rules within a NAS-Filter-Rule as part of an Access-
   Accept message.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 22:43:11 +0000
Content-class: urn:content-classes:message
Subject: RE: NAS-Filter-Rule (was: review of draft-ietf-radext-ieee802-01.txt)
Date: Thu, 2 Feb 2006 16:16:08 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Bert Wijnen writes...
=20
>   If WG A cannot reach (or has trouble reaching)
>   consensus/agreement on a specific work item,
>   then what arguments do we have that WG B
>   can do better?

None.

However, I don't think that the issue is that the RADEXT WG cannot come
to consensus on a technical approach as much as it is the fact that a
RADEXT draft is proposing to extend the existing Diameter
NAS-Filter-Rule syntax.  There are at least two problems here: (1)
RADIUS is not supposed to be a super-set of Diameter in any of its
features, and (2) failing to address a corresponding extension in
Diameter causes difficulty for the translation gateway process.  It was
suggested that, if an extension to the Diameter NAS-Filter-Rule is
required for use in RADIUS, that we actually extend the Diameter
NAS-Filter-Rule, rather that defining a separate RADIUS-NAS-Filter-Rule
attribute and syntax.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 21:19:57 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Thu, 2 Feb 2006 13:19:39 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

I had suggested in a previous email that we change the name of
NAS-Filter-Rule to something else to avoid any possibility that someone
may confuse this RADIUS attribute from what is already defined in
Diameter.

Diameter is going to inherit this new attribute anyway, so I'm unsure
what sort of compatibility issues may arise if we call the attribute
something 'Traffic-Rule'?

My expectation would be that NAS-Filter-Rule be deprecated.

MS=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, February 01, 2006 9:37 PM
> To: [email-masked]; [email-masked]
> Subject: Re: review of draft-ietf-radext-ieee802-01.txt
>=20
> >I'd like to understand this too.  I thought we didn't want=20
> to try & do=20
> >things in RADIUS that are not supported in Diameter.
>=20
> The RADEXT WG charter requires that Diameter compatibility issues be=20
> examined as part of each work item.   Extending the RFC 3588=20
> NAS-Filter-Rule=20
> syntax does bring up Diameter compatibility issues.  This was=20
> pointed out in Issue 130, which was filed in August 2005.
>=20
> As I understand it, the DIME WG is being chartered to produce=20
> RFC 3588bis, so one possibility is that they will consider a=20
> NAS-Filter-Rule syntax revision as part of that effort.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 21:06:50 +0000
Content-class: urn:content-classes:message
Subject: Issue 167: Compatibility with RFC 2866 and RFC 3576 Submitter
Date: Thu, 2 Feb 2006 13:06:12 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>

Bernard asserted...=20

>=20
> Issue 167: Compatibility with RFC 2866 and RFC 3576 Submitter=20
> names: Bernard Aboba Submitter email address:=20
> [email-masked] Date first submitted: January 30, 2006
> Reference:
> Document: IEEE 802-01
> Comment type: Technical
> Priority: S
> Section: 1.4
> Rationale/Explanation of issue:
>=20
> Section 1.4 states:
>=20
>   1.4 Attribute Interpretation
>=20
>      Unless otherwise noted in the individual description of an
>      attribute contained herein, a NAS that conforms to this
>      specification and receives an Access-Accept message that contains
>      an attribute from this document that it cannot apply MUST
>      interpret this though an Access-Reject had been sent and MUST
>      terminate the session.  If accounting is enabled on the NAS, it
>      MUST generate an Accounting-Request(Stop) message upon session
>      termination.
>=20
>      Similarly, if a NAS conforming to this specification and also
>      conforming to RFC 3576 [RFC3576] receives a CoA message that
>      contains an attribute from this document that it cannot apply, it
>      MUST NOT terminate the session and MUST generate a CoA-NAK packet
>      with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
>      accounting is enabled on the NAS, it MUST NOT generate an
>      Accounting-Request(Stop) message in such instances.
> RFC 2866 does not specify the generation of Accounting Stop=20
> messages resulting from Access-Reject packets.  This document=20
> is therefore requiring RADIUS accounting clients to generate=20
> accounting records in circumstances where they would not=20
> otherwise do so.  This raises the question of why this=20
> particular set of attributes would cause a special case=20
> modification to RFC 2866.

We are amendable to removing contentious references to accounting
behavior as noted in my email from yesterday (2/1/06) for Issue 111. =20
=20
> On inclusion of Error-Cause attributes:
>=20
>      It is possible that the NAS cannot honor Disconnect-Request or
>      CoA-Request messages for some reason.  The Error-Cause Attribute
>      provides more detail on the cause of the problem.  It MAY be
>      included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
>      messages.
>=20
> Since inclusion of an Error-Cause attribute is generally=20
> optional, the second paragraph mandates behavior not required=20
> by RFC 3576.

We are amendable to removing this paragraph.

Cheers,
MS

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 20:52:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: References
Date: Thu, 2 Feb 2006 12:52:24 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

=20

Bernard points out...

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, January 29, 2006 12:15 PM
> To: [email-masked]
> Subject: Issue: References
>=20
> Issue : References
> Submitter names: Bernard Aboba
> Submitter email address: [email-masked] Date first=20
> submitted: January 29, 2006
> Reference:
> Document: IEEE 802-01
> Comment type: Editorial
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>=20
> It is not clear to me why RFC 2868, 3162, 3576, 3579, 3580,=20
> 3748 are listed as  Normative References.  For example, an=20
> implementer would not be required to consult these documents=20
> in order to implement the specification.

We agree and will change the references from normative to informative.

>=20
> On the other hand, it seems like RFC 2674 and 3629 are=20
> referenced in a normative way; for example, if UTF-8 is=20
> supported, then an implementer would need to consult RFC=20
> 3629, no?  The reference to IEEE 802 also seems to be normative.

We agree and will change the references from informative to normative.

>=20
> Some of the references do not appear to be referenced in the=20
> specification. =20
> For example, there is no reference to RFC 1321, RFC 2866, RFC=20
> 2867, RFC 3748.

Good catch.  This are remnants of previous drafts. This will be removed.

Cheers,
MS

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 20:29:16 +0000
To: "Glen Zorn \(gwz\)" <[email-masked]>
cc: [email-masked]
Subject: Re: digest-auth, nonce replay issue 
Date: Thu, 02 Feb 2006 21:22:50 +0100
From: [email-masked]

Glen Zorn wrote:
> > nonce = concat(time-stamp, H(time-stamp ":" private-key), = second-part)
> >
> > time-stamp = minutes since Epoch in hexadecimal, padded to 8 digits
> >               second-part arbitrary data that might be interpreted
> > by the nonce generator to check the authencity of the nonce.
> >
> > One could argue that private-key is useless as Glen's attack requires
> > that the attacker has full access to the RADIUS client.
>
> Maybe not: I think that it is only necessary for the attacker to be 
> capable of eavesdropping on the conversation between the RADIUS client & 
> server & then masquerading as the client later, possibly by replaying 
> the Access-Request.
>
RADIUS server and client must use IPSec in the relevant mode anyway,
but as the nonce is sent in the clear between HTTP-style client and RADIUS
client, I think it should be protected.

> >
> > Is the granularity of minutes sufficient?
> 
> Depends upon the expected session length: are all (or a very high 
> percentage of) sessions expected to last more than a minute?  If so, 
> then one minute granularity is fine.  If you're going to use timestamps 
> you need to define the required level of clock synchronization between 
> the client and server...
> 
My intention was to use a 32 bit value that won't overflow in 2038 (the
German pension regulations are about to be changed, I might have still
to work then..).

As the Event-Timestamp attribute uses seconds, we can use seconds here
as well.

However, the RADIUS server has to trust the first timestamp it
receives from a RADIUS client. What if the RADIUS client's clock
is adjusted during operation?

In the IESG review, you mentioned a similar problem with CHAP. Do you
have some pointers how it was solved?

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 20:27:23 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: NAS-Filter-Rule (was: review of draft-ietf-radext-ieee802-01. txt)
Date: Thu, 2 Feb 2006 21:26:43 +0100 

Not that I do have concerns with this. In generic terms
that concern is:

  If WG A cannot reach (or has trouble reaching) 
  consensus/agreement on a specific work item,
  then what arguments do we have that WG B 
  can do better?

Bert

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, February 01, 2006 23:49
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: NAS-Filter-Rule (was: review of
> draft-ietf-radext-ieee802-01.txt)
> 
> 
> Hi all,
> 
> >The RADEXT WG charter requires that Diameter compatibility issues be 
> >examined as part of each work item.   Extending the RFC 3588 
> >NAS-Filter-Rule 
> >syntax does bring up Diameter compatibility issues.  This was 
> >pointed out in Issue 130, which was filed in August 2005.
> >
> >As I understand it, the DIME WG is being chartered to produce 
> >RFC 3588bis, so one possibility is that they will consider a 
> >NAS-Filter-Rule syntax revision as part of that effort.
> 
> I'm copying the DiME WG.  Is there interest in the Diameter community
> in revising the NAS-Filter-Rule?  For RADIUS, it is currently defined
> here:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-01.txt
> 
> I suggest that if this is of interest to both RADIUS & Diameter, we 
> come-up with a common format that would be usable in both protocols.
> 
> John
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 19:00:55 +0000
Content-class: urn:content-classes:message
Subject: RE: digest-auth, nonce replay issue
Date: Thu, 2 Feb 2006 11:00:36 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Beck01, Wolfgang <> supposedly scribbled:

> During the IESG review Glen Zorn pointed out, that the draft allows a
> nonce replay attack as the RADIUS server can't tell how old a nonce
> is. =20

Actually, the problem is that a valid response can be replayed, because =
the RADIUS server has no idea what the original nonce might have been, =
but I suppose it doesn't matter.

>=20
> So I've added some sentence like 'the nonce MUST contain some kind of
> timestamp'.=20
> Just before submitting -07, it dawned to me that this is not
> sufficient.=20
>=20
> In scenario 1, the RADIUS client communicates the nonce to the RADIUS
> server.=20
> As generator and consumer of the nonce are not the same system, we
> need to define a nonce format. RfC 2617 proposes=20
>=20
> time-stamp H(time-stamp ":" ETag ":" private-key)
>=20
> This is fine, but many HTTP-style messages don't have an ETag header.
> Even if there is one, the RADIUS server can't check it as there is no
> RADIUS attribute for ETag. We might structure the nonce mentally in
> two parts: =20
>=20
> nonce =3D concat(time-stamp, H(time-stamp ":" private-key), =
second-part)
>=20
> time-stamp =3D minutes since Epoch in hexadecimal, padded to 8 digits
>               second-part =3D arbitrary data that might be interpreted
> by the nonce generator to check the authencity of the nonce.=20
>=20
> One could argue that private-key is useless as Glen's attack requires
> that the attacker has full access to the RADIUS client.=20

Maybe not: I think that it is only necessary for the attacker to be =
capable of eavesdropping on the conversation between the RADIUS client & =
server & then masquerading as the client later, possibly by replaying =
the Access-Request.

>=20
> Is the granularity of minutes sufficient?

Depends upon the expected session length: are all (or a very high =
percentage of) sessions expected to last more than a minute?  If so, =
then one minute granularity is fine.  If you're going to use timestamps =
you need to define the required level of clock synchronization between =
the client and server...

>=20
>=20
> Wolfgang
>=20
> --
> T-Systems International GmbH
> Technologiezentrum
> Next Generation IP Services and Systems
> +49 6151 9372863
> Am Kavalleriesand 3
> 64295 Darmstadt

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 18:24:55 +0000
Content-class: urn:content-classes:message
Subject: RE: digest-auth, nonce replay issue
Date: Thu, 2 Feb 2006 13:23:46 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Wolfgang beck writes...

> During the IESG review Glen Zorn pointed out, that the draft=20
> allows a nonce replay attack as the RADIUS server can't tell=20
> how old a nonce is.
>=20
> So I've added some sentence like 'the nonce MUST contain some
> kind of timestamp'.  Just before submitting -07, it dawned to=20
> me that this is not sufficient.
>=20
> In scenario 1, the RADIUS client communicates the nonce to=20
> the RADIUS server.  As generator and consumer of the nonce are
> not the same system, we need to define a nonce format.=20
> RfC 2617 proposes
>=20
> time-stamp H(time-stamp ":" ETag ":" private-key)
>=20
> This is fine, but many HTTP-style messages don't have an=20
> ETag header. Even if there is one, the RADIUS server can't=20
> check it as there is no RADIUS attribute for ETag.
> We might structure the nonce mentally in two parts:
>=20
> nonce =3D concat(time-stamp, H(time-stamp ":" private-key),=20
> second-part)
>=20
> time-stamp =3D minutes since Epoch in hexadecimal, padded to=20
> 8 digits second-part =3D arbitrary data that might be interpreted
> by the nonce generator to check the authenticity of the nonce.
>=20
> One could argue that private-key is useless as Glen's attack=20
> requires that the attacker has full access to the RADIUS client.
>=20
> Is the granularity of minutes sufficient?

Time is ticking, and the IESG is waiting for a revised draft before
completing their review.  Would everyone on this WG list, who has an
interest in the Digest Authentication draft, please take a moment to
review this issue and respond to the list?  If we don't get any
responses, then maybe we can assume that no one needs this work?  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 07:50:27 +0000
Content-class: urn:content-classes:message
Subject: NAS-Filter-Rule (was: review of draft-ietf-radext-ieee802-01.txt)
Date: Thu, 2 Feb 2006 09:49:26 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi all,

>The RADEXT WG charter requires that Diameter compatibility issues be=20
>examined as part of each work item.   Extending the RFC 3588=20
>NAS-Filter-Rule=20
>syntax does bring up Diameter compatibility issues.  This was=20
>pointed out in Issue 130, which was filed in August 2005.
>
>As I understand it, the DIME WG is being chartered to produce=20
>RFC 3588bis, so one possibility is that they will consider a=20
>NAS-Filter-Rule syntax revision as part of that effort.

I'm copying the DiME WG.  Is there interest in the Diameter community
in revising the NAS-Filter-Rule?  For RADIUS, it is currently defined
here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-01.txt

I suggest that if this is of interest to both RADIUS & Diameter, we=20
come-up with a common format that would be usable in both protocols.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 05:36:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Re: review of draft-ietf-radext-ieee802-01.txt
Date: Wed, 01 Feb 2006 21:36:47 -0800

>I'd like to understand this too.  I thought we didn't
>want to try & do things in RADIUS that are not supported
>in Diameter.

The RADEXT WG charter requires that Diameter compatibility issues be 
examined as part of each work item.   Extending the RFC 3588 NAS-Filter-Rule 
syntax does bring up Diameter compatibility issues.  This was pointed out in 
Issue 130, which was filed in August 2005.

As I understand it, the DIME WG is being chartered to produce RFC 3588bis, 
so one possibility is that they will consider a NAS-Filter-Rule syntax 
revision as part of that effort.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 05:31:21 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Some questions about IEEE802-01
Date: Wed, 01 Feb 2006 21:30:53 -0800

Thanks for your comments, Greg.  It looks to me like each of the points you 
raise is a real issue, so please go ahead and file them.

>*) In A.2.2, regarding mid-session HTTP redirection,
>the text in the 2nd paragraph is talking about the
>RADIUS server sending an Access-Accept with Service-Type
>set to "Authorize Only".  I didn't understand what that
>was all about.  I thought "Authorize Only" could only
>be used in CoA-Request & Access-Request messages.
>Did I miss something there?

You didn't miss anything. I don't understand this usage of the "Authorize 
Only" Service-Type.

>*) At the very end of Section 2.5 on NAS-Filter-Rule,
>it says that the NAS can apply rules of its own before
>rules supplied via the interface in this document.
>I didn't understand the ordering and precendence
>between filters originated from the different sources.
>Is that covered somewhere?  If the server sends a
>flush-rule via CoA-Request, does that remove the
>NAS originated (configured) rules?  The text is implying
>that the rules are applied in specific order based on
>type, e.g. HTTP filter rules are last.  What if the NAS
>defines the HTTP filter rule, and other types come via
>CoA?  What's the order then?  This seems like an area
>of likely implementation confusion.

Yes, I think this is an issue.

>*) For Egress-VLANID & Egress-VLAN-Name, is there any
>particular reason to overload the "Tag Option" into
>the same attribute as the remainder values - instead
>of making the "Tag Option" portion a separate attribute?
>Wouldn't it be easier to configure on the server if
>these were separated out?  Also, if not separated,
>isn't calling the first octet a 'tag' confusing with
>the RADIUS tagged tunnel attributes?

My impression was that the usage was similar to the 'Tag' in the tunnel 
attributes, but perhaps I'm misreading the document.

>*) The NAS-Filter-Rule represents a *lot* of functionality.
>I think we can expect lots of variability in NASes to
>support various parts, e.g. maybe all the filtering, but
>not HTTP redirection, etc.  I think we maybe need to be
>clearer on what is supposed to happen when the NAS gets
>a CoA-Request or Access-Request containing directives
>that it cannot parse or apply.  In particular, in Section
>1.4 "Attribute Interpretation", I text indicating that
>non-understood attribute result in Access-Rejects.  But,
>in Section 6 "Security Considerations", I see text like:
>"...a NAS could be configured to ... not accept any
>redirection rules if it is known they are not used in
>this environment."   There seems to be some confusion
>about whether the NAS or server is authoritative.

Yes, I think there is a contradiction there.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 03:27:44 +0000
Content-class: urn:content-classes:message
Subject: Some questions about IEEE802-01
Date: Wed, 1 Feb 2006 22:27:12 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

I have a couple questions about IEEE802-01.
I'm not sure if these are issues, so thought
I'd just ask first.  I can file official=20
issues if needed.

*) In A.2.2, regarding mid-session HTTP redirection,
the text in the 2nd paragraph is talking about the
RADIUS server sending an Access-Accept with Service-Type
set to "Authorize Only".  I didn't understand what that
was all about.  I thought "Authorize Only" could only
be used in CoA-Request & Access-Request messages.=20
Did I miss something there?

*) At the very end of Section 2.5 on NAS-Filter-Rule,
it says that the NAS can apply rules of its own before
rules supplied via the interface in this document.
I didn't understand the ordering and precendence=20
between filters originated from the different sources.
Is that covered somewhere?  If the server sends a=20
flush-rule via CoA-Request, does that remove the=20
NAS originated (configured) rules?  The text is implying
that the rules are applied in specific order based on=20
type, e.g. HTTP filter rules are last.  What if the NAS
defines the HTTP filter rule, and other types come via=20
CoA?  What's the order then?  This seems like an area
of likely implementation confusion.

*) For Egress-VLANID & Egress-VLAN-Name, is there any
particular reason to overload the "Tag Option" into
the same attribute as the remainder values - instead=20
of making the "Tag Option" portion a separate attribute?
Wouldn't it be easier to configure on the server if
these were separated out?  Also, if not separated,=20
isn't calling the first octet a 'tag' confusing with
the RADIUS tagged tunnel attributes?

*) The NAS-Filter-Rule represents a *lot* of functionality.
I think we can expect lots of variability in NASes to
support various parts, e.g. maybe all the filtering, but
not HTTP redirection, etc.  I think we maybe need to be
clearer on what is supposed to happen when the NAS gets
a CoA-Request or Access-Request containing directives
that it cannot parse or apply.  In particular, in Section
1.4 "Attribute Interpretation", I text indicating that
non-understood attribute result in Access-Rejects.  But,
in Section 6 "Security Considerations", I see text like:
"...a NAS could be configured to ... not accept any
redirection rules if it is known they are not used in
this environment."   There seems to be some confusion
about whether the NAS or server is authoritative.

Greg

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 02:16:00 +0000
Content-class: urn:content-classes:message
Subject: Re: review of draft-ietf-radext-ieee802-01.txt
Date: Wed, 1 Feb 2006 21:15:38 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Regarding NAS-Filter-Rule:

> > The changes we have made are not simply extensions and the attribute
we
> > are defining is not purely a superset.=20
> Can you list what the specific differences are?

I'd like to understand this too.  I thought we didn't
want to try & do things in RADIUS that are not supported
in Diameter.

I noticed these in the text:
Section 1=20
"...extend the filter language described in [RFC3588]."
Section 2.5
"NAS-Filter-Rule is a superset in functionality..."

Greg

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 01:42:57 +0000
Content-class: urn:content-classes:message
Subject: Issue 165 - Allowed Usage
Date: Wed, 1 Feb 2006 17:42:30 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard rightly noticed...=20

> -----Original Message-----
> In Section 4, the Table of Attributes states the following:
>=20
>       The following table provides a guide to which attributes may be
>       found in which kinds of packets, and in what quantity.
>=20
>       Access- Access- Access- Access-   CoA-
>       Request Accept  Reject  Challenge Req  #   Attribute
>       0       0+      0       0         0+   TBD Egress-VLANID
>       0       0-1     0       0         0-1  TBD Ingress-Filters
>       0       0-1     0       0         0-1  TBD User-Priority-Table
>=20
> The Egress-VLAN-Name attribute is not included in this table,=20
> nor is it included in the IANA considerations section.

Oversight.  We will add it in.=20

>=20
> Section 2.1:
>=20
>          Multiple Egress-VLANID attributes can be delivered in an
>          authentication response; each attribute adds the=20
> specified VLAN
>          to the list of allowed egress VLANs for the port.
>=20
> This would appear to indicate that the Egress-VLAN-Name=20
> attribute is allowed in Access-Challenge, Access-Reject and=20
> Access-Accept packets.
> Yet, the attribute table in Section 4 does not seem to permit=20
> inclusion in Reject or Challenge packets.

Will changing
"Multiple Egress-VLANID attributes can be delivered in an authentication
response..."
to
"The RADIUS server can return multiple Egress-VLANID attributes in an
Access-Accept or CoA-Request packet..."
address this issue?

> Section 2.3:
>=20
>          Multiple Egress-VLAN-Name attributes can be delivered in an
>          authentication response; each attribute adds the=20
> named VLAN to
>          the list of allowed egress VLANs for the port.
>=20
> This would appear to indicate that the Egress-VLAN-Name=20
> attribute is allowed in Access-Challenge, Access-Reject and=20
> Access-Accept packets.
> There is no entry in the Attribute Table to confirm this.

Will changing
"Multiple Egress-VLAN-Name attributes can be delivered in an
authentication response..."
to
"The RADIUS server can return multiple Egress-VLAN-Name attributes in an
Access-Accept or CoA-Request packet..."
address this issue?

>=20
> Section 2.4:
>=20
> There is no material on permitted usage of the=20
> User-Priority-Table attribute.

Will adding the following sentence address this issue?

The RADIUS server MAY only send a single User-Priority-Table attribute
within an Access-Accept or COA-Request; this attribute MUST NOT be sent
within an Access-Request, Access-Challenge, Access-Reject, or
Disconnect-Request.

Cheers,
MS

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 01:13:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 102 in ieee802-01
Date: Wed, 1 Feb 2006 17:12:11 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Ok.

MS=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Tuesday, January 31, 2006 11:47 PM
> To: Sanchez, Mauricio (PNB Roseville); [email-masked]
> Subject: RE: Issue 102 in ieee802-01
>=20
> Hi Mauricio,
>=20
> Yes, that looks OK -- but the definition of TEXTDATA also=20
> needs to be aligned (it shouldn't include "%"). My proposal:
>=20
>   TEXTDATA       =3D  %x20-21 / %x23-24 / %x26-7E=20
>=20
> (In other words, exclude double quote '"' and percent sign '%')
>=20
> Best regards,
> Pasi
>=20
> > -----Original Message-----
> > From: Sanchez, Mauricio (PNB Roseville)
> > Sent: 31 January, 2006 20:52
> > To: [email-masked]
> > Subject: RE: Issue 102 in ieee802-01
> >=20
> >=20
> > Pasi,
> >=20
> > Would the following 'tunnel-id' syntax definition cover=20
> your concerns?
> >=20
> >    tunnel-id      =3D  DQUOTE 1*(TEXTDATA /("%" 2HEXDIG)) DQUOTE
> >=20
> > Thanks,
> > MS
> >=20
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of=20
> > > [email-masked]
> > > Sent: Wednesday, January 25, 2006 2:52 AM
> > > To: [email-masked]
> > > Subject: Issue 102 in ieee802-01
> > >=20
> > > Hi,
> > >=20
> > > It looks like version -01 of the IEEE attributes draft=20
> solved my of=20
> > > my comments, but one resolution looks slightly buggy:
> > >=20
> > > The ABNF includes two different ways to quoting "strange"=20
> > > octets in tunnel-id (backslashes and percent-hex-hex),=20
> but the text=20
> > > doesn't quite match the ABNF.
> > >=20
> > > Also, I think we don't need two different quoting mechanisms; the=20
> > > percent-hex-hex notation makes the backslashes redundant (and is=20
> > > IMHO easier to implement in a way that really works with=20
> arbitrary=20
> > > octets, such as LF (the rule delimeter!) and NUL).
> > >=20
> > > Best regards,
> > > Pasi
> > >=20
> > > --
> > > to unsubscribe send a message to
> > > [email-masked] with the word 'unsubscribe' in a=20
> > > single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> > >=20
> >=20
> > --
> > to unsubscribe send a message to=20
> [email-masked] with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 00:50:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 111: Accounting
Date: Wed, 1 Feb 2006 16:50:03 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard noted a while back...=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, November 13, 2005 10:17 PM
> To: [email-masked]
> Subject: Re: Issue 111: Accounting
>=20
> Here is what RFC 2866 says about the notion of an Accounting Session:
>=20
<...removed what RFC2866 says about accounting...>
>=20
> As Greg noted, the Service-Type is not being changed here, so=20
> that the Service is continuing, and sending of additional=20
> Start/Stop messages is somewhat odd.  Also, do we really want=20
> individual RADIUS attributes to provide their own definitions=20
> of when a new session is started and stopped? =20
> RADIUS accounting is a separate protocol from RADIUS=20
> authentication, and runs on a separate port.  Authentication=20
> attributes that affect accounting (Class,=20
> Acct-Interim-Interval) have to date been general ones. =20
> Terminating the Accounting Session in mid-stream could cause=20
> issues with RADIUS implementations that use the Accounting=20
> Records for things like simultaneous usage control.
>=20
> Paul Congdon said:
>=20
> At IETF-64 we reviewed this issue.  There did not seem to be=20
> any objection to having compliance statements in the Annex=20
> given that this Annex is where the context for the statements=20
> is developed.  Also, since a new session is created, as=20
> stated in the draft, there is no need to use INTERM messages.
>=20
> --------------------------------------------------------------
> -------------------
> Issue 111: Accounting
> Submitter name: Greg Weber
> Submitter email address: [email-masked] Date first=20
> submitted: August 10, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html
> Document: IEEE802-00
> Comment type: T
> Priority: S
> Section: A.3
> Rationale/Explanation of issue:
>=20
> The accounting requirements do not seem to be fully treated=20
> by the draft.  Section A.3 has a MUST requirement related to=20
> accounting.  I would think that MUST requirements should be=20
> treated by the text, not in an appendix.  Why does=20
> redirection require a STOP/START pair?  Can't this=20
> information be conveyed via an INTERIM record for the same=20
> session?  If the Service- Type is not changing, I'd think=20
> that an INTERIM would suffice.

In light that the treatment of accounting behavior would be best treated
elsewhere, such as in 3576bis, I would suggest that we omit any
discussion of accounting behavior in this draft.  This means that
sections 1.4 would be modified and section A.3 would be eliminated to
remove accounting references.=20

Does this seem like a reasonable path?

Cheers,
MS
=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 02 Feb 2006 00:42:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Allowed Usage
Date: Wed, 1 Feb 2006 19:41:41 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Also, the textual description of Ingress-Filters says=20
that it MUST NOT be included in Disconnect-Request
messages (and some other types of messages).  This is=20
not reflected in the Table of Attributes in Section 4
which may be confusing.  Would any of these attributes
be used in Disconnect-Request messages?  I'd guess not,
except maybe a flush rule...  :)

Greg

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, January 29, 2006 3:07 PM
> To: [email-masked]
> Subject: Issue: Allowed Usage
>=20
> Issue : Allowed Usage
> Submitter names: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: January 29, 2006
> Reference:
> Document: IEEE 802-01
> Comment type: 'T'echnical |
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>=20
> In Section 4, the Table of Attributes states the following:
>=20
>       The following table provides a guide to which attributes may be
>       found in which kinds of packets, and in what quantity.
>=20
>       Access- Access- Access- Access-   CoA-
>       Request Accept  Reject  Challenge Req  #   Attribute
>       0       0+      0       0         0+   TBD Egress-VLANID
>       0       0-1     0       0         0-1  TBD Ingress-Filters
>       0       0-1     0       0         0-1  TBD User-Priority-Table
>=20
> The Egress-VLAN-Name attribute is not included in this table, nor is
> it included in the IANA considerations section.
>=20
> Section 2.1:
>=20
>          Multiple Egress-VLANID attributes can be delivered in an
>          authentication response; each attribute adds the=20
> specified VLAN
>          to the list of allowed egress VLANs for the port.
>=20
> This would appear to indicate that the Egress-VLAN-Name attribute is
> allowed in Access-Challenge, Access-Reject and Access-Accept packets.
> Yet, the attribute table in Section 4 does not seem to permit
> inclusion in Reject or Challenge packets.
>=20
> Section 2.3:
>=20
>          Multiple Egress-VLAN-Name attributes can be delivered in an
>          authentication response; each attribute adds the=20
> named VLAN to
>          the list of allowed egress VLANs for the port.
>=20
> This would appear to indicate that the Egress-VLAN-Name attribute is
> allowed in Access-Challenge, Access-Reject and Access-Accept packets.
> There is no entry in the Attribute Table to confirm this.
>=20
> Section 2.4:
>=20
> There is no material on permitted usage of the User-Priority-Table=20
> attribute.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 01 Feb 2006 19:32:19 +0000
Content-class: urn:content-classes:message
Subject: RE: review of draft-ietf-radext-ieee802-01.txt
Date: Wed, 1 Feb 2006 14:32:32 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, January 28, 2006 1:57 PM
> To: [email-masked]
> Subject: RE: review of draft-ietf-radext-ieee802-01.txt
>=20
> David Nelson writes:
>=20
> >Given the ongoing work on RADIUS Design Guidelines to=20
> encompass additional=20
> >data types and foster greater compatibility with Diameter=20
> AVPs, and the=20
> >charter of the DIME WG, it is not inconceivable to come up=20
> with a single=20
> >"improved" filter
> >rule that would make RADIUS-Diameter attribute translation=20
> much easier.
> >It would, however, in all likelihood delay this work for many months.
> >It seems to me we have to decide which we value more highly: a [more]
> >unified data model between RADIUS and Diameter or timely=20
> delivery of the=20
> >802-related extensions in RADIUS.
>=20
> I'm not sure we have to choose.  We can split the document,=20
> removing the=20
> filter attributes and progressing the rest.  From what I can=20
> see, there are=20
> no open issues relating to the VLAN/Priority attributes, so=20
> doing that could=20
> enable the VLAN/Priority document to be sent to the IESG
> for review by IETF 65.

That sounds like a good idea to me.  It also nicely
resolves issue #110.

Greg

> Unless we think that we can resolve the Diameter and Design=20
> Guidelines=20
> issues by the submission deadline for IETF 65, I  don't see=20
> what other paths=20
> are available to completing this milestone in a timely way.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 01 Feb 2006 19:28:42 +0000
Content-class: urn:content-classes:message
Subject: [Issue] Editorial cmts on IEEE802-01
Date: Wed, 1 Feb 2006 14:28:01 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Editorial cmts on IEEE802-01
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: February 1st, 2006
Reference: NA
Document: IEEE802-01
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: Various
Rationale/Explanation of issue and requested changes:

Section 1.1 "Authenticator"
  "an entity that require" -> "an entity that requires"
Section 2.2 "Description"
  "IEEE 802.1Q" -> "[IEEE8021Q]"
Section 2.3 "Description"=20
  Please use either "VLAN ID" or "VLAN-ID" consistently.
Section 2.3 "String"
  Should "802.1Q-2003" be "[IEEE8021Q]" or is this a new
  reference?  The latter reference is dated January 1998=20
  in Section 7.1.
Section 2.5 "Description"
  "NAS-Filter-Rule process packets" ->
  "NAS-Filter-Rule processes packets"
Section 2.5 "Description"
  There is a reference for HTTP, but not HTTPS.
Section 2.5 "Description"
  "...if multiple NAS-Filter-Rule attributes are contained=20
   within an Access-Request or Access-Accept..." ->
  "...if multiple NAS-Filter-Rule attributes are contained
   within an Access-Accept or CoA-Request..."
Section 2.5 "Description"
  "flush rules" are mentioned a dozen paragraphs into=20
  the section, but they're not explained until way down
  in the Text section.  Shouldn't they be added as a
  type of rule in the Table after the second paragraph?
Section 2.5 "Text" "ipv6-address"
  "match the rule" -> "match the rule."
Section 2.5 "Text" "tcp-port"
  The text says this field can be used with UDP and SCTP
  in addition to TCP, so is it supposed to be called "port"?
Section 2.5 "Text" "tcpoptions"
  Do you want Informative references for RFCs 1323 & 1644?
Section 2.5 "Text" "redir_cnt"
  "redir_cnt   Specifies" -> "redir_cnt  Specifies"=20
Section 3.1 "String"
  "specify which filter rule the counter value is for." ->
  "specify for which filter rule the couter is a value."
Section 5
  "Allocation of seven updates..." ->
  "Allocation of five updates..."
Section 6
  "nabled networks" -> "enabled networks"
  "in message it sends." -> "in messages it sends."
Section A.1.2
  "(eg.  Mobile-IP)" -> "(e.g. Mobile-IP)"
Section A.1.4
  "and in both directions" ->
  "Flow in a tunnel in two directions"
Section A.1.4
  "and an NAS-Filter-Rule" -> "and a NAS-Filter-Rule"
  "packet(as" -> "packet (as"
Section A.2
  "the users browser" -> "the user's browser"
Section A.2.1
  "the RADIUS MAY" -> "the RADIUS server MAY"
Section A.2.2
  "CoA message" -> "CoA-Request message" (several occurrences)
Section A.2.3
  "The RADIUS serve can" -> "The RADIUS server can"
  "in two way." -> "in two ways."
Section A.4
  "IEEE 8021X environment" -> "IEEE 802.1X environment"
  "their hotel room" -> "her hotel room"
  "WiFi is" -> "WiFi and is"
Section B Examples #7 & #8
  Replace "foo.org" and "goo.org" with domains from RFC 2606.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 01 Feb 2006 08:06:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 102 in ieee802-01
Date: Wed, 1 Feb 2006 09:46:55 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Mauricio,

Yes, that looks OK -- but the definition of TEXTDATA also
needs to be aligned (it shouldn't include "%"). My proposal:

  TEXTDATA       =3D  %x20-21 / %x23-24 / %x26-7E=20

(In other words, exclude double quote '"' and percent sign '%')

Best regards,
Pasi

> -----Original Message-----
> From: Sanchez, Mauricio (PNB Roseville)
> Sent: 31 January, 2006 20:52
> To: [email-masked]
> Subject: RE: Issue 102 in ieee802-01
>=20
>=20
> Pasi,
>=20
> Would the following 'tunnel-id' syntax definition cover your concerns?
>=20
>    tunnel-id      =3D  DQUOTE 1*(TEXTDATA /("%" 2HEXDIG)) DQUOTE
>=20
> Thanks,
> MS=20
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of=20
> > [email-masked]
> > Sent: Wednesday, January 25, 2006 2:52 AM
> > To: [email-masked]
> > Subject: Issue 102 in ieee802-01
> >=20
> > Hi,
> >=20
> > It looks like version -01 of the IEEE attributes draft solved=20
> > my of my comments, but one resolution looks slightly buggy:
> >=20
> > The ABNF includes two different ways to quoting "strange"=20
> > octets in tunnel-id (backslashes and percent-hex-hex), but=20
> > the text doesn't quite match the ABNF.
> >=20
> > Also, I think we don't need two different quoting mechanisms;=20
> > the percent-hex-hex notation makes the backslashes redundant=20
> > (and is IMHO easier to implement in a way that really works=20
> > with arbitrary octets, such as LF (the rule delimeter!) and NUL).
> >=20
> > Best regards,
> > Pasi
> >=20
> > --
> > to unsubscribe send a message to=20
> > [email-masked] with the word 'unsubscribe' in=20
> > a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>