Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 31 Aug 2005 13:03:00 -0400

"Avi Lior" <[email-masked]> wrote:
> There is a difference because unexptected seems to tie the Challenge to
> the authentication method which is not true.

  PAP & CHAP don't currently use Access-Challenge, which is why I used
the term "unexpected".  The same NAS may support Access-Challenge for one authentication protocol, but not another.

  But "unsupported" is the more correct term.

> My understanding is a Challenge is an indication that the Server
> requires more information.

  Yes.  That makes it the ideal place to put capabilities exchange.

  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: Wed, 31 Aug 2005 10:08:48 +0000
Date: Wed, 31 Aug 2005 13:08:27 +0300
From: Miguel Garcia <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Issue 126: Unresolved NITs

Bernard Aboba wrote:

>
> References
> 
> [I-D.ietf-aaa-diameter-sip-app] is not referenced in the document (except 
>                                 in the change list)

This is actually referred to in Section 1.2.

/Miguel

--
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
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, 31 Aug 2005 09:49:28 +0000
Date: Wed, 31 Aug 2005 12:49:08 +0300
From: Miguel Garcia <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Review of DIGEST-04 document

I checked issues 124 and 125 and they are properly addressed in this new 
version.

/Miguel

Bernard Aboba wrote:

> A new version of the RADIUS Digest Authentication document is now 
> available for inspection:
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-04.txt
> 
> When it shows up on the IETF archive, it will be available here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-04.txt
> 
> Please check the specification over carefully.  If you have submitted an 
> issue, please post mail to the RADEXT WG mailing list indicating whether 
> your issue has been resolved.  
> 
> We are asking that RADEXT WG participants complete their final review by 
> Friday, September 9, 2005. 
> 
> --
> 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/>
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
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, 31 Aug 2005 08:51:43 +0000
Date: Wed, 31 Aug 2005 01:50:52 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 126: Unresolved NITs

Issue 126: Unresolved NITs
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 29, 2005
Reference: 
Document: DIGEST-04
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 4.4:

possesion -> possession

Section 4.14:

ie -> i.e.

Section 5:

Change:

TBD  User-Name 
TBD  Message-Authenticator 

To:

1  User-Name 
80 Message-Authenticator

References

[I-D.ietf-aaa-diameter-sip-app] is not referenced in the document (except 
                                in the change list)

[RFC2616] is not referenced.

[RFC1750] is not referenced.

--
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, 30 Aug 2005 23:59:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of DIGEST-04 document
Date: Tue, 30 Aug 2005 16:59:09 -0700
From: "Mahendran, AC" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Wolfgang, thanks for uploading the -04 version.

Bernard, as you already know, 3GPP2 is waiting on this draft for the
publication of BCMCS specification (X.S0022). I would greatly appreciate
if we can progress this draft at the earliest.=20

Thanks for your support.

Thanks,
-AC
3GPP2-IETF liaison

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, August 30, 2005 8:39 AM
To: [email-masked]
Subject: Review of DIGEST-04 document

A new version of the RADIUS Digest Authentication document is now=20
available for inspection:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-04.tx
t

When it shows up on the IETF archive, it will be available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-04.txt

Please check the specification over carefully.  If you have submitted an

issue, please post mail to the RADEXT WG mailing list indicating whether

your issue has been resolved. =20

We are asking that RADEXT WG participants complete their final review by

Friday, September 9, 2005.=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/>

--
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, 30 Aug 2005 22:28:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-zorn-radius-keywrap-07.txt
Date: Tue, 30 Aug 2005 15:28:20 -0700
From: "Pat Calhoun \(pacalhou\)" <[email-masked]>
To: "Radius Ext Mailing List" <[email-masked]>

>> >> In speaking with Russ Housely on the key-wrap issues, Russ
indicated
>> >> that it would need to be on an end-to-end basis.
>>=20
>> Except that that's not how RADIUS works...
>
>Right.  RADIUS security is between a RADIUS client and server.  There
are=20
>no other entities involved.=20

Correct. Further, while proxies exist in the RADIUS world, and are
mentioned in various drafts, clearly fixing how proxies should work,
from transport to security, is a much bigger work item, and one that I
would caution the WG to embark on. I believe that for customers that
have interest in secure, reliable proxies, then the work in AAA should
be used instead.

I'd like to thank Bernard on his excellent review and comments. I am
encouraged to see that he is positive on the work in progress - this is
goodness to the Internet Community, who really needs a more secure key
delivery mechanism in RADIUS, while minimizing impact on backward
compatibility.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

--
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, 30 Aug 2005 15:39:41 +0000
Date: Tue, 30 Aug 2005 08:39:10 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Review of DIGEST-04 document

A new version of the RADIUS Digest Authentication document is now 
available for inspection:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-04.txt

When it shows up on the IETF archive, it will be available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-04.txt

Please check the specification over carefully.  If you have submitted an 
issue, please post mail to the RADEXT WG mailing list indicating whether 
your issue has been resolved.  

We are asking that RADEXT WG participants complete their final review by 
Friday, September 9, 2005. 

--
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, 30 Aug 2005 15:30:59 +0000
Date: Tue, 30 Aug 2005 08:30:46 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt 

> A simple solution would be that a NAS that knows both the NAS and 
> user location always sends both (when sending location information).
> 
> (I don't think we need more fine-grained capability negotiation 
> for this.)

I agree that this would work and also agree that capability negotiation is 
not needed.  However, I thought that the idea was not to send any location 
data by default. 

--
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, 30 Aug 2005 15:29:50 +0000
Date: Tue, 30 Aug 2005 08:29:32 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: John Schnizlein <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt 

> The inclusion of the "entity" field reintroduces the problem we had with the
> initial draft, which is that no practical mechanism has been identified
> through which the NAS would know the location of the host attempting
> attachment.

Existing access points support user location determination, right?
See:
http://www.networkworld.com/news/2005/050505-cisco-airespace.html
http://www.arubanetworks.com/pdf/rf-location.pdf

--
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, 30 Aug 2005 15:10:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 123/124 Radius Digest requirement to clients
Date: Tue, 30 Aug 2005 11:10:16 -0400
From: "Nelson, David" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

I think the proposed language is acceptable.

In reading it, I noticed that the draft does not appear to discuss
RADIUS Proxy Servers.  It talks about HTTP Proxy Servers.

With regard to the normative requirements for nonce generation placed on
RADIUS Clients and RADIUS Severs, would it be useful to note that the
neither the RADIUS Client functionality with in a RADIUS Proxy Server,
nor the RADIUS Server functionality contained within a RADIUS Proxy
Server are ever expected to generate nonces?  That is to say, RADIUS
Proxy Servers perform no operation on the nonces other than
pass-through.=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, 30 Aug 2005 14:10:59 +0000
Content-class: urn:content-classes:message
Subject: RE: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Tue, 30 Aug 2005 10:10:40 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Pasi Eronen writes...

> This depends on what kind of NASes you're considering. In=20
> PSTN dial-up, determining the host location probably isn't=20
> feasible ...

It's probably more accurate to say that in PSTN dial-up it isn't always
possible to determine the host location accurately.   Technologies such
as ANI or Caller-ID provide that information.  For the traditional
land-line subscriber loop, it is very likely that the host is located
within the premises served by the subscriber loop.  This is almost
always the case with residential customers.  It will more often not be
the case with commercial customers, who may have centralized outgoing
trunk lines that can be accessed from a variety of locations.

--
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, 30 Aug 2005 13:56:07 +0000
Content-class: urn:content-classes:message
Subject: RE: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Tue, 30 Aug 2005 16:55:51 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

John Schnizlein wrote:
>=20
> The inclusion of the "entity" field reintroduces the problem
> we had with the initial draft, which is that no practical
> mechanism has been identified through which the NAS would know
> the location of the host attempting attachment.
>=20
> Rather than prolong the illusion, it would be better to
> eliminate this field and let the location attribute refer to
> the location of the NAS.

This depends on what kind of NASes you're considering. In PSTN
dial-up, determining the host location probably isn't feasible,
but there certainly are practical mechanisms for e.g. GSM/GPRS
and IEEE 802.11 networks. Although they're not necessarily that=20
widely used, I would not call them an "illusion"...

Best regards,
Pasi

--
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, 30 Aug 2005 13:47:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Tue, 30 Aug 2005 16:47:06 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Bernard Aboba wrote:

> > It looks like NAS could use this field to describe which location
> > it's sending, or send two Location-Information attributes if it=20
> > knows both.
>=20
> But the NAS isn't sending location by default.  So how does=20
> the RADIUS server that requires a given kind of location indicate=20
> what it needs? Keep in mind that if the RADIUS server REQUIRES=20
> location then it may need to send an Access-Reject.=20

A simple solution would be that a NAS that knows both the NAS and=20
user location always sends both (when sending location information).

(I don't think we need more fine-grained capability negotiation=20
for this.)

Best regards,
Pasi

--
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, 30 Aug 2005 13:43:15 +0000
Cc: [email-masked], [email-masked], [email-masked]
From: John Schnizlein <[email-masked]>
Subject: Re: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Tue, 30 Aug 2005 09:42:45 -0400
To: Bernard Aboba <[email-masked]>

The inclusion of the "entity" field reintroduces the problem we had 
with the initial draft, which is that no practical mechanism has been 
identified through which the NAS would know the location of the host 
attempting attachment.

Rather than prolong the illusion, it would be better to eliminate this 
field and let the location attribute refer to the location of the NAS.

John

On Aug 30, 2005, at 9:11 AM, Bernard Aboba wrote:

>> Are you sure? The Location-Information attribute includes a field
>> called "Entity", described as follows
>>
>>    Entity (8 bits):
>>      Describes which location this attribute refers to:
>>      (0) describes the location of the user's client device
>>      (1) describes the location of the AAA client
>>
>> It looks like NAS could use this field to describe which location
>> it's sending, or send two Location-Information attributes if it
>> knows both.
>
> But the NAS isn't sending location by default.  So how does the RADIUS
> server that requires a given kind of location indicate what it needs? 
> Keep
> in mind that if the RADIUS server REQUIRES location then it may need to
> send an Access-Reject.
>

--
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, 30 Aug 2005 13:12:03 +0000
Date: Tue, 30 Aug 2005 06:11:49 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt 

> Are you sure? The Location-Information attribute includes a field
> called "Entity", described as follows
> 
>    Entity (8 bits):
>      Describes which location this attribute refers to:
>      (0) describes the location of the user's client device
>      (1) describes the location of the AAA client
> 
> It looks like NAS could use this field to describe which location
> it's sending, or send two Location-Information attributes if it 
> knows both.

But the NAS isn't sending location by default.  So how does the RADIUS 
server that requires a given kind of location indicate what it needs? Keep 
in mind that if the RADIUS server REQUIRES location then it may need to 
send an Access-Reject. 

--
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, 30 Aug 2005 12:38:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Tue, 30 Aug 2005 15:37:11 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba wrote:

> The "server-driven" approach also provides a mechanism to=20
> address RADEXT Issue 27 (Who's Location).=20
>=20
> One of the major problems with the RADIUS-GEOPRIV document is that=20
> it does not support user location determination, only  NAS location.=20

Are you sure? The Location-Information attribute includes a field
called "Entity", described as follows

   Entity (8 bits):
     Describes which location this attribute refers to:
     (0) describes the location of the user's client device
     (1) describes the location of the AAA client

It looks like NAS could use this field to describe which location
it's sending, or send two Location-Information attributes if it=20
knows both.

Best regards,
Pasi

--
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, 29 Aug 2005 23:54:33 +0000
Date: Mon, 29 Aug 2005 16:53:45 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: RE: Review of draft-zorn-radius-keywrap-07.txt

> >> In speaking with Russ Housely on the key-wrap issues, Russ indicated
> >> that it would need to be on an end-to-end basis.
> 
> Except that that's not how RADIUS works...

Right.  RADIUS security is between a RADIUS client and server.  There are 
no other entities involved. 

> Under that interpretation, though, 
> I don't think that Kerberos would satisfy the criteria, either: a 
> Kerberos server has knowledge of lots of keys that are used by various 
> parties to protect things that are none of the server's business 
> (e.g., telnet data).  With Kerberos, we get around that little problem 
> by declaring the Kerberos server to be unconditionally trusted.

Right.  It seems to me that the criteria may be too strict.  I'm not sure 
why a Kerberos server can be "unconditionally trusted" but a RADIUS server 
would not be. 

--
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, 29 Aug 2005 23:01:01 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-zorn-radius-keywrap-07.txt
Date: Mon, 29 Aug 2005 16:00:24 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled:

>> There was a discussion at IETF-63 of whether the key-wrap in the Zorn
>> draft was hop-by-hop or end-to-end.  The answer was that it could be
>> either. The RADEXT session minutes read: "They are passed along the
>> path in the way they are set-up - may be hop-by-hop."
>>=20
>> In speaking with Russ Housely on the key-wrap issues, Russ indicated
>> that it would need to be on an end-to-end basis.

Except that that's not how RADIUS works...

>>=20
>> BTW, the hop-by-hop key-wrap is also an issue with the key-wrap
>> attributes in the Aboba draft.
>=20
> Right.  Russ Housley has indicated that he will work with Sam Hartman
> to=20
> provide a clear statement of requirements.
>=20
> End-to-end key management support has been something of a "holy
> grail" with the AAA community -- many attempts to find it, but little
> in the way of documented success. =20
>=20
> AAA WG worked on Diameter CMS for several years before giving up, and
> adopting support for Redirect within Diameter EAP (RFC 4072).=20
> However, I don't believe that it would be viable to retrofit Redirect
> functionality within RADIUS.=20

I don't think it would be useful, either, in the absence of the elusive =
"ubiquitous PKI".

>=20
> IN terms of other alternatives, there was a Kerberos proposal a while
> back:
> http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt
>=20
> There is also work ongoing within Terena on a DNSSEC-based approach:
> http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf
> http://www.lab.telin.nl/~arjan/pub/radius-dnssec.pdf

Unfortunately, the solution proposed by Terena doesn't appear to satisfy =
the "Housley Criteria" either -- the number of parties that "have access =
to keying material that is not needed to perform their own role" is =
reduced but not eliminated (presupposing that one interprets the =
appropriate role of key-holders as being just to apply security to (for =
example) the 802.11 traffic).  Under that interpretation, though, I =
don't think that Kerberos would satisfy the criteria, either: a Kerberos =
server has knowledge of lots of keys that are used by various parties =
for to protect things that are none of the server's business (e.g., =
telnet data).  With Kerberos, we get around that little problem by =
declaring the Kerberos server to be unconditionally trusted.

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, 29 Aug 2005 20:49:06 +0000
Date: Mon, 29 Aug 2005 13:48:03 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Review of draft-zorn-radius-keywrap-07.txt

> There was a discussion at IETF-63 of whether the key-wrap in the Zorn
> draft was hop-by-hop or end-to-end.  The answer was that it could be 
> either. The RADEXT session minutes read: "They are passed along the path
> in the way they are set-up - may be hop-by-hop."
> 
> In speaking with Russ Housely on the key-wrap issues, Russ indicated
> that it would need to be on an end-to-end basis.
> 
> BTW, the hop-by-hop key-wrap is also an issue with the key-wrap
> attributes in the Aboba draft.
  
Right.  Russ Housley has indicated that he will work with Sam Hartman to    
provide a clear statement of requirements. 

End-to-end key management support has been something of a 
"holy grail" with the AAA community -- many attempts to find it, but
little in the way of documented success.
  
AAA WG worked on Diameter CMS for several years before giving
up, and adopting support for Redirect within Diameter EAP (RFC 4072).  
However, I don't believe that it would be viable to retrofit Redirect 
functionality within RADIUS. 

IN terms of other alternatives, there was a Kerberos proposal a while 
back:
http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt

There is also work ongoing within Terena on a DNSSEC-based approach:
http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf
http://www.lab.telin.nl/~arjan/pub/radius-dnssec.pdf

--
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, 29 Aug 2005 18:16:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-zorn-radius-keywrap-07.txt
Date: Mon, 29 Aug 2005 14:15:01 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> Just like existing RADIUS shared secrets, the KEK and MAC Key are
> hop-by-hop secrets.

It seems to me that hop-by-hop protection of encryption keys potentially
violates the following requirement of the Housely Criteria:

     Limit key scope

         Follow the principle of least privilege.  Parties MUST NOT have
         access to keying material that is not needed to perform their
         own role.  A party has access to a particular key if it has
         access to all of the secret information needed to derive it.

And possibly this requirement, as well:

     Authenticate all parties

         Each party in the AAA key management protocol MUST be
         authenticated to the other parties with whom it communicates.
         Authentication mechanisms MUST maintain the confidentiality of
         any secret values used in the authentication process.

There was a discussion at IETF-63 of whether the key-wrap in the Zorn
draft was hop-by-hop or end-to-end.  The answer was that it could be
either. The RADEXT session minutes read: "They are passed along the path
in the way they are set-up - may be hop-by-hop."

In speaking with Russ Housely on the key-wrap issues, Russ indicated
that it would need to be on an end-to-end basis.

BTW, the hop-by-hop key-wrap is also an issue with the key-wrap
attributes in the Aboba draft.

--
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, 29 Aug 2005 08:31:39 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Issue 123/124 Radius Digest requirement to clients
Date: Mon, 29 Aug 2005 10:31:12 +0200

Proposal:

Section 1.3 Overview
[..]
   The nonces required by the digest algorithm are either generated by
   the RADIUS client or by the RADIUS server.  A mix of nonce generation
   modes is not supported.  This specification assumes that both the
   RADIUS client and server are appropriately configured to generate the
   nonces in either the RADIUS client or the RADIUS server, but not in
   both at the same time.  Implementations, though, do not have the
   means to verify this behavior.

New Section 2:
2.  Interoperability

   An implementation supporting this extension MUST include a Digest-
   Response attribute within an Access-Request packet where Digest
   Authentication is desired.  An Access-Request MUST NOT contain both a
   Digest-Response attribute and another authentication attribute, such
   as User-Password, CHAP-Password, or EAP-Message.

   RADIUS clients and servers MUST support both nonce generation modes.
   As there is no automatic capability exchange, the operator MUST make
   sure that the RADIUS client software uses the correct nonce
   generation mode when accessing a specific RADIUS server:
   o  If the RADIUS server generates nonces, its RADIUS clients MUST NOT
      try to generate nonces.
   o  If the RADIUS server does not generate nonces, its RADIUS clients
      MUST generate nonces locally.
   o  If at least one HTTP-style client requires AKA authentication
      [RFC3310], the RADIUS server MUST generate nonces and its RADIUS
      clients MUST NOT generate nonces locally.
   RADIUS implementations MUST offer respective configuration options.

(Section 2 removes also normative language from the overview section)

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: Sun, 28 Aug 2005 07:32:11 +0000
Date: Sun, 28 Aug 2005 00:31:33 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Review of draft-zorn-radius-keywrap-07.txt

Having looked at draft-zorn-radius-keywrap-07.txt, in general I think 
that the proposal is quite ingenious. 

If it I understand it correctly, the proposal addresses many of the 
weaknesses of MD5 usage in RADIUS while still enabling support for 
backward compatibility.  It can therefore be introduced on a NAS and 
RADIUS server without requiring changes to RADIUS proxies, or
on a RADIUS server but not all NAS devices.  Of course, to address all the 
MD5 vulnerabilities all RADIUS clients and servers need to be upgraded 
eventually, but the transition can be graceful. 

However, since I may not fully grasp the proposal, I thought I'd summarize 
the main aspects as I understand it:

a.  If I read the document correctly, it is possible for an implementation 
to compute all the Request and Response authenticators based on a RADIUS 
shared secret, *exactly* as it is done today.  As a result, the proposal 
is compatible with legacy RADIUS proxies and servers. 

In addition to a legacy shared secret, the proposal also creates 
additional shared secrets, namely the Key Encryption Key (KEK) and the MAC 
Key.   These additional shared secrets are presumably independent of the 
RADIUS shared secret so that if the RADIUS shared secret is compromised, 
an attacker will still be unable to forge messages or decrypt the wrapped 
key. 

Just like existing RADIUS shared secrets, the KEK and MAC Key are 
hop-by-hop secrets.  

b. The document also includes definition of a new 
Message-Authentication-Code attribute, which is a MAC calculated over the 
RADIUS packet in a manner similar to the existing
Message-Authenticator attribute, albeit using the new MAC key and more 
secure MAC algorithms, such as HMAC-SHA-1 and HMAC-SHA-256.

To maintain backward compatibility, this attribute can be added to a 
RADIUS packet in addition to the existing Message-Authenticator attribute, 
which is required by RFC 3579 and the Digest Authentication document.  A 
RADIUS server can tell whether a RADIUS client supports this new 
attribute by the presence of the attribute  in an Access-Request, so that 
a server need not send the attribute to a RADIUS client that does not 
support it. 

Since the RADIUS client can compute *both* the Message-Authenticator and 
the new Message-Authentication-Code attribute, it need not worry about 
whether the RADIUS server supports the new attribute or not;  it can just 
send both attributes. 

c.  The document includes definition of a Random-Nonce attribute, which 
among other things can be used to address the replay protection problems 
that exist in Accounting-Request, CoA-Request and Disconnect-Request messsages.  
Since these messages do not include a Nonce in the Request Authenticator 
field, in existing usage there is a danger of replay.  While the issue is 
handled for Accounting-Request messages by checking for duplication of 
Acct-Session-ID values in the billing engine, RFC 3576 relies on
inclusion of the Event-Timestamp attribute in CoA-Request and 
Disconnect-Request messages.  This requires RADIUS clients and servers to 
implement time synchronization, which may be inconvenient.  As a result, 
it seems to me that the Random-Nonce attribute has general utility. 

However, on reading the proposal, I did have some questions:

d. If the KEK and MAC Key are hop-by-hop secrets, are they similar to the 
existing RADIUS shared secret in that there can only be one secret between 
a given (client IP address, server IP address) pair?  If so, then I don't 
understand the need for the MAC Key ID field in the Message-Authentication-Code
attribute, or the Key-ID, KEK-ID and App-ID fields in the Key attribute.  
After all, the existing RADIUS shared secret does not need a key name 
because this is implicit in the source and destination addresses within 
the RADIUS packet. 

e. As described in IEEE 802.11i and the EAP Key Framework document, the 
lifetime of EAP keying material is determined by the Session-Time 
attribute.  As a result, what is the purpose of the Lifetime field within 
the Key attribute?  

f. Since it is possible to mount an offline dictionary attack on the KEK 
and MAC Key just as with the existing RADIUS shared secret, presumably the 
KEK and MAC Key are not derived from a passphrase and users need to take 
care to maintain proper hygene (e.g. keys should be unique for each RADIUS 
client/server pair, minimum entropy is required. etc.), 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: Sun, 28 Aug 2005 04:11:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-lior-radext-end-to-end-caps-01.txt
Date: Sun, 28 Aug 2005 00:12:07 -0400
From: "Avi Lior" <[email-masked]>
To: "Majdi Badarin" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5AB86.A7597EEE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Majdi
=20
Thanx for the comments please see inline.

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Majdi Badarin
	Sent: Saturday, August 27, 2005 5:51 PM
	To: [email-masked]
	Subject: Review of draft-lior-radext-end-to-end-caps-01.txt
=09
=09
	I object to taking on the End-to-End Capabilities document as a
RADEXT WG=20
	work item. The document doesn't properly define the problem and
the proposed solution =20
	is excessively complex and is not compatible with existing
mechanisms in Diameter.=20
	=20

	[Avi] The problem statement was discussed over the list and
presented at IETF.  As well there are some drafts that have
indepementatly introduced a capability exchange.  This is an attempt to
try to get one consistant approach to solve the problem.

=09
	When adding new features, the RADEXT WG needs to try and
maintain the simplicity of=20
	RADIUS as I believe that this has accounted for much of its
success.  Questions=20
	like "is this feature necessary at all?"  And "can this feature
be done in a simple way?"=20
	should be answered first. =20

=09
	[Avi] I agree that RADIUS as a Dialup AAA server is simple.  But
RADIUS has been evolving.  The addition of EAP.  Support for dynamic
operations 3576.  The evolution of RADIUS is necessary as it is being
asked to be involved in more complex deployements.

	 RADIUS is a simple protocol, and has existed without capability
negotiation since its=20
	inception. A very good case has to be made for adding this
capability at this time,=20
	especially in the complex manner that's being proposed.   The
document does not=20
	make the case for the major changes it is proposing.  In fact,
many of the problems=20
	it defines do not exist and many of the features it attempts to
add duplicate existing=20
	RADIUS functionality. =20

	As a result, I believe that the WG should discard the End-to-End
Capabilities document,=20
	since its approach is so inherently complex and flawed that it
cannot be fixed by=20
	accepting the document as a WG work item. =20

	A couple of specific problems, in addition to the unconvincing
motivation are:=20

	* The alternative mechanisms for detecting RFC 3576 support,
something that=20
	is already handled in RFC 3576.=20
	[Avi] Very inefficiently.  We have to try to disconnect or
perform a change of authorization before we can learn that whether or
not a NAS supports 3576.  In deployments where you have millions of
subscribers the facilities provided by 3576 are not usable.  This is why
for example 3GPP2 developed a capbility exchange specifically for
determining whether a NAS support this capability or not,=20

	* The use of capabilities negotiation for optional attributes.
RADIUS implementations=20
	have handled optional attributes for years, so this is
unnecessary.
	[Avi] I dont think so.  A NAS will ignore attirbutes that it
does not support.  Therefore for example in prepaid, when the server
sends prepaid attributes to the NAS that are going to control the
session, if the NAS ignores the attributes the prepaid user will be
given unlimited access. =20

	* Retroactive changes to the behaviour of existing RADIUS
implementations.=20
	[Avi] As long as we maintain backwards compatibility then I
belive that we are okay.  With a capability exchange the Server can
detect that it is potentially dealing with an old NAS and apply its
policies accordingly.  Without a capability exchange we are blind.=20

	* Creation of a registry for Capability IDs, including
capabilities that don't=20
	exist in RADIUS RFCs. =20
	[Avi] We should only have a registry of capabilities that are
supported  by RFCs.

	 This will cause interoperability problems -=20
	RADIUS requires that VSAs be treated as optional so as to allow
interoperability=20
	between vendor implementations.=20
	[Avi] I think SDOs that define VSAs should use the same scheme
as proposed but they should maintian their own registry.=20

	* Incompatibility with the Diameter optional/mandatory attribute
marking. =20
	The document doesn't even have a Diameter compatibility section.

	[Avi] We can add something to this document and perhaps write a
Diameter version.  Diameter also suffers from this problem btw.
Diameter has serious problems which is to be expected for a new AAA
protocol.=20

	I can go on to list all the objections to this document, all the
unnecessarily=20
	functionality, the confused problem statement, etc.  But that is
hardly necessary;=20
	other participants in the WG have already stated those
objections during previous=20
	discussions, more eloquently than I can.  In fact, looking back
at previous=20
	RADEXT WG discussion which started in January 2005, it appears
that many of=20
	these issues were brought up before. Looking back at the
discussion, it appears=20
	that WG consensus previously existed to adopt an alternative
(simpler) approach. =20
	So why is it being brought back again?=20
	[Avi]  Because other works have required some of the approaches
taken here.  Look this document is a starting point.  Lets make this a
working group document and then we can shape it so that it makes sense.
But as you noted first and foremost we need a capability exchange
mechanism.  What we should debate is what it looks like.=20

	I have to wonder "How can this document even be considered as a
WG work item=20
	given the volume and seriousness of the criticisms that have
been leveled=20
	 against it?"=20
	=20
	[Avi] I wish you wouldnt missrepresent the wishes of the group.
At the last IETF there were no objections for having a capability
excange. =20

	 And how can the RADEXT WG be bringing to WG last call=20
	documents that have so many problems, such as the VLAN and
Filters draft?=20

	In its consideration of new WG items, the RADEXT WG seems to be
asking the=20
	wrong questions.  The right question isn't "Are there any
objections?"=20
	but rather "Is there WG consensus that this document is an
appropriate solution=20
	to a real problem, and are there a significant base of vendors
who consider this=20
	functionality necessary and who will implement it?"=20
	=20

------_=_NextPart_001_01C5AB86.A7597EEE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML dir=3Dltr><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D849324203-28082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Majdi</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D849324203-28082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D849324203-28082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanx for the comments please see=20
inline.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of </B>Majdi=20
  Badarin<BR><B>Sent:</B> Saturday, August 27, 2005 5:51 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Review of=20
  draft-lior-radext-end-to-end-caps-01.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT color=3D#000000>
  <P><FONT face=3DArial><FONT size=3D2>I object to taking on the =
End-to-End=20
  Capabilities document as a RADEXT WG <BR>work item. The document =
doesn&#8217;t=20
  properly define the problem and the proposed solution&nbsp; <BR>is =
excessively=20
  complex and is not compatible with existing mechanisms in=20
  Diameter.&nbsp;<BR><FONT color=3D#0000ff><SPAN=20
  class=3D849324203-28082005>&nbsp;</SPAN></FONT></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
  class=3D849324203-28082005></SPAN><SPAN=20
  class=3D849324203-28082005>[Avi]&nbsp;The&nbsp;problem statement was=20
  discussed&nbsp;over the&nbsp;list and presented&nbsp;at =
IETF.&nbsp;&nbsp;As=20
  well there are some drafts that have&nbsp;indepementatly =
introduced&nbsp;a=20
  capability exchange.&nbsp; This is an attempt to try to get one =
consistant=20
  approach to solve the problem.</SPAN></FONT></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
  class=3D849324203-28082005></SPAN></FONT></FONT></FONT><FONT =
face=3DArial=20
  size=3D2><BR>When adding new features, the RADEXT WG needs to try and =
maintain=20
  the simplicity of <BR>RADIUS as I believe that this has accounted for =
much of=20
  its success.&nbsp; Questions <BR>like &#8220;is this feature necessary =
at=20
  all?"&nbsp; And &#8220;can this feature be done in a simple =
way?&#8221; <BR>should be=20
  answered first.&nbsp; </FONT></P><FONT face=3DArial color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT>
  <P><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><BR><FONT face=3DArial><FONT =
size=3D2><SPAN=20
  class=3D849324203-28082005><FONT color=3D#0000ff>[Avi]&nbsp;I agree =
that RADIUS as=20
  a Dialup AAA server is simple.&nbsp; But RADIUS has been =
evolving.&nbsp; The=20
  addition of EAP.&nbsp; Support for dynamic operations 3576.&nbsp; The=20
  evolution of RADIUS is necessary as it is being asked to be involved =
in more=20
  complex deployements.</FONT></SPAN></FONT></FONT></P>
  <P><FONT><FONT face=3DArial><FONT size=3D2><SPAN=20
  class=3D849324203-28082005>&nbsp;</SPAN>RADIUS is a simple protocol, =
and has=20
  existed without capability negotiation since its <BR>inception.=20
  </FONT></FONT></FONT><FONT><FONT><FONT face=3DArial><FONT size=3D2>A =
very good=20
  case has to be made for adding this capability at this time, =
<BR>especially in=20
  the complex manner that&#8217;s being proposed.&nbsp;&nbsp; The =
document does not=20
  <BR>make the case for the major changes it is proposing.&nbsp; In =
fact, many=20
  of the problems <BR>it defines do not exist and many of the features =
it=20
  attempts to add duplicate existing <BR>RADIUS =
functionality.&nbsp;<SPAN=20
  class=3D849324203-28082005><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></FONT></FONT></P>
  <P><FONT face=3DArial size=3D2>As a result, I believe that the WG =
should discard=20
  the End-to-End Capabilities document, <BR>since its approach is so =
inherently=20
  complex and flawed that it cannot be fixed by <BR>accepting the =
document as a=20
  WG work item.&nbsp; </FONT></P>
  <P><FONT face=3DArial size=3D2>A couple of specific problems, in =
addition to the=20
  unconvincing motivation are: </FONT></P>
  <P><FONT face=3DArial><FONT size=3D2>* The alternative mechanisms for =
detecting=20
  RFC 3576 support, something that <BR>is already handled in RFC 3576. =
<BR><SPAN=20
  class=3D849324203-28082005><FONT color=3D#0000ff>[Avi]&nbsp;Very=20
  inefficiently.&nbsp; We have to try to disconnect&nbsp;or perform a =
change of=20
  authorization before&nbsp;we can learn that whether or not a NAS =
supports=20
  3576.&nbsp; In&nbsp;deployments where you have millions of=20
  subscribers&nbsp;the facilities provided by&nbsp;3576 are not =
usable.&nbsp;=20
  This is why for example 3GPP2 developed a capbility exchange=20
  specifically&nbsp;for determining whether a NAS support this =
capability or=20
  not,&nbsp;</FONT></SPAN></FONT></FONT></P>
  <P><FONT face=3DArial size=3D2>* The use of capabilities negotiation =
for optional=20
  attributes.&nbsp; RADIUS implementations <BR>have handled optional =
attributes=20
  for years, so this is unnecessary.<BR><SPAN =
class=3D849324203-28082005><FONT=20
  color=3D#0000ff>[Avi]&nbsp;I dont think so.&nbsp;&nbsp;A NAS will =
ignore=20
  attirbutes that it does not support.&nbsp; Therefore&nbsp;for example =
in=20
  prepaid,&nbsp;when the server sends prepaid attributes to the =
NAS&nbsp;that=20
  are&nbsp;going to control the session,&nbsp;if the NAS ignores=20
  the&nbsp;attributes the&nbsp;prepaid user will be given&nbsp;unlimited =

  access.&nbsp;</FONT></SPAN> </FONT></P>
  <P><FONT face=3DArial><FONT size=3D2>* Retroactive changes to the =
behaviour of=20
  existing RADIUS implementations. <BR><SPAN =
class=3D849324203-28082005><FONT=20
  color=3D#0000ff>[Avi]&nbsp;As&nbsp;long as we maintain backwards =
compatibility=20
  then I belive that we are okay.&nbsp;&nbsp;With a capability =
exchange&nbsp;the=20
  Server can detect that it&nbsp;is potentially dealing with an old NAS =
and=20
  apply its policies accordingly.&nbsp; Without a capability exchange we =
are=20
  blind.&nbsp;</FONT></SPAN></FONT></FONT></P>
  <P><FONT face=3DArial size=3D2>* Creation of a registry for Capability =
IDs,=20
  including capabilities that don't <BR>exist in RADIUS RFCs.&nbsp; =
<BR><SPAN=20
  class=3D849324203-28082005><FONT color=3D#0000ff>[Avi]&nbsp;We should =
only have a=20
  registry of capabilities that are supported&nbsp; by=20
  RFCs.</FONT></SPAN></FONT></P>
  <P><FONT><FONT face=3DArial><FONT size=3D2><SPAN=20
  class=3D849324203-28082005>&nbsp;</SPAN>This will cause =
interoperability=20
  problems - <BR>RADIUS requires that VSAs be treated as optional so as =
to allow=20
  interoperability <BR>between vendor implementations. <BR><SPAN=20
  class=3D849324203-28082005><FONT =
color=3D#0000ff>[Avi]&nbsp;I&nbsp;think SDOs that=20
  define VSAs&nbsp;should use the same scheme as proposed but they=20
  should&nbsp;maintian their own=20
  registry.</FONT></SPAN></FONT></FONT></FONT><FONT><FONT =
face=3DArial><FONT=20
  size=3D2><SPAN =
class=3D849324203-28082005>&nbsp;</SPAN></FONT></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2>* Incompatibility with the =
Diameter=20
  optional/mandatory attribute marking.&nbsp; <BR>The document doesn't =
even have=20
  a Diameter compatibility section. <BR><SPAN =
class=3D849324203-28082005><FONT=20
  color=3D#0000ff>[Avi]&nbsp;We can add something to this document and =
perhaps=20
  write a Diameter version.&nbsp; Diameter also suffers from this =
problem=20
  btw.&nbsp; Diameter&nbsp;has serious problems&nbsp;which is to&nbsp;be =

  expected for a new AAA protocol.&nbsp;</FONT></SPAN></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2>I can go on to list all the =
objections to=20
  this document, all the unnecessarily <BR>functionality, the confused =
problem=20
  statement, etc.&nbsp; But that is hardly necessary; <BR>other =
participants in=20
  the WG have already stated those objections during previous =
<BR>discussions,=20
  more eloquently than I can.&nbsp; In fact, looking back at previous =
<BR>RADEXT=20
  WG discussion which started in January 2005, it appears that many of =
<BR>these=20
  issues were brought up before. Looking back at the discussion, it =
appears=20
  <BR>that WG consensus previously existed to adopt an alternative =
(simpler)=20
  approach.&nbsp; <BR>So why is it being brought back again? <BR><SPAN=20
  class=3D849324203-28082005><FONT color=3D#0000ff>[Avi]&nbsp; Because =
other works=20
  have required some of the approaches taken here.&nbsp; Look this =
document is a=20
  starting point.&nbsp; Lets make this a working group document and then =
we can=20
  shape it so that it makes sense.&nbsp; But&nbsp;as you noted first and =

  foremost we need a capability exchange mechanism.&nbsp; What =
we&nbsp;should=20
  debate is what it looks like.</FONT></SPAN></FONT></FONT><FONT=20
  face=3DArial><FONT size=3D2><SPAN=20
  class=3D849324203-28082005>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2>I have to wonder "How can this =
document even=20
  be considered as a WG work item <BR>given the volume and seriousness =
of the=20
  criticisms that have been leveled <BR>&nbsp;against =
it?"&nbsp;<BR><SPAN=20
  class=3D849324203-28082005><FONT =
color=3D#0000ff>&nbsp;</FONT></SPAN><BR><SPAN=20
  class=3D849324203-28082005><FONT color=3D#0000ff>[Avi]&nbsp;I wish you =
wouldnt=20
  missrepresent the wishes of the group.&nbsp; </FONT></SPAN><SPAN=20
  class=3D849324203-28082005><FONT color=3D#0000ff>At the last IETF =
there were no=20
  objections for having a capability excange.&nbsp;=20
  </FONT></SPAN></FONT></FONT></P>
  <P><FONT face=3DArial size=3D2><SPAN =
class=3D849324203-28082005>&nbsp;</SPAN>And how=20
  can the RADEXT WG be bringing to WG last call <BR>documents that have =
so many=20
  problems, such as the VLAN and Filters draft? </FONT></P>
  <P><FONT face=3DArial><FONT size=3D2>In its consideration of new WG =
items, the=20
  RADEXT WG seems to be asking the <BR>wrong questions.&nbsp; The right =
question=20
  isn't "Are there any objections?" <BR>but rather "Is there WG =
consensus that=20
  this document is an appropriate solution <BR>to a real problem, and =
are there=20
  a significant base of vendors who consider this <BR>functionality =
necessary=20
  and who will implement it?"&nbsp;<BR><SPAN =
class=3D849324203-28082005><FONT=20
  =
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></P></FONT></DIV></BLOC=
KQUOTE></BODY></HTML>

------_=_NextPart_001_01C5AB86.A7597EEE--

--
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, 28 Aug 2005 03:40:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities negotiation problem statement
Date: Sat, 27 Aug 2005 23:40:33 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Bernard,

Please see inline...=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, August 27, 2005 7:27 AM
> To: [email-masked]
> Subject: RE: Capabilities negotiation problem statement
>=20
> > 3GPP2 for example use advertisement for:
> > Prepaid - Before we push down a Prepaid policy we need to=20
> know whether=20
> > the NAS supports that policy.  Otherwise the NAS will ignore the=20
> > policy and allow the session to continue. As you can see this is a=20
> > serious problem.
>=20
> This case sounds the same as the security issue with filter=20
> rules. That is, the RADIUS server needs to send an attribute=20
> that cannot be safely ignored by the NAS.=20
>=20
> > Dynamic Auth - we need to understand whether a NAS supports=20
> 3576 for=20
> > correct operation.
>=20
> RFC 3576 already specifies how a RADIUS server can determine=20
> if a NAS supports it.  Where the RADIUS client does not=20
> support RFC 3576, the server  will receive an ICMP port=20
> unreachable message in reply to a Disconnect or CoA-Request. =20
> If the proxy supports RFC 3576, but the NAS does not, then=20
> the proxy replies with an Error-Cause value of "Unsupported
> Extension":
>=20
>    "Unsupported Extension" is a fatal error sent due to lack=20
> of support
>    for an extension such as Disconnect and/or CoA messages.  This will
>    typically be sent by a proxy receiving an ICMP port unreachable
>    message after attempting to forward a Request to the NAS.

I am aware of that but this is inefficient!  It requires that we send a
message and try.  It is more efficient if we know up front via a
capability indication. =20

> > Sure for simple deployement scenarios like Dial up.  But now we are=20
> > talking about more sophisticated usage for RADIUS.
>=20
> The existing RADIUS mechanisms work for all services.  They=20
> are not just for "dialup".=20

In some cases they don't work at all and in other cases they work but
not efficiently.
=20
> > But this is not efficient.  Why send an attribute or a set of=20
> > attributes if they are not required by the Server?
>=20
> RADIUS is a request/response protocol.  There is no way for a=20
> NAS to know what the RADIUS server requires before sending an=20
> Access-Request. =20

But in subsequent interaction for that session --  either in accounting
or in subsequent requests or in issuing commands such as proposed by LOG
OFF then the Server can indicate what it may desire.

=20
> > For one I need to be assured that the NAS supports the mandatory=20
> > semantics.
>=20
> That's relatively simple though -- a NAS can signal support=20
> for the extended format with a single attribute.=20

Ahhhhh so you do support a capability exchange!!!  I thought you didn't.
So we have at least one.
=20
> > I may support NAS Filter Rule but only some of its options.
>=20
> To date, RADIUS documents have focused on a single subject=20
> and included clear guidelines about what is needed to be=20
> considered compliant. =20

Not true. Is 2865 focused? Is 2869 focused? I would even argue that 3576
presents two different capabilities, DM and COA  Each may be supported
independantly.

> As an example, RFC 2868 is focused on=20
> tunnel attributes, so that a vendor can indicate that they=20
> are compliant with it, without being forced to implement=20
> attributes relating to a different capability.=20

Ideally sure but in some cases it is not possible to split a complex AAA
application into smaller RFCs just to stay true to that ideal. =20

Diameter CC is a perfect example of that.  Not all the features will be
implemented by a given vendor or even be ever be implmented by anyone.

> Similarly, existing RADIUS attributes are typically either=20
> implemented or not implemented.  If an attribute covers=20
> divergent capabilities so that vendors are unlikely to fully=20
> implement it within a single device, I would argue that that=20
> attribute should be broken down into distinct attributes,=20
> each with a unitanry purpose.

You mean like user-name?  Perhaps let user-name carry the actual user
name and have another attribute carry the routing information?  I would
agree.

>=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: Sun, 28 Aug 2005 03:15:54 +0000
Content-class: urn:content-classes:message
Subject: RE: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sat, 27 Aug 2005 23:13:57 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Alan DeKok" <[email-masked]>

Hi Bernard, =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, August 27, 2005 6:55 AM
> To: [email-masked]
> Cc: [email-masked]; Alan DeKok
> Subject: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt
>=20
> > And blindly requesting for location information (as you=20
> propose) I run=20
> > the risk of having a rejection by getting to a NAS that does not=20
> > support Challenge in the first place.
>=20
> The only reason a RADIUS server will need to send an=20
> Access-Challenge is if it *requires* location and it is not=20
> present.  In that case, the RADIUS server cannot allow access=20
> if location isn't provided. =20

Not true at all!   A RADIUS server may require to get location but if it
does not that does not mean that its only action is to reject the
session.  It may still grant access but the access could be limited in
scope.

I can have a policy that states the service X may only provided at a
certain location.  I request for the location and if it is not provided
then I grant access but do not grant access to service X.

Blindly challenging the NAS -- requesting location without even knowing
whether the NAS even supports a challenge let alone location information
-- runs the risk of outright rejection of the session.

> If the RADIUS server doesn't require location, then it can=20
> just request location in the Access-Accept.  If it gets it,=20
> great.  If not, it is willing to live with out it.=20

You mean for accounting purposes.  I am not even talking about that.
Above I am talking about needing location as part of the policy decision
function for granting access.
=20
> In either case (mandatory or optional), capability=20
> advertisement by the NAS is irrelevant.=20

I disagree.  There is a distinct advantage of letting the RADIUS server
know whether or not the NAS supports a particular function.  Blindly
challenging should only be done in cases where the NAS does not support
a capability exchange mechanism.

=20
>=20
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>=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: Sat, 27 Aug 2005 21:52:18 +0000
Content-class: urn:content-classes:message
Subject: Review of draft-lior-radext-end-to-end-caps-01.txt 
Date: Sat, 27 Aug 2005 14:51:23 -0700
From: "Majdi Badarin" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5AB51.778F382C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I object to taking on the End-to-End Capabilities document as a RADEXT =
WG=20
work item. The document doesn't properly define the problem and the =
proposed solution =20
is excessively complex and is not compatible with existing mechanisms in =
Diameter.=20
 =20
When adding new features, the RADEXT WG needs to try and maintain the =
simplicity of=20
RADIUS as I believe that this has accounted for much of its success.  =
Questions=20
like "is this feature necessary at all?"  And "can this feature be done =
in a simple way?"=20
should be answered first. =20

RADIUS is a simple protocol, and has existed without capability =
negotiation since its=20
inception. A very good case has to be made for adding this capability at =
this time,=20
especially in the complex manner that's being proposed.   The document =
does not=20
make the case for the major changes it is proposing.  In fact, many of =
the problems=20
it defines do not exist and many of the features it attempts to add =
duplicate existing=20
RADIUS functionality.=20

As a result, I believe that the WG should discard the End-to-End =
Capabilities document,=20
since its approach is so inherently complex and flawed that it cannot be =
fixed by=20
accepting the document as a WG work item. =20

A couple of specific problems, in addition to the unconvincing =
motivation are:=20

* The alternative mechanisms for detecting RFC 3576 support, something =
that=20
is already handled in RFC 3576.=20

* The use of capabilities negotiation for optional attributes.  RADIUS =
implementations=20
have handled optional attributes for years, so this is unnecessary.=20

* Retroactive changes to the behaviour of existing RADIUS =
implementations.=20

* Creation of a registry for Capability IDs, including capabilities that =
don't=20
exist in RADIUS RFCs.  This will cause interoperability problems -=20
RADIUS requires that VSAs be treated as optional so as to allow =
interoperability=20
between vendor implementations.=20

* Incompatibility with the Diameter optional/mandatory attribute =
marking. =20
The document doesn't even have a Diameter compatibility section.=20

I can go on to list all the objections to this document, all the =
unnecessarily=20
functionality, the confused problem statement, etc.  But that is hardly =
necessary;=20
other participants in the WG have already stated those objections during =
previous=20
discussions, more eloquently than I can.  In fact, looking back at =
previous=20
RADEXT WG discussion which started in January 2005, it appears that many =
of=20
these issues were brought up before. Looking back at the discussion, it =
appears=20
that WG consensus previously existed to adopt an alternative (simpler) =
approach. =20
So why is it being brought back again?=20

I have to wonder "How can this document even be considered as a WG work =
item=20
given the volume and seriousness of the criticisms that have been =
leveled=20
 against it?" And how can the RADEXT WG be bringing to WG last call=20
documents that have so many problems, such as the VLAN and Filters =
draft?=20

In its consideration of new WG items, the RADEXT WG seems to be asking =
the=20
wrong questions.  The right question isn't "Are there any objections?"=20
but rather "Is there WG consensus that this document is an appropriate =
solution=20
to a real problem, and are there a significant base of vendors who =
consider this=20
functionality necessary and who will implement it?"=20

------_=_NextPart_001_01C5AB51.778F382C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML =
DIR=3Dltr><HEAD><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1"></HEAD><BODY><DIV><FONT face=3D'Arial' =
color=3D#000000 size=3D2>=0A=
<P><FONT size=3D2>I object to taking on the End-to-End Capabilities =
document as a =0A=
RADEXT WG</FONT> <BR><FONT size=3D2>work item. The document =
doesn&#8217;t properly =0A=
define the problem and the proposed solution&nbsp; </FONT><BR><FONT =
size=3D2>is =0A=
excessively complex and is not compatible with existing mechanisms in =
Diameter. =0A=
</FONT><BR><FONT size=3D2>&nbsp;</FONT> <BR><FONT size=3D2>When adding =
new features, =0A=
the RADEXT WG needs to try and maintain the simplicity of =
</FONT><BR><FONT =0A=
size=3D2>RADIUS as I believe that this has accounted for much of its =0A=
success.&nbsp; Questions </FONT><BR><FONT size=3D2>like &#8220;is this =
feature necessary =0A=
at all?"&nbsp; And &#8220;can this feature be done in a simple =
way?&#8221; </FONT><BR><FONT =0A=
size=3D2>should be answered first.&nbsp; </FONT></P>=0A=
<P><FONT size=3D2>RADIUS is a simple protocol, and has existed without =
capability =0A=
negotiation since its </FONT><BR><FONT size=3D2>inception. A very good =
case has to =0A=
be made for adding this capability at this time, </FONT><BR><FONT =0A=
size=3D2>especially in the complex manner that&#8217;s being =
proposed.&nbsp;&nbsp; The =0A=
document does not</FONT> <BR><FONT size=3D2>make the case for the major =
changes it =0A=
is proposing.&nbsp; In fact, many of the problems</FONT> <BR><FONT =
size=3D2>it =0A=
defines do not exist and many of the features it attempts to add =
duplicate =0A=
existing</FONT> <BR><FONT size=3D2>RADIUS functionality. </FONT></P>=0A=
<P><FONT size=3D2>As a result, I believe that the WG should discard the =
End-to-End =0A=
Capabilities document,</FONT> <BR><FONT size=3D2>since its approach is =
so =0A=
inherently complex and flawed that it cannot be fixed by =
</FONT><BR><FONT =0A=
size=3D2>accepting the document as a WG work item.&nbsp; </FONT></P>=0A=
<P><FONT size=3D2>A couple of specific problems, in addition to the =
unconvincing =0A=
motivation are:</FONT> </P>=0A=
<P><FONT size=3D2>* The alternative mechanisms for detecting RFC 3576 =
support, =0A=
something that </FONT><BR><FONT size=3D2>is already handled in RFC 3576. =0A=
</FONT></P>=0A=
<P><FONT size=3D2>* The use of capabilities negotiation for optional =0A=
attributes.&nbsp; RADIUS implementations</FONT> <BR><FONT size=3D2>have =
handled =0A=
optional attributes for years, so this is unnecessary. </FONT></P>=0A=
<P><FONT size=3D2>* Retroactive changes to the behaviour of existing =
RADIUS =0A=
implementations. </FONT></P>=0A=
<P><FONT size=3D2>* Creation of a registry for Capability IDs, including =0A=
capabilities that don't</FONT> <BR><FONT size=3D2>exist in RADIUS =
RFCs.&nbsp; This =0A=
will cause interoperability problems -</FONT> <BR><FONT size=3D2>RADIUS =
requires =0A=
that VSAs be treated as optional so as to allow interoperability</FONT> =0A=
<BR><FONT size=3D2>between vendor implementations. </FONT></P>=0A=
<P><FONT size=3D2>* Incompatibility with the Diameter optional/mandatory =
attribute =0A=
marking.&nbsp; </FONT><BR><FONT size=3D2>The document doesn't even have =
a Diameter =0A=
compatibility section. </FONT></P>=0A=
<P><FONT size=3D2>I can go on to list all the objections to this =
document, all the =0A=
unnecessarily </FONT><BR><FONT size=3D2>functionality, the confused =
problem =0A=
statement, etc.&nbsp; But that is hardly necessary; </FONT><BR><FONT =0A=
size=3D2>other participants in the WG have already stated those =
objections during =0A=
previous </FONT><BR><FONT size=3D2>discussions, more eloquently than I =
can.&nbsp; =0A=
In fact, looking back at previous </FONT><BR><FONT size=3D2>RADEXT WG =
discussion =0A=
which started in January 2005, it appears that many of </FONT><BR><FONT =0A=
size=3D2>these issues were brought up before. Looking back at the =
discussion, it =0A=
appears </FONT><BR><FONT size=3D2>that WG consensus previously existed =
to adopt an =0A=
alternative (simpler) approach.&nbsp; </FONT><BR><FONT size=3D2>So why =
is it being =0A=
brought back again?</FONT> </P>=0A=
<P><FONT size=3D2>I have to wonder "How can this document even be =
considered as a =0A=
WG work item </FONT><BR><FONT size=3D2>given the volume and seriousness =
of the =0A=
criticisms that have been leveled </FONT><BR><FONT =
size=3D2>&nbsp;against it?" And =0A=
how can the RADEXT WG be bringing to WG last call </FONT><BR><FONT =0A=
size=3D2>documents that have so many problems, such as the VLAN and =
Filters =0A=
draft?</FONT> </P>=0A=
<P><FONT size=3D2>In its consideration of new WG items, the RADEXT WG =
seems to be =0A=
asking the</FONT> <BR><FONT size=3D2>wrong questions.&nbsp; The right =
question =0A=
isn't "Are there any objections?" </FONT><BR><FONT size=3D2>but rather =
"Is there =0A=
WG consensus that this document is an appropriate solution =
</FONT><BR><FONT =0A=
size=3D2>to a real problem, and are there a significant base of vendors =
who =0A=
consider this </FONT><BR><FONT size=3D2>functionality necessary and who =
will =0A=
implement it?"</FONT> </P></FONT></DIV></BODY></HTML>
------_=_NextPart_001_01C5AB51.778F382C--

--
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: Sat, 27 Aug 2005 11:27:09 +0000
Date: Sat, 27 Aug 2005 04:26:58 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RE: Capabilities negotiation problem statement

> 3GPP2 for example use advertisement for:
> Prepaid - Before we push down a Prepaid policy we need to know whether
> the NAS supports that policy.  Otherwise the NAS will ignore the policy
> and allow the session to continue. As you can see this is a serious
> problem.

This case sounds the same as the security issue with filter rules. That 
is, the RADIUS server needs to send an attribute that cannot be safely 
ignored by the NAS. 

> Dynamic Auth - we need to understand whether a NAS supports 3576 for
> correct operation. 

RFC 3576 already specifies how a RADIUS server can determine if a 
NAS supports it.  Where the RADIUS client does not support RFC 3576, the 
server  will receive an ICMP port unreachable message in reply to a 
Disconnect or CoA-Request.  If the proxy supports RFC 3576, but the NAS 
does not, then the proxy replies with an Error-Cause value of "Unsupported 
Extension":

   "Unsupported Extension" is a fatal error sent due to lack of support
   for an extension such as Disconnect and/or CoA messages.  This will
   typically be sent by a proxy receiving an ICMP port unreachable
   message after attempting to forward a Request to the NAS.

> Sure for simple deployement scenarios like Dial up.  But now we are
> talking about more sophisticated usage for RADIUS.

The existing RADIUS mechanisms work for all services.  They are not just 
for "dialup". 

> But this is not efficient.  Why send an attribute or a set of attributes
> if they are not required by the Server?

RADIUS is a request/response protocol.  There is no way for a NAS to know 
what the RADIUS server requires before sending an Access-Request.  

> For one I need to be assured that the NAS supports the mandatory
> semantics.  

That's relatively simple though -- a NAS can signal support for the 
extended format with a single attribute. 

> I may support NAS Filter Rule but only some of its options.

To date, RADIUS documents have focused on a single subject and included 
clear guidelines about what is needed to be considered compliant.  As an 
example, RFC 2868 is focused on tunnel attributes, so that a vendor can 
indicate that they are compliant with it, without being forced to 
implement attributes relating to a different capability. 

Similarly, existing RADIUS attributes are typically either implemented or 
not implemented.  If an attribute covers divergent capabilities so that 
vendors are unlikely to fully implement it within a single device, I would 
argue that that attribute should be broken down into distinct attributes, 
each with a unitary purpose.

--
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: Sat, 27 Aug 2005 10:56:43 +0000
Date: Sat, 27 Aug 2005 03:54:56 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt

> And blindly requesting for location information (as you propose) I run
> the risk of having a rejection by getting to a NAS that does not support
> Challenge in the first place. 

The only reason a RADIUS server will need to send an Access-Challenge is 
if it *requires* location and it is not present.  In that case, the RADIUS 
server cannot allow access if location isn't provided.  

If the RADIUS server doesn't require location, then it can just request 
location in the Access-Accept.  If it gets it, great.  If not, it is 
willing to live with out it. 

In either case (mandatory or optional), capability advertisement by the 
NAS is irrelevant. 

--
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: Sat, 27 Aug 2005 07:25:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sat, 27 Aug 2005 03:26:11 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Bernard,
=20
Bernard wrote:

> Based on this discussion, I think it is even simpler than I=20
> had thought -- Access-Challenge, Error-Cause and a "send=20
> location" attribute appear to solve the problem with no need=20
> for any capability advertisements.=20

I still think you are missing something.  I still need to know whether
the capability is supported.  It may impact my policy decision.  I may
have a policy that allows certain services to be provided only if
location is provided.  Knowing that a NAS cant support location allows
me to send an Accept with only those services that do not require
location information to be provided.=20

And blindly requesting for location information (as you propose) I run
the risk of having a rejection by getting to a NAS that does not support
Challenge in the first place.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, August 27, 2005 2:13 AM
> To: Alan DeKok
> Cc: [email-masked]; [email-masked]
> Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt
>=20
> >   Can there be multiple Error-Causes?  That would seem to=20
> be efficient.
>=20
> Off the top of my head, I don't see why not.  RFC 3576 allows=20
> 0+ Error-Cause attributes in a NAK, so I'd assume that it=20
> also would be allowed in an Access-Challenge or Access-Reject.=20
>=20
> > An Access-Request MAY be responded to with an Access-Challenge=20
> > containing Error-Cause, For authentication methods that normally=20
> > expect request/ack, receipt of an Access-Challenge would=20
> indicate that=20
> > they add the relevant data, and re-send the Access-Request without=20
> > prompting the user for more information.
>=20
> Where an Access-Challenge is expected, this works.  Where it=20
> is unexpected, RFC 2865 Section 4.4 requires that the NAS=20
> treat the Access-Challenge as an Access-Reject.=20
>=20
> >   That requirement would make it clear that the NAS *does* have to=20
> > maintain state, but that it does not have to tell the user=20
> about the=20
> > re-authentication.
>=20
> I think that it's possible to make this work without changing=20
> existing Access-Challenge behavior.  If an Access-Challenge=20
> would be sent anyway, a "send location" attribute can be=20
> piggybacked on it.  If it is unexpected, the Access-Challenge=20
> will be treated as an Access-Reject and re-authentication=20
> will be required.=20
>=20
> > > Am I missing something, or is the problem really this simple?=20
> >=20
> >   It would appear so.
>=20
=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: Sat, 27 Aug 2005 07:17:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sat, 27 Aug 2005 03:17:58 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Alan,

Just one nit.  You said:

>   For non-location-aware NASes, the RFC's already require=20
> implementations to treat unexpected Access-Challenges as=20
> Access-Rejects, so this idea would appear to be fail-safe there, too.

It not unexpected Access-Challenges but rather unsupported
Access-Challenge.

Section 4.4 of RFC 2865 states:

"     If the NAS does not support challenge/response, it MUST treat an
      Access-Challenge as though it had received an Access-Reject
      instead."

There is a difference because unexptected seems to tie the Challenge to
the authentication method which is not true.

My understanding is a Challenge is an indication that the Server
requires more information.
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Saturday, August 27, 2005 1:40 AM
> To: Bernard Aboba
> Cc: [email-masked]; [email-masked]
> Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt
>=20
> Bernard Aboba <[email-masked]> wrote:
> > If the RADIUS authentication mechanism doesn't already utilize an=20
> > Access-Challenge, this will not work.
>=20
>   On the other hand, if the NAS is updated to include=20
> location information, it may be acceptable to add additional=20
> requirements such as this.

Yes.  The scenario in  Geopriv would imply that a NAS stating suppot for
Location is expected to receive a Challenge by a server requiring
location information.  But we can be more clear about 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: Sat, 27 Aug 2005 07:07:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities negotiation problem statement
Date: Sat, 27 Aug 2005 03:07:47 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Bernard,

Thank you for your review.=20

I presented a slide presentation at IETF 62 that describes the problem
statement for Cap Exchange.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, August 26, 2005 1:23 PM
> To: [email-masked]
> Subject: Capabilities negotiation problem statement
>=20
> In looking at the Capabilities Negotiation draft, I was=20
> struck by the vagueness of the problem statement.=20
>=20
> RADIUS has existed without capabilities negotiation for more=20
> than a decade now.  As far as I know,  there are not even any=20
> Vendor-Specific implementations.  Given the level of=20
> experimentation on other areas (see RFC 2882) this is=20
> surprising.  If this problem is so important and pervasive=20
> (as the draft argues) how come the industry seems to have=20
> ignored it for a decade, without creating huge problems?=20

In fact, CUI and other work has introduced a capability exchange.

3GPP2 for example use advertisement for:
Prepaid - Before we push down a Prepaid policy we need to know whether
the NAS supports that policy.  Otherwise the NAS will ignore the policy
and allow the session to continue. As you can see this is a serious
problem.

Dynamic Auth - we need to understand whether a NAS supports 3576 for
correct operation.  There maybe more the one way to kill a session.  So
we want to know what the NAS can do.  This is laregely an efficiency
problem but also=20

> The answer is that RADIUS already enables NASes and RADIUS=20
> servers with different capabilities to interoperate.  For=20
> example, RFC 2865 allows a NAS to ignore attributes it does=20
> not understand, and this is how most existing RADIUS client=20
> implementations behave.  This allows a RADIUS server to send=20
> attributes to a NAS without having to worry about whether it=20
> understands them, as long as those attributes can be safely ignored.=20

Sure for simple deployement scenarios like Dial up.  But now we are
talking about more sophisticated usage for RADIUS.

> Similarly, a NAS does not need to know whether a RADIUS=20
> server understands an attribute in order to send it, as long=20
> as the attribute can be safely discarded by the RADIUS server.

But this is not efficient.  Why send an attribute or a set of attributes
if the are not required by the Server?

Also if you look at new drafts such as logoff.  Why send a logoff
message if the Server doesn't need it?

=20
> As a result, the real issue is specification of mandatory=20
> attributes, not "capability-negotiation" per se.  Note that a=20
> proposal for mandatory/optional marking has recently been put=20
> forward in the Design Guidelines document.=20

I don't think that that is all.
=20
> Some of the cases where the mandatory/optional issue comes up=20
> include:=20
>=20
> a. Where the RADIUS server REQUIRES the NAS to understand an=20
> attribute in order for access to be provided.  A classic case=20
> of this is use of security attributes (VLANs, Filters, etc.).=20
>  A NAS cannot safely ignore a security attribute sent by the=20
> RADIUS server. =20
>=20
> This situation is the most common one;  there are documented=20
> cases where existing behavior has resulted in substantial=20
> financial losses. =20
> At the same time, the behavior of existing implementations=20
> can't be changed retroactively.=20
>=20
> b. Where the NAS REQUIRES that the RADIUS server send an=20
> attribute in order for it to provide access.=20
>=20
> Other cases are already handled by the RADIUS protocol as it=20
> exists today:=20
>=20
> c. Where the RADIUS server requires an attribute that the NAS=20
> does not provide in an Access-Request, the server can send an=20
> Access-Reject, potentially including an Error-Cause (101)=20
> attribute.  If the NAS understands the Error-Cause attribute,=20
> it can correct the problem.=20
>=20
> In looking at the proposal within the Design Guidelines=20
> document, it appears to me that the Mandatory/Optional=20
> functionality described there potentially handles both cases=20
> a) and b).  In case a), a RADIUS server can send an attribute=20
> with the "M" bit set.  In case b), a NAS can send an=20
> attribute with the "M" bit set.=20
>=20
> Given all of this -- what is the problem statement for=20
> Capabilities Negotiation, and how does it differ from the=20
> problem statement for Mandatory/Optional attributes?=20

For one I need to be assured that the NAS supports the mandatory
semantics.  So as a minimum we need that information.  But there is
more....

But mandatory is not enough.  Since some Applications have different
options or capabilities.  We need to understand which ones are
supported.  For example, I may support volume based or time based
prepaid but not support Prepaid Pools which are much more difficult to
implement.  I may support NAS Filter Rule but only some of its options.
So knowing what the NAS supports allows me to send the appropriate
attributes to the NAS invoking the modes that it supports for a given
application.  After all, the name of the game is not to have the NAS
reject the session.

Finally, A server may need to understand what features are supported as
part of its authentication/authorization policy decision.  If the NAS
does not support prepaid then, in a mobile IPv4 scenario, the server
will not rely on the NAS for prepaid but rather the HA.  It will then
force the NAS (acting as FA) to reverse traffic all the flows to the HA
and not send any prepaid attributes to the NAS.

> --
> 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: Sat, 27 Aug 2005 06:35:12 +0000
Date: Fri, 26 Aug 2005 23:34:56 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt 

> > > Am I missing something, or is the problem really this simple? 
> > 
> >   It would appear so.

The "server-driven" approach also provides a mechanism to address RADEXT 
Issue 27 (Who's Location). 

One of the major problems with the RADIUS-GEOPRIV document is that it 
does not support user location determination, only  NAS location. 

This is a problem for vendors who are shipping APs with built-in 
location support that enables APs to pinpint the location of associated 
stations.  At least one RADIUS server implementation now supports 
"location-based access control".  Why can't the RADIUS-GEOPRIV 
specification be used to send user as well as NAS location? 

This basic problem with the document was pointed out in November 2004, but 
has still not been fixed in August 2005, 9 months later.  

However, using the "server-driven" approach, the problem would  
not be hard to address.  In the "send location" attribute included by the 
server, the server can specify what type of location data it is looking 
for - user or NAS.  

Note that layer 2 standards such as IEEE 802.11k already enable this 
distinction.  In IEEE 802.11k a station can ask either for its own 
location or the location of the AP.  

--
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: Sat, 27 Aug 2005 06:13:27 +0000
Date: Fri, 26 Aug 2005 23:13:17 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt 

>   Can there be multiple Error-Causes?  That would seem to be efficient.

Off the top of my head, I don't see why not.  RFC 3576 allows 0+ 
Error-Cause attributes in a NAK, so I'd assume that it also would 
be allowed in an Access-Challenge or Access-Reject. 

> An Access-Request MAY be responded to with an Access-Challenge 
> containing Error-Cause, For authentication methods that normally expect
> request/ack, receipt of an Access-Challenge would indicate that they
> add the relevant data, and re-send the Access-Request without
> prompting the user for more information.

Where an Access-Challenge is expected, this works.  Where it is 
unexpected, RFC 2865 Section 4.4 requires that the NAS treat the 
Access-Challenge as an Access-Reject. 

>   That requirement would make it clear that the NAS *does* have to
> maintain state, but that it does not have to tell the user about the
> re-authentication.

I think that it's possible to make this work without changing existing 
Access-Challenge behavior.  If an Access-Challenge would be sent anyway, a 
"send location" attribute can be piggybacked on it.  If it is unexpected, 
the Access-Challenge will be treated as an Access-Reject and 
re-authentication will be required. 

> > Am I missing something, or is the problem really this simple? 
> 
>   It would appear so.

Based on this discussion, I think it is even simpler than I had thought -- 
Access-Challenge, Error-Cause and a "send location" attribute appear to 
solve the problem with no need for any capability advertisements. 

--
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: Sat, 27 Aug 2005 06:02:33 +0000
Date: Fri, 26 Aug 2005 23:02:13 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt 

> would seem that this proposal may work for non-location-aware proxies.

Yes, I think the problem is with the NAS, not proxies.  

> For non-location-aware NASes, the RFC's already require
> implementations to treat unexpected Access-Challenges as
> Access-Rejects, so this idea would appear to be fail-safe there, too.

Yes, Section 4.4 of RFC 2865 states:

"     If the NAS does not support challenge/response, it MUST treat an
      Access-Challenge as though it had received an Access-Reject
      instead."

So a RADIUS server can always send a Challenge with an Error-Cause value 
as well as a "send location" attribute.  Where the NAS does not expect a 
Challenge, it will treat it as an Access-Reject. 

--
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: Sat, 27 Aug 2005 05:39:03 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt 
Cc: [email-masked], [email-masked]
Date: Sat, 27 Aug 2005 01:40:13 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> If the RADIUS authentication mechanism doesn't already utilize an 
> Access-Challenge, this will not work. 

  On the other hand, if the NAS is updated to include location
information, it may be acceptable to add additional requirements such
as this.

  For simple password-style authentication methods such as PAP or
CHAP, adding another step would be relatively easy.  For methods
already involving Access-Challenge, your previous suggestion would
apply.

> But we can't impose that requirement retroactively. 

  I agree.

  However, RADIUS proxies already pass Access-Challenge packets back
and forth for protocols they don't understand.  (e.g. EAP).  So it
would seem that this proposal may work for non-location-aware proxies.

  For non-location-aware NASes, the RFC's already require
implementations to treat unexpected Access-Challenges as
Access-Rejects, so this idea would appear to be fail-safe there, too.

  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: Sat, 27 Aug 2005 05:26:04 +0000
Content-class: urn:content-classes:message
Subject: RE: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sat, 27 Aug 2005 01:26:00 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

 Hi Bernard,

Please see inline.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, August 26, 2005 8:43 PM
> To: [email-masked]; [email-masked]
> Subject: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt
>=20
> In thinking about the problem of capabilities negotiation=20
> within the RADIUS-GEOPRIV document, it is not clear to me=20
> that it is necessary for a NAS to advertise location support.=20
>=20
> Instead, the NAS can be set by default not to send location=20
> attributes unless the server asks for them.  The problem then=20
> reduces to how the server communicates its needs to the NAS.=20
>=20
> There are several cases of interest:=20
>=20
> 1) The RADIUS server REQUIRES the NAS to provide location in=20
> the Access-Request (e.g. it implements location-based access control).
> In this case the RADIUS server can send an Access-Reject with=20
> an Error-Cause attribute with a value of "Location Required".=20
> Alternatively if the authentication mechanism (e.g. EAP)=20
> supports Access-Challenges, the RADIUS server can place a=20
> "Send location" attribute in the Challenge.  On receiving=20
> either of these indications, the NAS includes location=20
> attributes in the Access-Request.=20
> Note that the server's decision is not influenced by whether=20
> the client has advertised location support, only by the=20
> inclusion of location attributes in the Access-Request.

Access Reject case is grossly inefficient requiring the
re-authentication and is simply not acceptable in many deployement and
in particular in mobile deployements where authentication is resouce
intensive.

The Challenge Option is better but we will benefit in efficiency if the
home network knew whether or not the NAS supported the feature in the
first place.  After all, if you required location information, why would
you challenge a NAS that couldn't deliver the information?

> 2) The RADIUS server does not require location in the=20
> Access-Request, but would like location attributes to be=20
> included in Accounting packets, if available.  In this case,=20
> the RADIUS server sends an Access-Accept including a "Send=20
> location" attribute, perhaps specifying more details on how=20
> location should be provided (e.g. Accounting-Stop only,=20
> interim records, civil/geographic, etc.).

This would work but if the authentication is predicated on whether or
not I could have location in the accounting stream, then your scheme
would not work right?
=20
> Since the RADIUS server does not require location attributes,=20
> a legacy NAS can ignore the "send location" attribute with no=20
> ill effects.  This is how legacy NAS implementations behave,=20
> and the "Issues and Fixes" document indicates that this is in=20
> fact the correct behavior.
> If the NAS does understand the "send location" attribute then=20
> it will send location in the Accounting packets as requested.
>=20
> Am I missing something, or is the problem really this simple?=20

I think advertizement as described in the current Geopriv document is
well thoughtout.

I think the issue raised is whether or not to take care of it in the
End-to-End capability or in the document itself.

> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>=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: Sat, 27 Aug 2005 05:14:03 +0000
Date: Fri, 26 Aug 2005 22:13:53 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt 

>   Also, this use of Access-Reject is closer to the semantics for
> Access-Challenge.  I would prefer to use that, instead.  i.e. An
> Access-Request MAY be responded to with an Access-Challenge containing
> Error-Cause, For authentication methods that normally expect
> request/ack, receipt of an Access-Challenge would indicate that they
> add the relevant data, and re-send the Access-Request without
> prompting the user for more information.

If the RADIUS authentication mechanism doesn't already utilize an 
Access-Challenge, this will not work. 

>   That requirement would make it clear that the NAS *does* have to
> maintain state, but that it does not have to tell the user about the
> re-authentication.

But we can't impose that requirement retroactively. 

> > Alternatively if the authentication mechanism (e.g. EAP) supports 
> > Access-Challenges, the RADIUS server can place a "Send 
> > location" attribute in the Challenge.  On receiving either of these 
> > indications, the NAS includes location attributes in the Access-Request. 
> > Note that the server's decision is not influenced by whether the client 
> > has advertised location support, only by the inclusion of location 
> > attributes in the Access-Request.
> 
>   Yes.
> 
> > 2) The RADIUS server does not require location in the Access-Request,
> ...
> 
>   Yes.
> 
> > Am I missing something, or is the problem really this simple? 
> 
>   It would appear 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/>

Envelope-to: [email-masked]
Delivery-date: Sat, 27 Aug 2005 05:00:52 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt 
Cc: [email-masked], [email-masked]
Date: Sat, 27 Aug 2005 01:01:40 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> 1) The RADIUS server REQUIRES the NAS to provide location
> in the Access-Request (e.g. it implements location-based access control).
> In this case the RADIUS server can send an Access-Reject with an 
> Error-Cause attribute with a value of "Location Required". 

  Can there be multiple Error-Causes?  That would seem to be efficient.

  Also, this use of Access-Reject is closer to the semantics for
Access-Challenge.  I would prefer to use that, instead.  i.e. An
Access-Request MAY be responded to with an Access-Challenge containing
Error-Cause, For authentication methods that normally expect
request/ack, receipt of an Access-Challenge would indicate that they
add the relevant data, and re-send the Access-Request without
prompting the user for more information.

  That requirement would make it clear that the NAS *does* have to
maintain state, but that it does not have to tell the user about the
re-authentication.

> Alternatively if the authentication mechanism (e.g. EAP) supports 
> Access-Challenges, the RADIUS server can place a "Send 
> location" attribute in the Challenge.  On receiving either of these 
> indications, the NAS includes location attributes in the Access-Request. 
> Note that the server's decision is not influenced by whether the client 
> has advertised location support, only by the inclusion of location 
> attributes in the Access-Request.

  Yes.

> 2) The RADIUS server does not require location in the Access-Request,
...

  Yes.

> Am I missing something, or is the problem really this simple? 

  It would appear 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: Sat, 27 Aug 2005 00:43:38 +0000
Date: Fri, 26 Aug 2005 17:43:14 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt

In thinking about the problem of capabilities negotiation within the 
RADIUS-GEOPRIV document, it is not clear to me that it is necessary for a 
NAS to advertise location support. 

Instead, the NAS can be set by default not to send location attributes 
unless the server asks for them.  The problem then reduces to how the 
server communicates its needs to the NAS. 

There are several cases of interest: 

1) The RADIUS server REQUIRES the NAS to provide location
in the Access-Request (e.g. it implements location-based access control).
In this case the RADIUS server can send an Access-Reject with an 
Error-Cause attribute with a value of "Location Required". 
Alternatively if the authentication mechanism (e.g. EAP) supports 
Access-Challenges, the RADIUS server can place a "Send 
location" attribute in the Challenge.  On receiving either of these 
indications, the NAS includes location attributes in the Access-Request. 
Note that the server's decision is not influenced by whether the client 
has advertised location support, only by the inclusion of location 
attributes in the Access-Request.

2) The RADIUS server does not require location in the Access-Request,
but would like location attributes to be included in Accounting packets, 
if available.  In this case, the RADIUS server sends an Access-Accept
including a "Send location" attribute, perhaps specifying more details on
how location should be provided (e.g. Accounting-Stop only, interim
records, civil/geographic, etc.).

Since the RADIUS server does not require location attributes, a legacy NAS 
can ignore the "send location" attribute with no ill effects.  This is how 
legacy NAS implementations behave, and the "Issues and
Fixes" document indicates that this is in fact the correct behavior.
If the NAS does understand the "send location" attribute then it will
send location in the Accounting packets as requested.

Am I missing something, or is the problem really this simple? 

--
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, 26 Aug 2005 23:28:34 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Capabilities negotiation problem statement 
Cc: [email-masked]
Date: Fri, 26 Aug 2005 19:29:33 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> What happens to the "extended" RADIUS attribute format including the
> Mandatory bit when the RADIUS PDU passes through a proxy server that
> hasn't implemented the "extended" attribute format?

  Ideally, it passes it through unchanged.

> I suppose this is the same as what happens to any other unrecognized
> attributes at proxy servers...  which is what, exactly?

  "implementation dependent".  So let's look at the error conditions:

 1) proxy drops the attributes, and home server doesn't see them.
    It's likely then, that the home server will need those attributes,
    and the new type of session will fail to meet it's requirements,
    and will be rejected

 2) The proxy passes them as-is, and the home server sees them.
    It's likely, then, that the new type of session will work.

  Looking at (1), if the home server has a way to tell that the new
attributes have been dropped, then the design is fail-safe.
Otherwise, the home server gets a request with missing information,
and may reach the wrong conclusion.

  My initial thought is to extend the RADIUS packet header by
mandating a new RADIUS attribute to be the first one in the packet.
The existence, and placement, of that attribute would signal new
capabilities.  It's content could include things like information
about the other "mandatory" attributes in the packet, such as a simple
count.

  If that attribute was a simple integer, it's impact on RADIUS would
be small, and the likelihood of making it through a proxy chain would
be high.  The other, complex, new attributes may not make it through a
proxy chain, but by "bootstrapping" off of the first attribute, home
servers could detect this fact, and deal with it.

  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, 26 Aug 2005 21:36:00 +0000
Content-class: urn:content-classes:message
Subject: IETF-63 Proceedings Submission
Date: Fri, 26 Aug 2005 17:35:43 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

IETF-63 RADEXT WG Minutes

Scribes: Paul Congdon, Greg Weber (Editor: Dave Nelson)
No jabberer.  (Later Hannes Tschofenig joined the jabber room.)
Bluesheets started.
No agenda changes requested.

Presentations and agenda online at:
   http://www.drizzle.com/~aboba/IETF63/radext/
RADEXT Issues Tracker location:
   http://www.drizzle.com/~aboba/RADEXT
Streaming audio archive location:
=20
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf63/ietf63-ch5-we
d.mp3.1 [start time index: 20:34]

Brief status of WG work items:
- 2684bis in AD follow-up
- Dynauth MIBs completed WGLC, 9 issues
- CUI in AD follow-up
- Digest Auth completed WGLC, 5 issues
- 802 Extensions in WGLC, 3 issues (so far)

Presentations:

- RFC2684 bis presented by Jari Arkko.

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt

Problem with internationalization found in IESG review.  Added
clarifying text for ABNF vs. document text requirements and the use of
UTF-8 vs. IDN-unware ASCII for the realm part.  Revision back to IESG
for approval -- very soon, e.g. about a week.   Realm strings will be
IDN unaware (no "!").

- Chargeable User Identity presented by Avi Lior.

http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id
-03.txt

All issues have been addressed in the current version of the document.
Several SDOs are interested in this draft - WiMAX is one who will be
submitting a liaison letter to IETF for this.  Pasi Eronen clarifies
that this document is in AD evaluation stage and not at the IESG.
Bernard may need to update the web-site to indicate the appropriate
document status. ID Tracker from IETF homepage is definitive on status.

- Digest Authentication update by Wolfgang Beck.

http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt

Diameter compatibility is the current main issue with the document.
There is also an issue regarding client-side nonce generation when
interoperating with Diameter - additional text will be added to address
this.  We could move forward two ways; one it get client side nonce
generation added to diameter, or simply drop this.  The 3GPP2 liaison
would like to see client side nonce generation remain because they
currently use it.  Avi Lior recommends that we operate in both modes of
operation and when working with Diameter, and get Diameter to update to
support client side nonce generation.  The 3GPP2 people are waiting for
an RFC number on this document so they can publish their spec.  The
security considerations need to be updated to discuss what to do when
realm check fails.  There were also some typos that will be corrected.
Desire to get -04 version out shortly after IETF-63.

- Dynamic Authorization MIBs - Greg Weber speaking for authors who could
not attend.

http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib
-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib
-01.txt
=20
These MIBs are companions to RFC 3576.  They are expected to be
completed by the end of the year.  Issues 96/97 have been resolved and
are simply editorial in nature.  Issue 105 resolution relates to where
the MIBs are to be located in the OID tree.  It is believed that new
MIBs should be rooted off of mib-2 and the authors are willing to make
the change to support this.  Issue 92 is the most controversial.  A few
new terms are defined by this document; DAC and DAS.  It was suggested
to match RFC 3576 and not introduce new terms in MIB, however the terms
are embedded in all of the object names.  It is still the belief of the
WG that the terms should be consistent and it sounds as though the
object names will be globally searched and replaced.  Bernard Aboba: RFC
3576bis would be within WG charter, and we could address the terminology
issues there.  That would mean either delaying the MIBs or revising them
later.

- 802 Extensions draft presented by Paul Congdon.

http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt

Discussed recent changes, but not current issue status.  Changes include
removal of controversial (Diameter-like) extended attribute types, no
new data-types or M-bit, fleshed out the NAS-Filter-Rule,  can now
specify L2 encapsulations, removed IP-redirection rule type in favor of
tunneling.  Among the interested parties are TNC of TCG, 3GPP, WiMAX
(hot-lining). Glen Zorn questioned the chairs on why this document was
so quickly moved to last call.  The chairs believe that the previous
issues in the individual submissions were sufficiently resolved and
there being a number of SDOs waiting on this document see the need to
expedite the review and closure of this document.  WG last call closes
on Aug 10th.  There was a question regarding when the wireless
attributes would be documented.  There is a -00 draft on WLAN attributes
to be discussed on this later in the meeting.

- RADIUS IPv6 MIBs discussed by Dave Nelson.

http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt

http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt

http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt

http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt

New textual conventions for address objects have been included.  Review
comments from the MIB Doctors have been resolved in the -01 revisions.
The drafts UPDATE their predecessor RFCs, deprecate old tables (not
doing table augmenting anymore), added new tables to mirror old ones,
added specific usage guidelines new IP address objects.  The question of
whether these should be WG work items was posed and no objections were
heard.  The RADEXT -00 drafts will be created and moved to WG last call.

- Common Radius Implementation Issues and Fixes presented by Dave
Nelson.

http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt

The document was created based upon a long laundry list of issues that
have been discussed on the mailing list.  This document identifies many
of the problems identified in the field and makes suggestions to resolve
the problems.  Areas discussed include:=20
  - Proper use of the state attribute=20
  - Request ID supplementation alternative=20
  - Re-transmit schemes=20
  - How to handle overload conditions=20
  - Clarification of accounting attribute updates=20
  - Clarification of using multiple Filter-ID attributes=20
  - Treating access-accept for unknown services as a reject=20
  - Avoiding sending VSAs to a NAS that doesn't understand them
                                                             =20
A question about this recommendation is how to reliably detect supported
vs. unsupported VSAs.  The capabilities attribute is a possible
solution.  Glen Zorn suggested the possibility of a version number.
Since this is just -00, it was suggested to post issues against the
document.  It was noted that some issues were currently in the tracker
but not yet included in the draft.

  - Corrections to RFC 2869, section 2.2 regarding miss-stated
Access-Challenge.=20
  - Handling multiple services=20
  - Defining how to calculate Message-Authenticator for Disconnect, COA
and others=20
  - Authorize only discussion

There were some questions of how this document should progress.  The
document is useful, but perhaps an RFC 3576bis additionally needs to be
created.  Also, some of the issues are against earlier RFCs as well.
These are standards track and may be more difficult to update.  This
document is intended to address existing and past issues.  Another
forward looking document discusses future issues. Other issues not
addressed were NASes with multiple IP addresses and accounting interval
updates.  These should be included and consensus on a solution for these
needs to be proposed.

- RADIUS Attribute Design Guidelines presented by Greg Weber.

http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0
0.txt

This is a forwarding looking document addressing design recommendations
for new attributes.  This document describes what is considered a good
attribute design and reviews the current RADIUS data types, as well as
the divergence in the Standard and Vendor Specific data models.  A few
have reviewed this document so far.  The current document does include
some recommendations, but these are straw-man recommendations.  The
motivation for this document is to get better alignment with data models
in vendor attributes, address attribute space exhaustion and align
better with diameter.  The scope of the document includes consideration
for backward compatibility, existing VSAs, supporting the existing
transport, non-AAA applications and Diameter compatibility. The document
straw-man proposes a single standards base format for VSAs as a
recommendation.  The document also includes recommendations on when
particular formats should be used and when to use existing VSA format
verse the new one.  Lots to do on this draft.  Avi Lior agrees this
document is a good starting point and is willing to work on the draft.
There was a question whether SDOs should be differentiated from Vendors,
but the group doesn't believe so.  There was a question whether IANA
considerations are included, but the authors believe this is already
spelled out elsewhere.  Glen Zorn asks if it was considered to extend
the size of RADIUS attributes rather than dealing with fragmentation.
Greg Weber did not consider this because he felt it would be beyond the
scope of the charter.

- WLAN Attributes presented by Jari Arkko.

http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt

The list of attributes that were removed from the 802 Extensions draft
was presented.  There is some overlap that needs to be discussed.
[Technical difficulties with slides caused us to move forward to the
next topic.]  Upon return, some relationships to the EAP keying draft
were described.  A list of key management attributes were described and
the issues.  Privacy can be addressed similar to NAI and by omitting
Peer-ID and Server-ID attributes.  Key-wrap options were described as
three choices; AES key wrap, a Key Encryption Key (Zorn draft) or IPSec.
The later is not used in industry.  The key-wrap options may be
difficult to resolve.  The questions on this document are whether this
should be a WG item and how to solve the privacy and key-wrap problems.

- RADIUS attributes for Cryptographic Keys presented by Glen Zorn.

http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt

The motivation for this draft was to allow RADIUS to be used in certain
government environments.  While RADIUS isn't a key provisioning
protocol, there are keys that are passed around in RADIUS and perhaps
aren't wrapped securely enough.  Several editorial changes were made in
the -07 revision, but also HMAC-MD5 was removed and other key transport
attributes (e.g. MPPE-xxx) were outlawed if the same data is also
transferred in the new attributes.  Questions about how keys are
transferred to the client - hop-by-hop or end-to-end?  They are passed
along the path in the way they are set-up - may be hop-by-hop.  Glen
plans to add AES-CMAC and some other technical changes in the -08
revision.

- General WG discussion on key-wrap issues.

Glen Zorn points out that the keying issue is not just an 802.11 or
Wireless problem.  Also, Glen believes that IPSec is inappropriate as a
protection mechanism for an application level protocol.  Glen believes
that NIST is in agreement that IPSec is not appropriate for this use.
Nancy Cam-Winget from Cisco summarized the NIST meeting that took place
back at the end of June.  She also agrees that it isn't just wireless
that needs the keying solutions.  They wanted to know if a new key-wrap
attribute with a new algorithm would be sufficient or would IPSec work.
Nancy believes that the latest draft of the Zorn document has all the
changes included based upon the NIST discussion.  Nancy believes that
NIST's reaction to the use of IPSec to protect RADIUS key distribution
was that it would require further review by NIST.  Jari Arkko also
believes the key work isn't just for wireless and would like to see it
in a separate draft from other WLAN attributes.  There was a question
about the relationship to the Zorn document and the Aboba document?  We
do have keying attributes for WLAN as a charter item for this group, but
can't introduce new security mechanisms.  Bernard's document comes from
the EAP key framework perspective.  A question about a new message
authenticator algorithm and attribute being described by Glen.  It can
be used in any RADIUS message because it is independent of the
authenticator value in the RADIUS message. Message-Authenticator cannot
be used in Accounting-Request or CoA messages.  The new one is
cryptographically stronger; the old one is not FIPS compliant (MD5).
The new attribute can be used as a complete replacement of the old style
message authenticator.  Alternatively, the old message authenticator
could still be used.  Bernard's draft reuses the RADIUS shared secret,
while Glen's draft assumes a cryptographically separate pre-shared key.
Bill Burr cautions that NIST is not looking very closely at RADIUS usage
and so there isn't a good view of what is being done here.  He
characterized the existing wireless key distribution mechanism (i.e. as
used in 802.11i with RADIUS) as somewhat "Rube Goldberg".  Bill
described the process of obtaining a FIPS-140 certification and how
painful it may be for vendors.  Glen points out that there is a lot of
interest in solving this problem and it has been solved, so why is there
a new WLAN draft addressing the keying mechanisms?  Dave Nelson (Chair)
indicated that the keying problem seems to have a lot of interest. The
WG might consider amending its charter (security mechanism restriction)
to address this issue, if needed.

[Ed. Note:  Only the statements of Bill Burr should be considered as the
position of NIST.  Other statements are the opinion of the speaker.]

- End-to-End capability exchange presented by Avi Lior.

http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-01
.txt

The proposal describes an end-to-end, per-session mechanism to negotiate
capabilities.  The attribute contains a string of octets where each
capability is encoded in 2 bits that define, not-supported, supported
and required.  Avi points out other documents need this work; location
in the GEOPRIV WG, VLAN, priority and filtering, CUI and prepaid could
all use this.  Should it be a WG document?  No one objects to making
this a WG item, but we will confirm this on the list.  This document
should be in alignment with Greg's work on Design Guidelines if we are
defining a new data type.

- RADIUS Prepaid attributes presented by Avi Lior.

http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-08.txt

The document was re-organized for read-ability and updated.  Flow based
prepaid is becoming a requirement.  Requested by 3GPP2 and WiMAX.  The
difference between RADIUS credit control (a.k.a. prepaid) and Diameter
credit control was described.   It is believed that some of the
differences are regarding some features that may compromise the privacy
of the client (e.g. balance check and cost inquiry).  Other differences
are not clear yet and need to be discussed.  How can Diameter credit
control and RADIUS prepaid be translated?  The recommendation is that
the server must do this itself.  A recommendation from the audience was
to have scenarios documented or analyzed - not necessarily included in
the draft, but available.  Different SDOs are using Diameter and RADIUS,
and there will likely be some issues related to translation.  Resolution
of these issues may require assistance from 3GPP, 3GPP2 and WiMAX, as
the RADEXT WG didn't anticipate supporting different "dialects" of the
prepaid extensions.  The authors believe the document is ready to become
a WG item.   Since the authors are not in complete alignment it was
suggested that they hash out their problems before making it a WG
document.   The authors believe they have enough alignment, but being
out of time, we will continue the discussion on the WG mailing list.

- RADIUS Bandwidth attributes presented by Avi Lior.

http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabili
ty-01.txt

Issues from Bernard Aboba's extensive review have all been addressed,
except one which is related to the length of the attribute size.  Should
this be a WG document?  Discuss on the WG mailing list.

- RADIUS QoS attributes presented by Hannes Tschofenig.

http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-01.txt

Hannes describes a more general QoS environment.  This work is related
to the Diameter work.  They are addressing a generic description
described in NSIS QSPEC work.  As compared to Avi Lior's bandwidth
document, this is a more heavy weight description.  Avi's document is
viewed as a short term solution.  There is the question of charter scope
in RADEXT.=20

- General WG Discussion about QoS and Bandwidth.

Allison Mankin (Transport AD) points out that we shouldn't use RADIUS as
a resource management protocol.  She believes that RSVP and NSIS are the
protocols to do resource allocation.  There was an RSVP and Diameter
document that is similar to proposed RADIUS document.  John Loughney
comments that the Diameter QoS document is an individual submission and
not a current AAA WG document.  John will post the link to the RADEXT WG
mailing list for this document, so that we can review it.  Allison
mentions that we don't want to start extending the bandwidth draft to
include a bunch of new things like latency and jitter, but they are
happy with simple rates that are currently defined.  Combining Avi's
bandwidth draft and Hannes' QoS draft would certainly delay the simple
bandwidth parameter attribute that has been requested by other SDOs.  A
comment from 3GPP is that they are depending upon the bandwidth draft to
be complete for reference in their specification release 7, by mid-2006.
The group doesn't believe they should be combined.  Dave Nelson (Chair)
asked what the overlap is between the documents.  Avi points out that
the QoS "blob" includes a bandwidth component and could be used, but
John Loughney and the other authors believe there may be a solution on
how cross reference the documents and avoid overlap.  Dave (Chair)
indicated he would work to facilitate the cross-WG and cross-Area
coordination that will be required to move forward in this area.

--
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, 26 Aug 2005 21:14:56 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-zorn-radius-keywrap-07
Date: Fri, 26 Aug 2005 17:14:10 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Pat Calhoun \(pacalhou\)" <[email-masked]>, "Nancy Winget \(ncamwing\)" <[email-masked]>

> I would ask that all WG members review...

Oh, yes... I should also have requested that comments use the RADEXT
Issue format described on the Issue Tracker web page

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, 26 Aug 2005 21:05:19 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-zorn-radius-keywrap-07
Date: Fri, 26 Aug 2005 17:05:04 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Pat Calhoun \(pacalhou\)" <[email-masked]>, "Nancy Winget \(ncamwing\)" <[email-masked]>

Pat Calhoun writes...

> The chair has recently stated that the document above is in scope of
the
> working group, and I applaud this move given there is market need for
> such a solution. Given that the draft is in its 7th version and
includes
> comments generated through various peer reviews, I would like to
> recommend that the chair do a last call of the draft to move it
forward
> in the standards track.

The co-chairs have stated that key-wrap attributes are within the scope
of the RADEXT charter.

However, we have two submissions that deal with this subject.  The
process we have been using in RADEXT is for individual submissions to be
reviewed as pre-WG work items, with issues being tracked in the RADEXT
Issues Tracker.  Once the issues are resolved, and the drafts reasonably
mature, we then ask for WG consensus to make the documents WG work
items.  In this case we also need to resolve which of the documents to
adopt, or whether to merge them.

This is basically an unfinished discussion from the RADEXT WG session at
IETF-63, and it is appropriate that we continue the discussion on the
mailing list.

Some discussion has already occurred.

I would ask that all WG members review=20

http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt

and

http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt=20

with respect to the key wrap attributes contained therein.  Please
review these documents with the Housley Criteria=20

http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-00.txt=20

in mind.

Discussion of the key wrap issues in general, specific comments on
either draft, and whether one or the other approach to RADIUS key wrap
should become a WG work item, are welcome.

Thanks!

- Dave

--
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, 26 Aug 2005 20:46:18 +0000
Content-class: urn:content-classes:message
Subject: FW:  draft-zorn-radius-keywrap-07
Date: Fri, 26 Aug 2005 13:45:50 -0700
From: "Nancy Winget \(ncamwing\)" <[email-masked]>
To: <[email-masked]>
Cc: "Pat Calhoun \(pacalhou\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>

=20
Resending to the WG as it doesn't seem to be getting posted?
=09
	Nancy.

-----Original Message-----
From: Pat Calhoun (pacalhou)=20
Sent: Friday, August 26, 2005 1:40 PM
To: Radius Ext Mailing List
Cc: [email-masked]; Nancy Winget (ncamwing)
Subject: draft-zorn-radius-keywrap-07

All,

The chair has recently stated that the document above is in scope of the
working group, and I applaud this move given there is market need for
such a solution. Given that the draft is in its 7th version and includes
comments generated through various peer reviews, I would like to
recommend that the chair do a last call of the draft to move it forward
in the standards track.

Thanks,

Pat Calhoun

CTO, Wireless Networking Business Unit

--
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, 26 Aug 2005 18:50:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities negotiation problem statement
Date: Fri, 26 Aug 2005 14:50:51 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba writes...

> In general, most proxies I've seen can be set either to pass along
unknown
> attributes, to only allow a defined set of attributes to pass, or to
> completely replace some or all existing attributes with new ones.

And that will be the behavior for either new mandatory attributes or a
new capability advertisement attribute.  There seems to be no
requirement for capabilities advertisement over mandatory attributes
based on proxy behavior.

--
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, 26 Aug 2005 18:47:09 +0000
Date: Fri, 26 Aug 2005 11:46:48 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Capabilities negotiation problem statement

> Yes, but mandatory attributes were included in Diameter from day-one.
> What happens to the "extended" RADIUS attribute format including the
> Mandatory bit when the RADIUS PDU passes through a proxy server that
> hasn't implemented the "extended" attribute format?
>
> I suppose this is the same as what happens to any other unrecognized
> attributes at proxy servers...  which is what, exactly?

In general, most proxies I've seen can be set either to pass along unknown 
attributes, to only allow a defined set of attributes to pass, or to 
completely replace some or all existing attributes with new ones. 

--
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, 26 Aug 2005 18:19:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities negotiation problem statement
Date: Fri, 26 Aug 2005 14:19:09 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> Mandatory attributes are end-to-end in Diameter, so I assume they
would be
> end-to-end in RADIUS too.  It's only Diameter application negotiation
that
> is hop-by-hop.

Yes, but mandatory attributes were included in Diameter from day-one.
What happens to the "extended" RADIUS attribute format including the
Mandatory bit when the RADIUS PDU passes through a proxy server that
hasn't implemented the "extended" attribute format?

I suppose this is the same as what happens to any other unrecognized
attributes at proxy servers...  which is what, exactly?

--
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, 26 Aug 2005 18:14:44 +0000
Date: Fri, 26 Aug 2005 11:14:21 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Capabilities negotiation problem statement

> I think the only issues that may not be addressed by the Mandatory bit
> (which, BTW, does not yet have WG consensus) that may require some
> additional text would be proxy chain and roaming consortium scenarios.
> If the Mandatory bit is hop-by-hop, then a Proxy Considerations section

Mandatory attributes are end-to-end in Diameter, so I assume they would be 
end-to-end in RADIUS too.  It's only Diameter application negotiation that 
is hop-by-hop. 

--
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, 26 Aug 2005 17:53:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities negotiation problem statement
Date: Fri, 26 Aug 2005 13:52:47 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> Given all of this -- what is the problem statement for Capabilities
> Negotiation, and how does it differ from the problem statement for
> Mandatory/Optional attributes?

I think the only issues that may not be addressed by the Mandatory bit
(which, BTW, does not yet have WG consensus) that may require some
additional text would be proxy chain and roaming consortium scenarios.
If the Mandatory bit is hop-by-hop, then a Proxy Considerations section
will likely be required to describe behavior in those kinds of
deployments.  Avi's draft intends to cover end-to-end capabilities
advertisement.  If the Mandatory bit can be made end-to-end, or suitable
behavior in roaming deployments can be described, then maybe we don't
need capabilities advertisement.

--
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, 26 Aug 2005 17:23:03 +0000
Date: Fri, 26 Aug 2005 10:22:31 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Capabilities negotiation problem statement

In looking at the Capabilities Negotiation draft, I was struck by the 
vagueness of the problem statement. 

RADIUS has existed without capabilities negotiation for more than a decade 
now.  As far as I know,  there are not even any Vendor-Specific 
implementations.  Given the level of experimentation on other areas (see 
RFC 2882) this is surprising.  If this problem is so important and 
pervasive (as the draft argues) how come the industry seems to have 
ignored it for a decade, without creating huge problems? 

The answer is that RADIUS already enables NASes and RADIUS servers with 
different capabilities to interoperate.  For example, RFC 2865 allows a 
NAS to ignore attributes it does not understand, and this is how most 
existing RADIUS client implementations behave.  This allows a RADIUS server 
to send attributes to a NAS without having to worry about whether it 
understands them, as long as those attributes can be safely ignored. 

Similarly, a NAS does not need to know whether a RADIUS server understands 
an attribute in order to send it, as long as the attribute can be safely 
discarded by the RADIUS server.

As a result, the real issue is specification of mandatory attributes, 
not "capability-negotiation" per se.  Note that a proposal for 
mandatory/optional marking has recently been put forward in the Design 
Guidelines document. 

Some of the cases where the mandatory/optional issue comes up include: 

a. Where the RADIUS server REQUIRES the NAS to understand an attribute in 
order for access to be provided.  A classic case of this is use of 
security attributes (VLANs, Filters, etc.).  A NAS cannot safely 
ignore a security attribute sent by the RADIUS server.  

This situation is the most common one;  there are documented cases 
where existing behavior has resulted in substantial financial losses.  
At the same time, the behavior of existing implementations can't be 
changed retroactively. 

b. Where the NAS REQUIRES that the RADIUS server send an attribute in 
order for it to provide access. 

Other cases are already handled by the RADIUS protocol as it exists today: 

c. Where the RADIUS server requires an attribute that the NAS does not 
provide in an Access-Request, the server can send an Access-Reject, 
potentially including an Error-Cause (101) attribute.  If the NAS 
understands the Error-Cause attribute, it can correct the problem. 

In looking at the proposal within the Design Guidelines document, it 
appears to me that the Mandatory/Optional functionality described there 
potentially handles both cases a) and b).  In case a), a RADIUS server can 
send an attribute with the "M" bit set.  In case b), a NAS can send an 
attribute with the "M" bit set. 

Given all of this -- what is the problem statement for Capabilities 
Negotiation, and how does it differ from the problem statement for 
Mandatory/Optional attributes? 

--
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, 25 Aug 2005 14:43:58 +0000
Date: Thu, 25 Aug 2005 07:43:44 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt

> Please post comments to the RADEXT WG in the format defined on the
> RADEXT WG Issue list:
> 
> http://www.drizzle.com/~aboba/RADEXT/

It would also be helpful if the authors of the RADIUS Location document 
would post the resolution of the 13 issues that have already been filed, 
so we can figure out which ones are now closed.  

--
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, 25 Aug 2005 14:25:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Thu, 25 Aug 2005 10:22:09 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> Review of draft-ietf-geopriv-radius-lo-04.txt

Thanks, Bernard.  I'd like to request that the entire WG take some time
to review this document.  I've been informed that it is getting ready
for WGLC in the GEOPRIV WG, and it would be well for RADEXT WG comments
to be received at this time.  So...

This is a request for cross-WG review of the document "Carrying Location
Objects in RADIUS".  The document is available for inspection here:

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt
=20
Please post comments to the RADEXT WG in the format defined on the
RADEXT WG Issue list:

http://www.drizzle.com/~aboba/RADEXT/

Please send comments by Friday September 30, 2005.  (But sooner is
better.)

--
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, 25 Aug 2005 14:12:22 +0000
Date: Thu, 25 Aug 2005 17:12:29 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked], Russ Housley <[email-masked]>
Subject: Re: RADIUS keywrap attributes

Bernard Aboba wrote:

>>o   Do we expect to find a solution that can reasonably
>>be expected to fit existing networks without a lot
>>of additional effort from vendors/network managers?
>>(I don't know, but this is crucial in order to make
>>a real impact.)
>>    
>>
>
>I don't think that it is required for the solution be deployed by 
>everyone, by the segment of people who want/need it.  
>  
>
Yes, I meant to say that. Of course, for IETF to
do work in this area I think we should expect
the segment to be large enough to warrant the
work. Maybe "everyone who sells to DoD" is
sufficiently large :-)

--Jari

--
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, 25 Aug 2005 14:07:51 +0000
Date: Thu, 25 Aug 2005 07:07:28 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: Russ Housley <[email-masked]>
Subject: Re: RADIUS keywrap attributes

> For instance,
> I think the Diameter redirect scheme is pretty good, but its
> very likely that most or even all usage is going to be through
> proxies, just as we already do today. 

What was accomplished in RFC 4072 (Diameter EAP) was to provide a 
secure mode of operation.  Not everyone will use this mode, but defining 
it means that users who want it will have it available.  

> o   Do we expect to find a solution that can reasonably
> be expected to fit existing networks without a lot
> of additional effort from vendors/network managers?
> (I don't know, but this is crucial in order to make
> a real impact.)

I don't think that it is required for the solution be deployed by 
everyone, by the segment of people who want/need it.  

--
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, 25 Aug 2005 12:56:44 +0000
Content-Class: urn:content-classes:message
Subject: RE: Items from the IETF-63 meeting requiring confirmation.
Date: Thu, 25 Aug 2005 15:56:08 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Murtaza Chiba" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Murtaza Chiba
> Sent: Thursday, August 25, 2005 2:50 AM
> To: Nelson, David
> Cc: [email-masked]
> Subject: Re: Items from the IETF-63 meeting requiring confirmation.
>=20
> David et al.,
>=20
>=20
> >=20
> > 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and=20
> > draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, that the=20
> > drafts will be revised to use terminology that is=20
> consistent with the=20
> > base document, RFC 3576.
> >=20
>=20
> Would like to point out that the new terms introduced do use=20
> the terms as found in the RFC3576 as part of its definition. =20
> These new terms are necessary to make it unambiguous as to=20
> what the MIB objects are referring to.  Else, we will have a=20
> strange situation where the dynauth-client-mib will have=20
> objects that are named radiusServer and dynauth-server-mib=20
> having objects name radiusClient at the top level, which IMO=20
> is most likely to be more confusing.
>=20
> Further, the intent for the new terms has been misrepresented=20
> as being an attempt to clarify the RFC3576 rather than its=20
> original intent which was to have unambiguous less confusing=20
> object names and text.
>=20
> If, however, the group at large feels that the terms MUST=20
> change then we
>   ask how to make the terms/text less confusing, bearing in=20
> mind that the roles of the RADIUS Server and Client are=20
> actually reversed in the case of the RFC3576.
>=20
> Thanks,
> Murtaza
>=20

My personal opinion, as MIB reviewer is that the terminology and the
naming convention used in the two MIB documents is not that confusing.
As a manager I do expect that a client exposes information known to the
client about the servers it registers with, and that a server exposes
information it is aware about concerning the clients accessing the
server.=20

Regards,

Dan

--
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, 25 Aug 2005 08:22:02 +0000
Date: Thu, 25 Aug 2005 11:21:56 +0300
From: Jari Arkko <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC: "Glen Zorn (gwz)" <[email-masked]>,  Bernard Aboba <[email-masked]>, [email-masked], "Zhang, Tiebing" <[email-masked]>,  Russ Housley <[email-masked]>
Subject: Re: RADIUS keywrap attributes

Re: charter prohibition on new security mechanisms. I tend to agree
with David on this. While we do not want to develop (say) RADIUS-over-TLS,
addressing the security issues in specific attributes is within scope,
if those attributes themselves on the charter.

Re: draft-zorn vs. draft-aboba. I think that from a 10.000 ft perspective
these are really the same thing, just different in details and have
some different deployment impacts. Perhaps we can leave the
choice between them until we've decided if we need this work
to begin with.

Re: IESG expectations, charter constraints, NIST requirements:
I think its pretty obvious that we are dealing with several
sets of different types of requirements, not all of
which always match the real world out there. For instance,
I think the Diameter redirect scheme is pretty good, but its
very likely that most or even all usage is going to be through
proxies, just as we already do today. But having this scheme
at least made it possible to publish an IETF RFC, and even
the non-redirect usage of Diameter EAP is much better than
the vendor specific attributes that most people use today.
I think it would be useful to ask ourselves if we can make
a similar positive step, not necessarily reaching all goals
but improving what we have today. At the end of the day,
that's what matters. So, I have some questions:

  o   Do we believe we have an issue in the existing usage?
       (I think we do)

  o   Do we have a clear target for this work?
       (Yes we do, wireless LANs.)

  o   Does it fit our overall plan for the system that we
       want to provide?
       (Yes, its the missing part in the network access
       authentication system.)

  o   If we do something, will that actually be deployed
       by a significant number of users, or are we using it
       just as an checkbox item to pass through IESG/IEEE/
       NIST/unsuspecting customer?
       (Here I think we need more input...)

  o   Do we expect to find a solution that can reasonably
       be expected to fit existing networks without a lot
       of additional effort from vendors/network managers?
       (I don't know, but this is crucial in order to make
       a real impact.)

  o   Do we have the manpower/expertise to do this?
       (You tell me.)

--Jari

--
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, 25 Aug 2005 07:25:22 +0000
Date: Thu, 25 Aug 2005 10:25:12 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Alper Yegin <[email-masked]>,  [email-masked]
Subject: Re: RFC 2867/2868 question

Bernard Aboba wrote:

>>I have a question though: It seems like we can use either RADIUS
>>Access-Request/Answer, or RADIUS Accounting Request/Answer for setting
>>up the compulsory tunnel. What is the rationale behind this
>>"flexibility"? When would you recommend using one or the other?
>>    
>>
>
>I am not sure what "flexibility" you are talking about.  RADIUS Accounting 
>is not an authentication/authorization mechanism, it is an accounting 
>protocol.  RFC 2867 attributes are used to account for tunnel usage after 
>they have been set up; the RFC 2868 attributes are used to authorize 
>compulsory tunnels.  
>  
>
There's some flexibility in using the same attributes for
incoming or outgoing tunnels, and for reporting capabilities
vs. requesting a specific action. (I'm personally not too
fond of this flexibility.)

But all of this happens within the auth/authz part i.e.
Access-Request/Challenge/Response, not within accounting.

--Jari

--
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, 25 Aug 2005 05:46:19 +0000
Content-class: urn:content-classes:message
Subject: RE: Items from the IETF-63 meeting requiring confirmation.
Date: Thu, 25 Aug 2005 11:15:16 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Murtaza Chiba \(mchiba\)" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Please see inline with the tag <Nagi>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Murtaza Chiba (mchiba)
Sent: Thursday, August 25, 2005 5:20 AM
To: Nelson, David
Cc: [email-masked]
Subject: Re: Items from the IETF-63 meeting requiring confirmation.

David et al.,

>=20
> 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and=20
> draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, that the=20
> drafts will be revised to use terminology that is consistent with the=20
> base document, RFC 3576.
>=20

<Murtaza> Would like to point out that the new terms introduced do use
the terms as found in the RFC3576 as part of its definition.  These new
terms are necessary to make it unambiguous as to what the MIB objects
are referring to.  Else, we will have a strange situation where the
dynauth-client-mib will have objects that are named radiusServer and
dynauth-server-mib having objects name radiusClient at the top level,
which IMO is most likely to be more confusing.

<Nagi> Does it make sense to rename it as "radiusClient" while the other
MIBs call "radiusAuthenticationClient". IMHO, it makes a lot of sense to
call them as they are. i.e., "radiusDynAuthServer" and
"radiusDynAuthClient". The only difference I see is that the DynAuth
MIBs have the formal "Terminology" section and there is a justification
why it is there as I mentioned in my other e-mail.

<Murtaza> Further, the intent for the new terms has been misrepresented
as being an attempt to clarify the RFC3576 rather than its original
intent which was to have unambiguous less confusing object names and
text.

<Nagi> As Murtaza correctly pointed it, the terminology is not needed to
define in the RFC-3576. It is the same with RFC-2865 and RFC-2618.

<Murtaza> If, however, the group at large feels that the terms MUST
change then we
  ask how to make the terms/text less confusing, bearing in mind that
the roles of the RADIUS Server and Client are actually reversed in the
case of the RFC3576.

<Nagi> Would like to know WG opinion as to how the Dynauth MIBs deviated
from the other MIBs and how better we can handle it.

Thanks
Nagi.

--
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, 25 Aug 2005 05:34:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Items from the IETF-63 meeting requiring confirmation.
Date: Thu, 25 Aug 2005 11:03:56 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

All,

Please see below my view points on the Dynauth MIBs for issue 92.

> 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and
draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, > that the
drafts will be revised to use terminology that is consistent with the
base document, RFC 3576.

First I would like to request the group to focus on the below points and
not getting distracted or drawing conclusions on the other previous
discussions.

- Take for instance, Radius Authentication Client MIB, RFC-2618(Same is
true with the Radius Accounting MIB as well). You can observe that there
is the term "Radius Authentication Client" everywhere but you may wonder
where is this terminology coming from? If you refer to the RFC-2865, all
you find is Radius client or server but not Radius *Authentication*
client/server.

 =20
- However, if you read the "Overview" section of the RFC-2618, you find
the below and I wonder if anybody has problems to understand what
exactly "Radius Authentication Client" is and who is supposed to
implement "Radius Authentication Client MIB". IMO, the term "Radius
Authentication Client" in RFC-2618 makes a lot of sense though there was
*no need* to introduce this term in the base RFC-2865.

  For your quick ref, snippet from RFC-2618, Overview section.
  =20
   "The RADIUS authentication protocol, described in [16], distinguishes
   between the client function and the server function. In RADIUS
   authentication, clients send Access-Requests, and servers reply with
   Access-Accepts, Access-Rejects, and Access-Challenges.  Typically NAS
   devices implement the client function, and thus would be expected to
   implement the RADIUS authentication client MIB, while RADIUS
   authentication servers implement the server function, and thus would
   be expected to implement the RADIUS authentication server MIB."

- Now, if you see the Dynauth MIBs, no wonder, you observe the Dynamic
Authorization Server/Client terms. Base protocol talks about the Dynamic
Authorization Protocol(RFC-3576) though *no need* to introduce the
Dynamic Authorization Client/Server.

- The only extra section for Dynauth MIBs is to clarify "DAC" and "DAS"
because that in this particular case (in contrast with Radius
Authenticatio/Accounting Client/Server) the client and server
functionality is reversed.

Conclusion:

Terminology is never defined in the base RFCs but introduced
informally(not noted in the bold letters that says "Terminology") in the
respective MIBs as and when appropriate. Like the other MIBs, Dynauth
MIBs also have the overview section that clarifies the terminology. In
the case of the Dynauth MIBs, since the client/server functionality is
reversed, we highlighted/clarified in the Terminology section as per the
WG suggestion.

Had the Dynauth protocol operate on a regular "pull" model instead of
"push" model(i.e., authentication and accounting requests are initiated
by the NAS and acts as client. For the Dynauth, the Radius server
initiates the requests and NAS acts as a server), then we would have
observed *absolutely no difference* with the other MIBs. For instance,
if I could have referred the NAS as a "Dynamic Authorization Client"
then you wouldn't have even noticed the difference between the other
MIBs and Dynauth MIBs.

The terminology has always been introduced/defined in the MIBs. Hence I
don't see a need to define this terminology in the RFC-3576bis/Issues
and Fixes document.=20

Hope I can convince atleast some of you. We need your vote especially
when you are in agreement  :-)

Thank you,
Nagi.

--
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, 25 Aug 2005 01:28:02 +0000
Date: Wed, 24 Aug 2005 18:27:30 -0700
From: Murtaza Chiba <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Items from the IETF-63 meeting requiring confirmation.

Bernard,

Bernard Aboba wrote:
>>If, however, the group at large feels that the terms MUST change then we  ask
>>how to make the terms/text less confusing, bearing in mind that the roles of
>>the RADIUS Server and Client are actually reversed in the case of the RFC3576.
> 
> 
> RFC 3576 uses the terms "NAS" and "RADIUS server" to refer to the
> entities, although the term "RADIUS client" is used occasionally as well.
> My overall impression on rereading RFC 3576 is that is fairly clear about 
> what entities are involved and what they do.  I think that using the 
> term "NAS" instead of "RADIUS client" most of the time was helpful in that 
> regard. 
> 
> Maybe something like this might help here?  Might it make sense to have a 
> "Dynamic Authorization NAS MIB" and a "Dynamic Authorization Server MIB"? 

The NAS IS the Dynamic Authorization "Server" as described in RFC3576. 
That is, the NAS actually services requests from a client (RADIUS server).

Besides Dynamic Authorization Server is new term DAS that has been used 
in the MIBs.

So your proposal is more confusing really.

Murtaza

> Reducing the usage of the term "client" might help the clarity. 

--
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, 25 Aug 2005 01:12:42 +0000
Date: Wed, 24 Aug 2005 18:12:19 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Murtaza Chiba <[email-masked]>
cc: [email-masked]
Subject: Re: Items from the IETF-63 meeting requiring confirmation.

> If, however, the group at large feels that the terms MUST change then we  ask
> how to make the terms/text less confusing, bearing in mind that the roles of
> the RADIUS Server and Client are actually reversed in the case of the RFC3576.

RFC 3576 uses the terms "NAS" and "RADIUS server" to refer to the
entities, although the term "RADIUS client" is used occasionally as well.
My overall impression on rereading RFC 3576 is that is fairly clear about 
what entities are involved and what they do.  I think that using the 
term "NAS" instead of "RADIUS client" most of the time was helpful in that 
regard. 

Maybe something like this might help here?  Might it make sense to have a 
"Dynamic Authorization NAS MIB" and a "Dynamic Authorization Server MIB"? 
Reducing the usage of the term "client" might help the clarity. 

--
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, 24 Aug 2005 23:50:13 +0000
Date: Wed, 24 Aug 2005 16:49:38 -0700
From: Murtaza Chiba <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC: [email-masked]
Subject: Re: Items from the IETF-63 meeting requiring confirmation.

David et al.,

> 
> 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and
> draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, that the
> drafts will be revised to use terminology that is consistent with the
> base document, RFC 3576.
> 

Would like to point out that the new terms introduced do use the terms 
as found in the RFC3576 as part of its definition.  These new terms are 
necessary to make it unambiguous as to what the MIB objects are 
referring to.  Else, we will have a strange situation where the 
dynauth-client-mib will have objects that are named radiusServer and 
dynauth-server-mib having objects name radiusClient at the top level, 
which IMO is most likely to be more confusing.

Further, the intent for the new terms has been misrepresented as being 
an attempt to clarify the RFC3576 rather than its original intent which 
was to have unambiguous less confusing object names and text.

If, however, the group at large feels that the terms MUST change then we 
  ask how to make the terms/text less confusing, bearing in mind that 
the roles of the RADIUS Server and Client are actually reversed in the 
case of the RFC3576.

Thanks,
Murtaza

--
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, 24 Aug 2005 22:05:15 +0000
Content-class: urn:content-classes:message
Subject: Items from the IETF-63 meeting requiring confirmation.
Date: Wed, 24 Aug 2005 18:04:07 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The following is a list of items on which rough consensus was obtained
at the RADEXT WG session at IETF-63, and upon which confirmation on the
RADEXT WH mailing list is sought.

1.) With regard to draft-ietf-radext-digest-auth-03, RADEXT Issues 123,
124, that the draft will include support for both modes of operation,
nonces from client and nonces from server, and that the companion
Diameter draft will take the same approach (pending consensus in the AAA
WG).

2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and
draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, that the
drafts will be revised to use terminology that is consistent with the
base document, RFC 3576.

3.) With regard to draft-nelson-rfc2618bis-01.txt,
draft-nelson-rfc2619bis-01.txt, draft-nelson-rfc2620bis-01.txt and
draft-nelson-rfc2621bis-01.txt that the drafts will be accepted as
RADEXT WG work items and moved to WGLC soon after the -00 versions are
posted.

4.) With regard to draft-lior-radext-end-to-end-caps-01, that the
document will be accepted a WG work item.

Please take a moment to review these items and reply to the list by
Wednesday, August 31, 2005 if you do not concur with these WG decisions
taken at the IETF-63 meeting.

--
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, 24 Aug 2005 21:35:12 +0000
Date: Wed, 24 Aug 2005 14:35:00 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Pre working-group work item review of RADIUS Bandwidth document

This is a request for review of the document "Network Bandwidth Parameters 
for RADIUS".  The document is available for inspection here:

http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capability-01.txt

Please post comments to the RADEXT WG in the format defined on the RADEXT 
WG Issue list:

http://www.drizzle.com/~aboba/RADEXT/

Please send comments by Friday September 23, 2005. 

--
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, 24 Aug 2005 21:08:26 +0000
Date: Wed, 24 Aug 2005 14:08:01 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Review of draft-ietf-geopriv-radius-lo-04.txt

Review of draft-ietf-geopriv-radius-lo-04.txt

The RADEXT WG Issues page discloses that 13 issues remain open against
this document:
http://www.drizzle.com/~aboba/RADEXT/

Based on a preliminary review of the -04 version, it appears that some
of these open issues still have not been addressed.  Some notes below: 

Section 2

"  Furthermore, the authors believe that there is a relationship
   between the location of the network and the location of the entity
   that triggered the network access authentication.  Knowing the
   location of a network (where the user or end host is attached to)
   might in many networks also reveal the location of the user or end
   host.  In some networks it is even possible to provide a accurate
   location of the user or end host.  A similar assumption is also made
   with regard to the location information obtained via DHCP (see for
   example [4]).  This information might be used by applications in
   other protocols (such as SIP [12] with extensions [13]) to indicate
   the location of a particular user even though the location "only"
   refers to the location of the network or equipment within the
   network.  The assumption here is also that the location of the
   network has some relationship to the location of the end host (and
   subsequently to a user).  This assumption might not hold in all
   scenarios.  Nevertheless, it seems to be reasonable."

RADEXT Issue 27 points out that this assumption is
not correct -- the location of the peer and the location of the
NAS are not the same thing.  There are APs today that are capable
of providing the location of the user with a high degree of accuracy. 
Can those APs use this specification to provide the NAS and peer
location information independently? 

Section 3.2

RADEXT Issue 74 points out problems with the way this document uses
RFC 3576.  

   The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request.

This paragraph appears to retroactively update RFC 3576.  

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

This also sounds like an update of RFC 3576.  Why should RFC 3576 
behavior be different when location attributes are included? 

More fundamentally, why does RFC 3576 need to be used to obtain location 
information in mid-session when the same info is available in Accounting 
packets?  Or is the issue that location data may not be included in 
Interim accounting information? I didn't notice a way that the RADIUS
server can configure the way the NAS sends location info (e.g. don't send 
in interims, send at a given interval different from the interim interval, 
etc.)

Section 4

   How the network obtains the user's
   location information is out of the scope of this document. 

See RADEXT Issue 27.  Obtaining the peer location is one of the
fundamental usage scenarios for RADIUS-based location information.
If this is out of scope for this specification, a different 
specification will be needed to address that issue.  Why not handle
both issues within the same document? 

Section 8

   The capability attribute allows the RADIUS client to indicate whether
   civic and/or geospatial location information can be provided to the
   RADIUS server.  This is useful to avoid sending location information
   with every request if no further out-of-band arrangements are made
   with regard to the transport of location information.  The AAA server
   uses the capability attribute to indicate that the AAA client has to
   provide civic and/or geospatial location information as part of this
   particular protocol exchange.  If the AAA server does not send a
   capability attribute then the AAA client MUST NOT return location
   information.  The user's authorization policies MUST be consulted by
   the AAA server before requesting location information delivery from
   the AAA client.  If the AAA server encounters that the AAA client
   does not support the desired location information it might respond
   with an Access-Reject with the corresponding error cause attribute
   (with the Location-Info-Required error code).

The above paragraph seems vague about the nature of the capability
negotiation.  Terms like "might respond" imply a range of
acceptable behaviors, which could result in interoperability problems. 

Since Access-Requests are initiated by the NAS, there is no way
for the NAS to know beforehand whether a given RADIUS server requires
location information or not.  However, a NAS might default to not
sending location information and then if the AAA server sends back
an Access-Reject with a Location-Info-Required error code, then it
could enable it.  This seems to handle the case where the RADIUS
server requires location (e.g. won't grant access without it). 

Based on the rest of Section 8, it appears that there are other
scenarios in which the RADIUS server might like location information 
if available, but does not require it.   In these cases, the 
RADIUS server could send back an Access-Accept with a request for
location information, specifying what kind of location it is
asking for (NAS or peer). If the NAS does not understand
the attribute it will ignore it.

Overall, it is not clear to me why the Capability attribute is needed, or 
if so, what the goal is.  

Section 11

Why is a capability attribute needed in an Access-Challenge?  Why
is "Location-Info-Required" a new attribute rather than a value
of Error-Cause?  Why are Basic-Policy-Rules, Extended-Policy-Rules,
Capability and Location-Info-Required attributes allowed in an 
Access-Reject? 

--
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, 24 Aug 2005 18:13:21 +0000
Date: Wed, 24 Aug 2005 11:13:04 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: Re: RADIUS-GEOPRIV and Capabilities

> draft-lior-radext-end-to-end-caps-01.txt document) i would like to
> confirm that 
> a) it is ok to define a registry in the radius-geopriv document and 
> b) to register two values (require for radius-geopriv)

BTW, does the current GEOPRIV-RADIUS location document address the issues 
that were raised in RADEXT WG review? 

It is not clear to me that the kind of capability  negotiation you are 
proposing makes sense in this application.  RADIUS accounting servers can 
handle unknown attributes. Since a RADIUS server may be doing 
location-based authorization, a RADIUS client may need to send location 
or its Access-Request will be rejected.  In that situation, the RADIUS 
client needs to send location before negotiation is possible. 

It seems like the issue could be handled without having the client 
announce capabilities at all.  The client is set up by default to either 
send or not send location information.  If the server has a problem with this, 
it rejects the request and indicates that location data is needed.  Since 
Access-Reject messages cannot request a service, this probably needs to be 
accomplished via an error-message, rather than inclusion of a location 
attribute. 

--
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, 24 Aug 2005 17:45:04 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] draft of ISMS charter
Date: Wed, 24 Aug 2005 13:44:21 -0400
From: "Nelson, David" <[email-masked]>
To: "Juergen Quittek" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Juergen Quittek writes...

(Cross posted to RADEXT and ISMS WG lists)

> --On 8/22/2005 10:59 PM +0200 David B Harrington wrote:
>=20
> > I think the definiton of RADIUS attributes for management belongs in
> > RADEXT.
>=20
> I also would prefer this option.
> Do you think we should bring the issue to the RADEXT mailing list?

Yes.

As I have already indicated, we have an existing draft under
consideration in RADEXT that contains this type of new attribute.  It is
fairly close to being ready for adoption as a WG work item.  We could
use this existing draft, or we could break it out as separate draft.

I think the important things for ISMS to communicate to RADEXT are:

(a) That ISMS has a requirement for standardization of a RADIUS
attribute for the purpose of providing authorization of SNMPv3 access to
the NAS (managed entity) via the ISMS mechanisms (i.e. SSH, etc.).

(b) That the attribute will be used in the ISMS security method to map
into one or more SNMP security parameters, such as securityName or
groupName.

(c) The desired milestone date for sending such an I-D to the IESG for
approval, that aligns with the ISMS WG milestones.

Since, I've already cross posted this message to RADEXT, we can use this
as the starting point for discussions.

--
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, 22 Aug 2005 21:33:23 +0000
Date: Mon, 22 Aug 2005 14:33:09 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alper Yegin <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 2867/2868 question

> I have a question though: It seems like we can use either RADIUS
> Access-Request/Answer, or RADIUS Accounting Request/Answer for setting
> up the compulsory tunnel. What is the rationale behind this
> "flexibility"? When would you recommend using one or the other?

I am not sure what "flexibility" you are talking about.  RADIUS Accounting 
is not an authentication/authorization mechanism, it is an accounting 
protocol.  RFC 2867 attributes are used to account for tunnel usage after 
they have been set up; the RFC 2868 attributes are used to authorize 
compulsory tunnels.  

--
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, 22 Aug 2005 20:51:57 +0000
Content-class: urn:content-classes:message
Subject: Draft RADEXT WG Minutes from IETF-63
Date: Mon, 22 Aug 2005 16:50:25 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Please review this draft of the minutes of the RADEXT WG session at =
IETF-63.  Kindly reply to the list with any errors or omissions you may =
notice, by the end of this week (August 26).  Thanks!

-------------------------------------------------------------------------=
---

IETF-63 RADEXT WG Minutes

Scribes: Paul Congdon, Greg Weber (Editor: Dave Nelson)
No jabberer.  (Later Hannes Tschofenig joined the jabber room.)
Bluesheets started.
No agenda changes requested.

Presentations and agenda online at:
  http://www.drizzle.com/~aboba/IETF63/radext/
RADEXT Issues Tracker location:
  http://www.drizzle.com/~aboba/RADEXT
Streaming audio archive location:
   =
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf63/ietf63-ch5-wed=
.mp3.1 [start time index: 20:34]

Brief status of WG work items:
- 2684bis in AD follow-up
- Dynauth MIBs completed WGLC, 9 issues
- CUI in AD follow-up
- Digest Auth completed WGLC xx issues
- 802 Extensions in WGLC, 3 issues (so far)

Presentations:

- RFC2684 bis presented by Jari Arkko.

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt

Problem with internationalization found in IESG review.  Added =
clarifying text for ABNF vs. document text requirements and the use of =
UTF-8 vs. IDN-unware ASCII for the realm part.  Revision back to IESG =
for approval -- very soon, e.g. about a week.   Realm strings will be =
IDN unaware (no "!").

- Chargeable User Identity presented by Avi Lior.

http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-=
03.txt

All issues have been addressed in the current version of the document.  =
Several SDOs are interested in this draft - WiMAX is one who will be =
submitting a liaison letter to IETF for this.  Pasi Eronen clarifies =
that this document is in AD evaluation stage and not at the IESG.  =
Bernard may need to update the web-site to indicate the appropriate =
document status. ID Tracker from IETF homepage is definitive on status.

- Digest Authentication update by Wolfgang Beck.

http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt

Diameter compatibility is the current main issue with the document.  =
There is also an issue regarding client-side nonce generation when =
interoperating with Diameter - additional text will be added to address =
this.  We could move forward two ways; one it get client side nonce =
generation added to diameter, or simply drop this.  The 3GPP2 liaison =
would like to see client side nonce generation remain because they =
currently use it.  Avi Lior recommends that we operate in both modes of =
operation and when working with Diameter, and get Diameter to update to =
support client side nonce generation.  The 3GPP2 people are waiting for =
an RFC number on this document so they can publish their spec.  The =
security considerations need to be updated to discuss what to do when =
realm check fails.  There were also some typos that will be corrected.  =
Desire to get -04 version out shortly after IETF-63.

- Dynamic Authorization MIBs - Greg Webber speaking for authors who =
could not attend.

http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-=
01.txt

http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-=
01.txt
=20
These MIBs are companions to RFC 3576.  They are expected to be =
completed by the end of the year.  Issues 96/97 have been resolved and =
are simply editorial in nature.  Issue 105 resolution relates to where =
the MIBs are to be located in the OID tree.  It is believed that new =
MIBs should be rooted off of mib-2 and the authors are willing to make =
the change to support this.  Issue 92 is the most controversial.  A few =
new terms are defined by this document; DAC and DAS.  It was suggested =
to match RFC 3576 and not introduce new terms in MIB, however the terms =
are embedded in all of the object names.  It is still the belief of the =
WG that the terms should be consistent and it sounds as though the =
object names will be globally searched and replaced.  Bernard Aboba: RFC =
3576bis would be within WG charter, and we could address the terminology =
issues there.  That would mean either delaying the MIBs or revising them =
later.

- 802 Extensions draft presented by Paul Congdon.

http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt

Discussed recent changes, but not current issue status.  Changes include =
removal of controversial (Diameter-like) extended attribute types, no =
new data-types or M-bit, fleshed out the NAS-Filter-Rule,  can now =
specify L2 encapsulations, removed IP-redirection rule type in favor of =
tunneling.  Among the interested parties are TNC of TCG, 3GPP, WiMAX =
(hot-lining). Glen Zorn questioned the chairs on why this document was =
so quickly moved to last call.  The chairs believe that the previous =
issues in the individual submissions were sufficiently resolved and =
there being a number of SDOs waiting on this document see the need to =
expedite the review and closure of this document.  WG last call closes =
on Aug 10th.  There was a question regarding when the wireless =
attributes would be documented.  There is a -00 draft on WLAN attributes =
to be discussed on this later in the meeting.

- RADIUS IPv6 MIBs discussed by Dave Nelson.

http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt

http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt

http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt

http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt

New textual conventions for address objects have been included.  Review =
comments from the MIB Doctors have been resolved in the -01 revisions. =
The drafts UPDATE their predecessor RFCs, deprecate old tables (not =
doing table augmenting anymore), added new tables to mirror old ones, =
added specific usage guidelines new IP address objects.  The question of =
whether these should be WG work items was posed and no objections were =
heard.  The RADEXT -00 drafts will be created and moved to WG last call.

- Common Radius Implementation Issues and Fixes presented by Dave =
Nelson.

http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt

The document was created based upon a long laundry list of issues that =
have been discussed on the mailing list.  This document identifies many =
of the problems identified in the field and makes suggestions to resolve =
the problems.  Areas discussed include:=20
  - Proper use of the state attribute=20
  - Request ID supplementation alternative=20
  - Re-transmit schemes=20
  - How to handle overload conditions=20
  - Clarification of accounting attribute updates=20
  - Clarification of using multiple Filter-ID attributes=20
  - Treating access-accept for unknown services as a reject=20
  - Avoiding sending VSAs to a NAS that doesn't understand them
                                                             =20
A question about this recommendation is how to reliably detect supported =
vs. unsupported VSAs.  The capabilities attribute is a possible =
solution.  Glen Zorn suggested the possibility of a version number.  =
Since this is just -00, it was suggested to post issues against the =
document.  It was noted that some issues were currently in the tracker =
but not yet included in the draft.

  - Corrections to RFC 2869, section 2.2 regarding miss-stated =
Access-Challenge.=20
  - Handling multiple services=20
  - Defining how to calculate Message-Authenticator for Disconnect, COA =
and others=20
  - Authorize only discussion

There were some questions of how this document should progress.  The =
document is useful, but perhaps an RFC 3576bis additionally needs to be =
created.  Also, some of the issues are against earlier RFCs as well. =
These are standards track and may be more difficult to update.  This =
document is intended to address existing and past issues.  Another =
forward looking document discusses future issues. Other issues not =
addressed were NASes with multiple IP addresses and accounting interval =
updates.  These should be included and consensus on a solution for these =
needs to be proposed.

- RADIUS Attribute Design Guidelines presented by Greg Weber.

http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-00=
.txt

This is a forwarding looking document addressing design recommendations =
for new attributes.  This document describes what is considered a good =
attribute design and reviews the current RADIUS data types, as well as =
the divergence in the Standard and Vendor Specific data models.  A few =
have reviewed this document so far.  The current document does include =
some recommendations, but these are straw-man recommendations.  The =
motivation for this document is to get better alignment with data models =
in vendor attributes, address attribute space exhaustion and align =
better with diameter.  The scope of the document includes consideration =
for backward compatibility, existing VSAs, supporting the existing =
transport, non-AAA applications and Diameter compatibility. The document =
straw-man proposes a single standards base format for VSAs as a =
recommendation.  The document also includes recommendations on when =
particular formats should be used and when to use existing VSA format =
verse the new one.  Lots to do on this draft.  Avi Lior agrees this =
document is a good starting point and is willing to work on the draft.  =
There was a question whether SDOs should be differentiated from Vendors, =
but the group doesn't believe so.  There was a question whether IANA =
considerations are included, but the authors believe this is already =
spelled out elsewhere.  Glen Zorn asks if it was considered to extend =
the size of RADIUS attributes rather than dealing with fragmentation.  =
Greg Weber did not consider this because he felt it would be beyond the =
scope of the charter.

- WLAN Attributes presented by Jari Arkko.

http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt

The list of attributes that were removed from the 802 Extensions draft =
was presented.  There is some overlap that needs to be discussed.  =
[Technical difficulties with slides caused us to move forward to the =
next topic.]  Upon return, some relationships to the EAP keying draft =
were described.  A list of key management attributes were described and =
the issues.  Privacy can be addressed similar to NAI and by omitting =
Peer-ID and Server-ID attributes.  Key-wrap options were described as =
three choices; AES key wrap, a Key Encryption Key (Zorn draft) or IPSec. =
 The later is not used in industry.  The key-wrap options may be =
difficult to resolve.  The questions on this document are whether this =
should be a WG item and how to solve the privacy and key-wrap problems.

- RADIUS attributes for Cryptographic Keys presented by Glen Zorn.

http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt

The motivation for this draft was to allow RADIUS to be used in certain =
government environments.  While RADIUS isn't a key provisioning =
protocol, there are keys that are passed around in RADIUS and perhaps =
aren't wrapped securely enough.  Several editorial changes were made in =
the -07 revision, but also HMAC-MD5 was removed and other key transport =
attributes (e.g. MPPE-xxx) were outlawed if the same data is also =
transferred in the new attributes.  Questions about how keys are =
transferred to the client - hop-by-hop or end-to-end?  They are passed =
along the path in the way they are set-up - may be hop-by-hop.  Glen =
plans to add AES-CMAC and some other technical changes in the -08 =
revision.

- General WG discussion on key-wrap issues.

Glen Zorn points out that the keying issue is not just an 802.11 or =
Wireless problem.  Also, Glen points out that IPSec is inappropriate as =
a protection mechanism for an application level protocol.  Glen believes =
NIST is in agreement that IPSec is not appropriate for this use.  Nancy =
Cam-Winget from Cisco summarized the NIST meeting that took place back =
at the end of June.  She also agrees that it isn't just wireless that =
needs the keying solutions.  They wanted to know if a new key-wrap =
attribute with a new algorithm would be sufficient or would IPSec work.  =
The latest draft of the Zorn document has all the changes included based =
upon the NIST discussion.  Nancy indicated that NISTs reaction to IPSec =
would require further review by NIST.  Jari Arkko also believes the key =
work isn't just for wireless and would like to see it in a separate =
draft from other WLAN attributes.  There was a question about the =
relationship to the Zorn document and the Aboba document?  We do have =
attributes for WLAN as a charter item for this group, but can't =
introduce new security mechanisms.  Bernard's document comes from the =
EAP key framework perspective.  A question about a new message =
authenticator algorithm and attribute being described by Glen.  It can =
be used in any RADIUS message because it is independent of the =
authenticator value in the RADIUS message. Message-Authenticator cannot =
be used in Accounting-Request or CoA messages.  The new one is =
cryptographically stronger; the old one is not FIPS compliant (MD5).  =
The new attribute can be used as a complete replacement of the old style =
message authenticator.  Alternatively, the old message authenticator =
could still be used.  Bernard's draft reuses the RADIUS shared secret, =
while Glen's draft assumes a cryptographically separate pre-shared key. =
Bill Burr cautions that NIST is not looking very closely at RADIUS usage =
and so there isn't a good view of what is being done here.  He =
characterized the existing wireless key distribution mechanism (i.e. as =
used in 802.11i with RADIUS) as somewhat "Rube Goldberg".  Bill =
described the process of obtaining a FIPS-140 certification and how =
painful it may be for vendors.  Glen points out that there is a lot of =
interest in solving this problem and it has been solved, so why is there =
a new WLAN draft addressing the keying mechanisms?  Dave Nelson (Chair) =
indicated that the keying problem seems to have a lot of interest. The =
WG might consider amending its charter (security mechanism restriction) =
to address this issue, if appropriate.

- End-to-End capability exchange presented by Avi Lior.

http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-01.=
txt

The proposal describes an end-to-end, per-session mechanism to negotiate =
capabilities.  The attribute contains a string of octets where each =
capability is encoded in 2 bits that define, not-supported, supported =
and required.  Avi points out other documents need this work; location =
in the GEOPRIV WG, VLAN, priority and filtering, CUI and prepaid could =
all use this.  Should it be a WG document?  No one objects to making =
this a WG item, but we will confirm this on the list.  This document =
should be in alignment with Greg's work on Design Guidelines if we are =
defining a new data type.

- RADIUS Prepaid attributes presented by Avi Lior.

http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-=
08.txt

The document was re-organized for read-ability and updated.  Flow based =
prepaid is becoming a requirement.  Requested by 3GPP2 and WiMAX.  The =
difference between RADIUS credit control (a.k.a. prepaid) and Diameter =
credit control was described.   It is believed that some of the =
differences are regarding some features that may compromise the privacy =
of the client (e.g. balance check and cost inquiry).  Other differences =
are not clear yet and need to be discussed.  How can Diameter credit =
control and RADIUS prepaid be translated?  The recommendation is that =
the server must do this itself.  A recommendation from the audience was =
to have scenarios documented or analyzed - not necessarily included in =
the draft, but available.  Different SDOs are using Diameter and RADIUS, =
and there will likely be some issues related to translation.  Resolution =
of these issues may require assistance from 3GPP, 3GPP2 and WiMAX, as =
the RADEXT WG didn't anticipate supporting different "dialects" of the =
prepaid extensions.  The authors believe the document is ready to become =
a WG item.   Since the authors are not in complete alignment it was =
suggested that they hash out their problems before making it a WG =
document.   The authors believe they have enough alignment, but being =
out of time, we will continue the discussion on the WG mailing list.

- RADIUS Bandwidth attributes presented by Avi Lior.

http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabilit=
y-01.txt

Issues from Bernard Aboba's extensive review have all been addressed, =
except one which is related to the length of the attribute size.  Should =
this be a WG document?  Discuss on the WG mailing list.

- RADIUS QoS attributes presented by Hannes Tschofenig.

http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-01.txt

Hannes describes a more general QoS environment.  This work is related =
to the Diameter work.  They are addressing a generic description =
described in NSIS QSPEC work.  As compared to Avi Lior's bandwidth =
document, this is a more heavy weight description.  Avi's document is =
viewed as a short term solution.  There is the question of charter scope =
in RADEXT.=20

- General WG Discussion about QoS and Bandwidth.

Allison Mankin (Transport AD) points out that we shouldn't use RADIUS as =
a resource management protocol.  She believes that RSVP and NSIS are the =
protocols to do resource allocation.  There was an RSVP and Diameter =
document that is similar to proposed RADIUS document.  John Loughney =
comments that the Diameter QoS document is an individual submission and =
not a current AAA WG document.  John will post the link to the RADEXT WG =
mailing list for this document, so that we can review it.  Allison =
mentions that we don't want to start extending the bandwidth draft to =
include a bunch of new things like latency and jitter, but they are =
happy with simple rates that are currently defined.  Combining Avi's =
bandwidth draft and Hannes' QoS draft would certainly delay the simple =
bandwidth parameter attribute that has been requested by other SDOs.  A =
comment from 3GPP is that they are depending upon the bandwidth draft to =
be complete for reference in their specification release 7, by mid-2006. =
 The group doesn't believe they should be combined.  Dave Nelson (Chair) =
asked what the overlap is between the documents.  Avi points out that =
the QoS "blob" includes a bandwidth component and could be used, but =
John Loughney and the other authors believe there may be a solution on =
how cross reference the documents and avoid overlap.  Dave (Chair) =
indicated he would work to facilitate the cross-WG and cross-Area =
coordination that will be required to move forward in this area.

=A0

--
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, 22 Aug 2005 18:45:08 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS keywrap attributes
Date: Mon, 22 Aug 2005 14:44:54 -0400
From: "Nelson, David" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Zhang, Tiebing" <[email-masked]>, "Russ Housley" <[email-masked]>

Glen Zorn writes...

> Hmm.  Since RADIUS clients and servers are required to ignore unknown
> packet types (by specification, not tradition), I don't really
understand
> why this same logic would not apply to the protocol in general.

I would suggest that one level of forwards and backwards compatibility
is obtained by ignoring individual attributes that are not understood,
while a very different (IMHO much lower) level of compatibility might be
obtained by ignoring entire protocol PDUs.

This discussion side-steps the whole issue of whether new attributes (or
indeed new commands) may safely be ignored by either clients or servers,
if the subject matter of said protocol elements is important or
"security sensitive".  We have the Mandatory header bit in Diameter to
address this issue.  I don't see any good solution to this problem,
short of adding a Mandatory bit in RADIUS attributes, which raises a
whole other backwards compatibility issue.=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: Mon, 22 Aug 2005 18:36:38 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS keywrap attributes
Date: Mon, 22 Aug 2005 11:35:57 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Zhang, Tiebing" <[email-masked]>, "Russ Housley" <[email-masked]>

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

> Glen Zorn writes...
>=20
>>> So yes, keying attributes are within the RADEXT WG charter.
>>=20
>> I suppose that, as David mentioned, this is a matter that is open to
>> interpretation.  However, the current charter states that "No new
>> security mechanisms will be defined for protecting RADIUS."  Taking
>> the position (which I think reasonable) that RADIUS includes
>> attributes and their allowable contents, it would seem to me that an
>> attribute that cryptographically protects its contents is, in fact,
>> a new security mechanism.
>=20
> The intent of the charter prohibition on "new security mechanisms"
> was to preclude the specification of incompatible revisions to
> RADIUS, that would mandate upgrades to existing RADIUS
> implementations.  Since RADIUS was designed without the benefit of a
> security method negotiation or selection mechanism, it's likely quite
> difficult to add new PDU-level security mechanisms in a backwards
> compatible fashion.  Since RADIUS implementations have traditionally
> ignored new attributes, introduced after the implementation, adding
> new security within the scope of a single attribute does not present
> the same level of backwards compatibility issues. =20

Hmm.  Since RADIUS clients and servers are required to ignore unknown =
packet types (by specification, not tradition), I don't really =
understand why this same logic would not apply to the protocol in =
general.=20
=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: Mon, 22 Aug 2005 16:04:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Radius Digest, both modes of operation should be mandatory
Date: Mon, 22 Aug 2005 12:03:43 -0400
From: "Nelson, David" <[email-masked]>
To: "Miguel Garcia" <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>
Cc: <[email-masked]>

Miguel Garcia writes...

> I didn't take the same approach for the analysis. Instead, I thought
> that if you are doing an interoperability test between two
independently
> developped implementations, one implementation might have implemented
a
> Radius client that supports only nonces generated in the Radius client
> and the other implementation might have implemented a Radius server
that
> only supports nonces generated in the Radius server.
>=20
> Both implementation will be compliant to your draft, but unable to
> interoperate. And will not be able to recover from any error.
>=20
> To me this is a severe design failure, and I am trying to avoid it. I
> think that the burden of implementing support for both modes of
> operation is almost negligible compared to the burden of not being
able
> to interoperate. So for the sake of interoperability I would suggest
to
> mandate the support for both modes of operation in both RADIUS clients
> and servers.

I tend to agree with Miguel.  If we are standardizing Digest
Authentication within RADIUS, the traditional multi-vendor
interoperability considerations should apply.  Suggesting that
cross-vendor interoperability will not occur in practical deployments
may be correct, at least in some cases.  Still, having an RFC that
documents inherently non-interoperable protocol options seems like a
poor choice.

--
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, 22 Aug 2005 15:09:50 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS keywrap attributes
Date: Mon, 22 Aug 2005 11:09:15 -0400
From: "Nelson, David" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Zhang, Tiebing" <[email-masked]>, "Russ Housley" <[email-masked]>

Glen Zorn writes...

> > So yes, keying attributes are within the RADEXT WG charter.
>=20
> I suppose that, as David mentioned, this is a matter that is open to
> interpretation.  However, the current charter states that "No new
security
> mechanisms will be defined for protecting RADIUS."  Taking the
position
> (which I think reasonable) that RADIUS includes attributes and their
> allowable contents, it would seem to me that an attribute that
> cryptographically protects its contents is, in fact, a new security
> mechanism.

The intent of the charter prohibition on "new security mechanisms" was
to preclude the specification of incompatible revisions to RADIUS, that
would mandate upgrades to existing RADIUS implementations.  Since RADIUS
was designed without the benefit of a security method negotiation or
selection mechanism, it's likely quite difficult to add new PDU-level
security mechanisms in a backwards compatible fashion.  Since RADIUS
implementations have traditionally ignored new attributes, introduced
after the implementation, adding new security within the scope of a
single attribute does not present the same level of backwards
compatibility issues.

I would further suggest that *if* the issues at hand, i.e. modifications
to RADIUS to allow FIPS certification of systems that include RADIUS as
a component, are of sufficient importance to the Internet Community,
then we should consider amending the charter to allow that work in
RADEXT, understanding that backwards compatibility is still an issue.
It would, IMHO, be a Bad Idea (tm) for this work of this significance to
be undertaken as individual submissions, when we have a WG working in
this area.

--
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, 22 Aug 2005 06:15:50 +0000
Date: Mon, 22 Aug 2005 09:15:14 +0300
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
CC: [email-masked]
Subject: Re: Issue: Radius Digest, both modes of operation should be mandatory

Wolfgang:

I didn't take the same approach for the analysis. Instead, I thought 
that if you are doing an interoperability test between two independently 
developped implementations, one implementation might have implemented a 
Radius client that supports only nonces generated in the Radius client 
and the other implementation might have implemented a Radius server that 
only supports nonces generated in the Radius server.

Both implementation will be compliant to your draft, but unable to 
interoperate. And will not be able to recover from any error.

To me this is a severe design failure, and I am trying to avoid it. I 
think that the burden of implementing support for both modes of 
operation is almost negligible compared to the burden of not being able 
to interoperate. So for the sake of interoperability I would suggest to 
mandate the support for both modes of operation in both RADIUS clients 
and servers.

/Miguel

Beck01, Wolfgang wrote:

> What scenarios do we have?
> 
> 1) plain IETF SIP providers, web servers, using HTTP Digest
> - client-side nonce generation is sufficient
> 
> 2) plain IETF SIP providers, web servers, using AKA Digest
> - server-side nonce generation is required
> 
> 3) providers using Diameter servers
> - server-side nonce generation is required, as Diameter does not (yet?) support
> client-side nonce generation.
> 
> 4) 3GPP2 IMS
> - client-side nonce generation is required
> 
> Will there be mixed environments?
> 
> A) RADIUS clients connected to distinct service providers (RADIUS roaming using NAI)
> - This is unlikely in SIP/HTTP environments, as RADIUS is not used for layer 2
> access authentication here. A user can access directly his SIP/HTTP server.
> This is different from the classical RADIUS use.
> 
> In IMS -- where there is a coupling between SIP and lower layers --, roaming
> is done on the the SIP level. As far as I know, there is no RADIUS or Diameter
> connection between different IMS providers.
> 
> B) A provider changes its equipment gradually from plain HTTP digest to AKA digest.
> 
> In the case of Digest Authentication, RADIUS clients are never talking to RADIUS
> or Diameter servers of a different provider.
> 
> My feeling is that there will be providers that will never bother about server-side
> nonce generation. Others will never consider client-side nonce generation. Mandating
> both modes will only complicate the initial configuration for them.
> 
> What does the group think?
> 
> 
> Wolfgang
> 
> --
> T-Systems
> Next Generation IP Services and Systems
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
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, 22 Aug 2005 01:21:54 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS keywrap attributes
Date: Sun, 21 Aug 2005 18:17:46 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Zhang, Tiebing" <[email-masked]>, "Russ Housley" <[email-masked]>

Bernard Aboba <> supposedly scribbled:

>>> I was under the impression that this was outside the scope of the WG
>>> charter.  Has this changed recently?
>=20
> The RADEXT WG charter was written based on liaison requests from SDOs
> including IEEE 802.11.  The IEEE 802 attribute draft, developed to
> respond to those requests, included keying attributes from the
> beginning.  =20

The keying attribute you mention was such in name only; it provided no =
security for the encapsulated key, since it was assumed that security =
would be supplied by running RADIUS over IPsec.

> So yes, keying attributes are within the RADEXT WG charter.

I suppose that, as David mentioned, this is a matter that is open to =
interpretation.  However, the current charter states that "No new =
security mechanisms will be defined for protecting RADIUS."  Taking the =
position (which I think reasonable) that RADIUS includes attributes and =
their allowable contents, it would seem to me that an attribute that =
cryptographically protects its contents is, in fact, a new security =
mechanism.

>=20
> While keying attributes are within the scope of the RADEXT WG
> charter, I am not clear what the criteria are for IESG approval.
> Satisfying the requirements in "AAA Key Management" (draft-housley)
> could prove quite difficult.  One of the requirements of
> draft-housley is to avoid disclosure of keying material to
> unauthorized parties.  This hurdle was overcome in RFC 4072 using
> Diameter redirect.   =20

It's not at all clear that the redirect technique actually solves any =
problem; for example, the keying problem is basically ignored, although =
there are probably ways to solve it.
 =20
>=20
> However, it is not clear to me that it would be possible to retrofit
> a redirect mechanism within RADIUS.  Since CMS failed to gain
> traction within Diameter, I see no reason why that would be viable
> for RADIUS, either.  The presentation at IETF 63 discussed a number
> of other alternatives, some of which are subjects of current research
> (the DNSSEC approach under development within Terena).    =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: Sun, 21 Aug 2005 21:28:42 +0000
Date: Sun, 21 Aug 2005 14:28:24 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nancy Winget (ncamwing)" <[email-masked]>
cc: [email-masked], "Zhang, Tiebing" <[email-masked]>,  Russ Housley <[email-masked]>,  "Pat Calhoun (pacalhou)" <[email-masked]>
Subject: RE: RADIUS keywrap attributes

> If we can agree that this is a work item for this group, then we can
> discuss the merits of the different proposed approaches by either
> draft-zorn-radius-keywrap-08.txt or your newly proposed
> draft-aboba-radext-wlan-00.txt and make progress on this particular
> requirement.

I believe that the issue of keywrap is within the scope of the RADEXT WG 
charter, so that discussing it on the RADEXT WG mailing list is 
appropriate. 

> We can always determine the criteria for IESG approval as well but that
> should not stall our progress in addressing this requirement.

I agree that we should not wait to move forward, but past history shows 
that getting IESG input early on is likely to avoid a lot of pain down the 
road. 

The original RADIUS WG was not permitted to work on RADIUS keywrap 
attributes, and that is why the VSAs documented in RFC 2548 needed to be 
developed. 

Prior to the approval of RFC 4004 (Diameter MIP) and RFC 4072 (Diameter 
EAP), the IETF had not published any AAA key management documents 
developed by an IETF WG as RFCs;  both of these documents took more than 5 
years to go from an initial submission to publication as RFCs. 

In order to avoid the problems that have been experienced in the past, 
it would be nice to know that what criteria are believed to apply to the 
work beforehand, so that we don't go through a lot of effort only to find 
out that the document is unacceptable to the IESG, requiring years of 
rework. 

My understanding is that all AAA key management documents submitted for 
publication as RFCs need to meet the criteria established in:
http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-00.txt

However, given that RADIUS is a mature, widely deployed protocol, there 
are practical limits on the scale of changes that can be made in order to 
meet these criteria. 

--
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, 21 Aug 2005 20:39:27 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS keywrap attributes
Date: Sun, 21 Aug 2005 13:38:55 -0700
From: "Nancy Winget \(ncamwing\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Zhang, Tiebing" <[email-masked]>, "Russ Housley" <[email-masked]>, "Pat Calhoun \(pacalhou\)" <[email-masked]>

The proposed draft-zorn-radius-keywrap-08.txt focuses mainly on the
keying attributes which we believe need to be protected and has been a
requirement for quite some time now.  Draft-zorn-radius-keywrap-08.txt
does not attempt to introduce a full new security mechanism to RADIUS as
is suggested by draft-aboba-radext-wlan-00.txt but merely addresses how
the keying material should be protected.

If we can agree that this is a work item for this group, then we can
discuss the merits of the different proposed approaches by either
draft-zorn-radius-keywrap-08.txt or your newly proposed
draft-aboba-radext-wlan-00.txt and make progress on this particular
requirement.

We can always determine the criteria for IESG approval as well but that
should not stall our progress in addressing this requirement.

	Nancy.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Sunday, August 21, 2005 12:29 AM
To: [email-masked]
Cc: Zhang, Tiebing; Russ Housley
Subject: RE: RADIUS keywrap attributes

> > I was under the impression that this was outside the scope of the WG

> > charter.  Has this changed recently?

The RADEXT WG charter was written based on liaison requests from SDOs
including IEEE 802.11.  The IEEE 802 attribute draft, developed to
respond to those requests, included keying attributes from the
beginning. =20
So yes, keying attributes are within the RADEXT WG charter.

While keying attributes are within the scope of the RADEXT WG charter, I
am not clear what the criteria are for IESG approval. Satisfying the
requirements in "AAA Key Management" (draft-housley) could prove quite
difficult.  One of the requirements of draft-housley is to avoid
disclosure of keying material to unauthorized parties.  This hurdle was
overcome in RFC 4072 using Diameter redirect.

However, it is not clear to me that it would be possible to retrofit a
redirect mechanism within RADIUS.  Since CMS failed to gain traction
within Diameter, I see no reason why that would be viable for RADIUS,
either.  The presentation at IETF 63 discussed a number of other
alternatives, some of which are subjects of current research (the DNSSEC
approach under development within Terena). =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/>

--
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, 21 Aug 2005 07:30:09 +0000
Date: Sun, 21 Aug 2005 00:29:21 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: "Zhang, Tiebing" <[email-masked]>, Russ Housley <[email-masked]>
Subject: RE: RADIUS keywrap attributes

> > I was under the impression that this was outside the scope of the WG
> > charter.  Has this changed recently?

The RADEXT WG charter was written based on liaison requests from SDOs 
including IEEE 802.11.  The IEEE 802 attribute draft, developed to 
respond to those requests, included keying attributes from the beginning.  
So yes, keying attributes are within the RADEXT WG charter.

While keying attributes are within the scope of the RADEXT WG charter,
I am not clear what the criteria are for IESG approval. Satisfying the 
requirements in "AAA Key Management" (draft-housley) could prove quite 
difficult.  One of the requirements of draft-housley is
to avoid disclosure of keying material to unauthorized parties.  This
hurdle was overcome in RFC 4072 using Diameter redirect.

However, it is not clear to me that it would be possible to retrofit 
a redirect mechanism within RADIUS.  Since CMS failed to gain 
traction within Diameter, I see no reason why that would be viable for 
RADIUS, either.  The presentation at IETF 63 discussed a number of other 
alternatives, some of which are subjects of current research (the DNSSEC 
approach under development within Terena).  

--
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, 19 Aug 2005 11:34:51 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Issue: Radius Digest, both modes of operation should be manda tory
Date: Fri, 19 Aug 2005 13:33:58 +0200

What scenarios do we have?

1) plain IETF SIP providers, web servers, using HTTP Digest
- client-side nonce generation is sufficient

2) plain IETF SIP providers, web servers, using AKA Digest
- server-side nonce generation is required

3) providers using Diameter servers
- server-side nonce generation is required, as Diameter does not (yet?) support
client-side nonce generation.

4) 3GPP2 IMS
- client-side nonce generation is required

Will there be mixed environments?

A) RADIUS clients connected to distinct service providers (RADIUS roaming using NAI)
- This is unlikely in SIP/HTTP environments, as RADIUS is not used for layer 2
access authentication here. A user can access directly his SIP/HTTP server.
This is different from the classical RADIUS use.

In IMS -- where there is a coupling between SIP and lower layers --, roaming
is done on the the SIP level. As far as I know, there is no RADIUS or Diameter
connection between different IMS providers.

B) A provider changes its equipment gradually from plain HTTP digest to AKA digest.

In the case of Digest Authentication, RADIUS clients are never talking to RADIUS
or Diameter servers of a different provider.

My feeling is that there will be providers that will never bother about server-side
nonce generation. Others will never consider client-side nonce generation. Mandating
both modes will only complicate the initial configuration for them.

What does the group think?

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: Thu, 18 Aug 2005 18:00:53 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 121: Data Representation
Date: Thu, 18 Aug 2005 13:59:40 -0400
From: "Nelson, David" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>

Wolfgang Beck writes...

> I've used the description in RfC 2617, Section 3.2.1
>=20
> "nonce
>      A server-specified data string which should be uniquely generated
>      each time a 401 response is made. It is recommended that this
>      string be base64 or hexadecimal data. "
>=20
> As the nonce is only interpreted by the nonce generator,
interopability
> is not required.

Perhaps adding that last sentence, of some variant, to the text of the
draft would clarify that this is an opaque (to RADIUS) nonce, in which
case its encoding is not required to be specified to obtain
interoperability.  In that case the attribute value should perhaps be
String, with the advisory that robust implementations shout treat it as
undistinguished octets.

--
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, 18 Aug 2005 14:03:26 +0000
Date: Thu, 18 Aug 2005 17:01:19 +0300
From: Miguel Garcia <[email-masked]>
To: [email-masked]
CC: "Beck01, Wolfgang" <[email-masked]>
Subject: Issue: Radius Digest requirement to clients

Submitter name: Miguel Garcia
Submitter email address: [email-masked]
Date first submitted: August 18, 2005
Reference: -
Document: draft-ietf-radext-digest-auth-03.txt
Comment type: T
Priority: '1' Should fix
Section: 1.2
Rationale/Explanation of issue:

The text imposes a requirement for RADIUS client that is both 
unimplementable and untestable.

The text reads:
    "If the RADIUS server generates nonces, its RADIUS clients MUST NOT
    try to generate nonces.  If the RADIUS server does not generate
    nonces, its RADIUS clients MUST generate nonces locally. "

The text seems to suggest that if a RADIUS server is generating a nonce 
then the RADIUS client must make sure that it does not generate a nonce. 
  These seems to imply a sequence where first the RADIUS server does an 
action (generate or not a nonce), and then the RADIUS client does a 
consequent action (not generate or generate a nonce).

However, the sequence of events (see the scenarios in Sections 1.3.1 and 
1.3.2) is that it is the RADIUS client the first entity that has to 
decide whether to generate a nonce or not (I assume that based on 
configuration), and then the RADIUS server can operate consequently.

Requested change:

I see two possibilities here, please choose one.

Possibility 1:
==============
To describe that the RADIUS servers and clients do not verify whether a 
nonce has been previously generated by the correspondent node. However, 
this must be pre-agreed and pre-configured before operation. In this 
case, I suggest to delete the text above mentioned and add the following:

"This specification assumes that both the RADIUS client and server are 
appropriately configured to generate the nonces in either the RADIUS 
client or the RADIUS server, but not in both at the same time. 
Implementations, though, do not have the means to verify this behaviour."

Possibility 2:
==============
To enforce that nonces are generated appropriately. I have my doubts 
whether this is achievable or not, espcially considering the case of 
HTTP Digest authentication using AKA (RFC 3310), because it requires to 
generate nonces always in the RADIUS server. In addition to this, we 
would need to consider the error cases and the recovery from them. If 
someone wants to pursue this track, please provide text for discussion.

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
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, 18 Aug 2005 13:44:30 +0000
Date: Thu, 18 Aug 2005 16:44:13 +0300
From: Miguel Garcia <[email-masked]>
To: [email-masked]
CC: "Beck01, Wolfgang" <[email-masked]>
Subject: Issue: Radius Digest, both modes of operation should be mandatory

Submitter name: Miguel Garcia
Submitter email address: [email-masked]
Date first submitted: August 18, 2005
Reference: -
Document: draft-ietf-radext-digest-auth-03.txt
Comment type: T
Priority: '1' Should fix
Section: 1.2
Rationale/Explanation of issue:

The draft contains two modes of operation, in one the nonces are 
generated in the RADIUS client, in the other, nonces are generated in 
the RADIUS server.

The text reads:
"RADIUS clients and servers can support one, or both nonce generation 
modes."

So how is interoperability going to be granted if a RADIUS client 
implements only one mode and the RADIUS server implements the other?

In my opinion what has been pursued here is to not add additional 
complexity to the implementation. But the generation of a nonce does not 
add almost any complexity, so I would say that both modes have to be 
supported in the sake of interoperability.

In addition to that, the text does not have a normative statement (only 
speaks about "can"). The text should be normative, and should be placed 
outside the Overview section, which is informative by nature.

     Requested change:

Add the following text elsewhere (Section 2?):

"RADIUS clients and servers MUST implement support for the two modes of 
operation: when nonces are generated in the RADIUS server and when 
nonces are generated in the RADIUS client."

And delete the existing text in Section 1.3

"RADIUS clients and servers can support one, or both nonce generation 
modes."
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
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, 18 Aug 2005 12:14:15 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Issue 121: Data Representation
Date: Thu, 18 Aug 2005 14:13:46 +0200

Bernard wrote:
> In Section 3.5, it says:
> 
> " Text
> It is recommended that this text be base64 or hexadecimal data."
> 
> For interoperability, you need to choose the representation 
> or at least specify how it can be determined which 
> representation is to be used.
> 
I've used the description in RfC 2617, Section 3.2.1

"nonce
     A server-specified data string which should be uniquely generated
     each time a 401 response is made. It is recommended that this
     string be base64 or hexadecimal data. "

As the nonce is only interpreted by the nonce generator, interopability
is not required.

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: Wed, 17 Aug 2005 17:34:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 119: More NITs; table format
Date: Wed, 17 Aug 2005 13:33:43 -0400
From: "Nelson, David" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>

Wolfgang Beck writes...

> - The xml2rfc tool adds borders to the table and I haven't found a=20
> way to disable this. Replacing the table with ASCII art is an option,
> but it wouldn't look good in xml2rfc's html output (and I don't know
> how the tool handles page breaks with large ascii art).

I'm a reasonably new user of xlm2rfc, but I have chosen to use the
artwork solution to preserve traditional ASCII RFC text formatting.  I
suspect that I have done this that the expense of the HTML version of
the document.  I haven't found another solution, however.

--
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, 17 Aug 2005 15:44:20 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: Issue 119: More NITs; table format
Date: Wed, 17 Aug 2005 17:43:53 +0200

Bernard wrote:

> Section 2.1
>
> .. Change .. To:
> Where an HTTP-style request traverses several proxies and each of the 
> proxies requests to authenticate the HTTP-style client the request at 
> the HTTP-style server may contain multiple credential sets.

I've added a comma after "HTTP-style client":

"Where an HTTP-style request traverses several proxies and each of the 
proxies requests to authenticate the HTTP-style client, the request at 
the HTTP-style server may contain multiple credential sets."

> Section 5
> 
> Please reformat the attribute table in the format used in
> other RADIUS RFCs, such as RFC 2865 Section 5.44:
> 
> The following table provides a guide to which attributes may
> be found in which kinds of packets, and in what quantity.
> 
> Request Accept Reject Challenge # Attribute
> 0-1     0-1      0       0      1 User-Name
> 0-1     0        0       0      2 User-Password [Note 1]
> 
Two remarks:
- Placing the attribute name in the last column seems a bit strange to me
- The xml2rfc tool adds borders to the table and I haven't found a way to disable
this. Replacing the table with ASCII art is an option, but it wouldn't look good
in xml2rfc's html output (and I don't know how the tool handles page breaks
with large ascii art).

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, 16 Aug 2005 21:23:03 +0000
Content-class: urn:content-classes:message
Subject: Issue:  Editorial comments on draft-ietf-radext-digest-auth-03.txt
Date: Tue, 16 Aug 2005 17:21:42 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: August 16, 2005
Reference:
Document: DIGEST-03
Comment type: 'E' Editorial
Priority: '1' Should fix
Section: 1.1, 1.3, 2.1, 4.1, 4.2. 4.3

(1) Rationale/Explanation of issue:

1.1 Terminology

This document includes many instances of the normative keywords. It does
not clarify that the usage applies only to RADIUS Clients and Server
that implement the digest authentication feature described in the
document.

While this may be obvious to some, certain text would appear to be
creating retroactive normative requirements on existing implementations.

Requested changes:

Add the following text at the end of Section 1.1:

"The use of normative requirement key words in this document shall apply
only to RADIUS Client and RADIUS Server implementations that include the
features described in this document.  This document creates no normative
requirements for existing implementations."

(2) Rationale/Explanation of issue:

Typographical errors.

Requested Changes:

1.3 Overview

In the fourth paragraph:

s/where Digest authentication is/where Digest Authentication is/

In the eighth paragraph:

s/a configurable parameter/a configurable parameter./

2.1 RADIUS Client Behavior

In the second paragraph:

s/are situation where/are situations where/

s/MUST send zero or exactly one/MUST send exactly zero or one/

(3) Rationale/Explanation of issue:

Confusing text.

The third paragraph contains the phrase "If the RADIUS client recognizes
the nonce...".  This could use some clarification.  The definition of
"nonce" in Section 1.1 is "An unpredictable value...".  How is it
possible for the RADIUS client to recognize an unpredictable value?
Does this simply that the RADIUS client maintains a history of recently
used nonce values?  Or is there another meaning?

Requested changes:

Please add clarification.

(4) Rationale/Explanation of issue:

Move Diameter gateway considerations to the Diameter SIP Application
draft.

4.1 RADIUS Client Diameter Server
4.1 Diameter Client, RADIUS Server
4.3 Limitations

Requested Changes:

Delete these sections and add a general reference to the Diameter SIP
draft.  This presumes, of course, that consensus is concurrently
obtained in the AAA WG to make this change.

--
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, 16 Aug 2005 19:02:35 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only / RADIUS layering
Date: Tue, 16 Aug 2005 15:02:31 -0400
From: "Avi Lior" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Pasi,

Snip...

> I think Avi's example of using "Authorize Only" for=20
> replenishing prepaid quota is a good example of this. The=20
> syntax of the attributes is defined in IETF specs, but actual=20
> interoperability requires some agreement of how the messages=20
> are acted upon that not's specified in any IETF document.=20
> (I'm not sure if it's specified in any document, in fact...)

I agree with your points.

But in the case of prepaid, I think the syntax and semantics is
described in the RADIUS prepaid document.  The same would be the case
for Diameter Credit Control.

However, in a case of the upcoming QoS Blob RADIUS work and even
Mobile-IPv4 work and even PANA, the semantics are covered in other
documents and therefore the RADIUS documents should reference the
documents rather then repeat the information.

> 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

--
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, 14 Aug 2005 18:48:04 +0000
Date: Sun, 14 Aug 2005 11:47:24 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Last look at RFC 2486bis...

The current version of RFC 2486bis is believed to have addressed all
outstanding issues.

The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt

We are asking participants in the RADEXT WG to take one last look at the
document.  Please post your comments to the RADEXT WG mailing list  by
Friday, August 19, 2005.

--
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: Sat, 13 Aug 2005 00:36:21 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: ISSUE: Request Authenticator validation in RFC 2866
Date: Fri, 12 Aug 2005 20:35:24 -0400
Message-Id: <[email-masked]>

Description of issue: No requirement for Request Authenticator validation in RFC 286
Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: August 12, 2005
Reference: URL to e-mail describing problem, if available
Document: RFC 2866
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:

  The text defining the Response Authenticator for Accounting-Response
packets says that "invalid packets are silently discarded", but no
such text exists for the Request Authenticator in Accounting-Request
packets.

Suggested fix:  Add following text to "issues & fixes draft"

  RFC 2866, Section 4.1 says:

  Request Authenticator

      The Request Authenticator of an Accounting-Request contains a 16-octet
      MD5 hash value calculated according to the method described in
      "Request Authenticator" above.

  The text is incomplete, as it does not indicate any action to take
when an Accounting-Request packet contains an invalid Request
Authenticator.  The following text should be considered to be part of
the above description:

     The Request Authenticator field MUST contain the correct data,
     as given by the above calculation.  Invalid packets are silently
     discarded.  Note that some early implementations always set the
     Request Authenticator to all zeros.  New implementations of RADIUS
     clients MUST use the above algorithm to calculate the
     Request Authenticator field.  New implementations of RADIUS servers
     MUST silently discard invalid packets.

  We may also want to add a note to the Security Considerations
section of the "Issues and fixes" draft.  RADIUS server
implementations which accept a Request Authenticator of all zeros are
subject to various attack scenarios.

  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, 12 Aug 2005 21:30:53 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Issue 81
Date: Fri, 12 Aug 2005 17:29:23 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The authors believe that the -02 version of this draft addresses RADEXT =
Issue 81.=20

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

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.

	Title		: RADIUS NAS-Management Authorization
	Author(s)	: G. Weber, D. Nelson
	Filename	: draft-nelson-radius-management-authorization-02.txt
	Pages		: 18
	Date		: 2005-8-12
=09
   This document describes RADIUS attributes for the authorization and
=A0=A0 service provisioning of local and remote management of embedded
=A0=A0 systems and other managed entities (NASes).=A0 Specific =
provisions are
=A0=A0 made for remote management via framed management protocols, and =
for
=A0=A0 more granular levels of security and command privilege level =
beyond
=A0=A0 those included in the base RADIUS specification.=A0 Provisions =
are also
=A0=A0 introduced for enhancing auditability of individual management
=A0=A0 operations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-author=
ization-02.txt

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

--
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, 12 Aug 2005 03:07:26 +0000
Date: Thu, 11 Aug 2005 20:06:55 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Narayanan Vidya-CVN065 <[email-masked]>
cc: "'Emile van Bergen'" <[email-masked]>, [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: RE: AAA for Handovers

The most recent IEEE 802.11r draft eliminates portions of the key
hierarchy and also mandates that the Authenticator and AAA client
reside on the same entity.  There is still discussion on the
interactions between NASes.

RFC 3580 describes how Accounting-Start messages can be sent in handover
situations.

On Thu, 11 Aug 2005, Narayanan Vidya-CVN065 wrote:

> Emile, Bernard,
> Thanks for the clarification on the accounting issues.
>
> Does anyone know how this will work with 802.11r-like key hierarchy? As
> per the key hierarchy, it seems like the station will have to establish
> the MSK by contacting the R0 key holder. However, the PTK it shares is
> with the R2 key holder. So, technically, the PMK-R0 is only used to
> derive the PMK-R1 and the latter to derive PMK-R2. I would imagine the
> RADIUS client would reside in the R0-KH - right? However, the station
> may handoff to different R2-KHs within the same R0-KH - how and when
> will accounting-start messages be sent in this case? Or, is it that the
> accounting messages only need to be sent when the station first derives
> the PMK-R0?
>
> About IAPP, I wasn't referring to the use of it here. I think mandating
> use of IAPP for sake of authentication or accounting perhaps leads to
> more complications.

--
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, 12 Aug 2005 02:12:05 +0000
From: Narayanan Vidya-CVN065 <[email-masked]>
To: "'Emile van Bergen'" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: RE: AAA for Handovers
Date: Thu, 11 Aug 2005 21:11:47 -0500

Emile, Bernard,
Thanks for the clarification on the accounting issues. 

Does anyone know how this will work with 802.11r-like key hierarchy? As per the key hierarchy, it seems like the station will have to establish the MSK by contacting the R0 key holder. However, the PTK it shares is with the R2 key holder. So, technically, the PMK-R0 is only used to derive the PMK-R1 and the latter to derive PMK-R2. I would imagine the RADIUS client would reside in the R0-KH - right? However, the station may handoff to different R2-KHs within the same R0-KH - how and when will accounting-start messages be sent in this case? Or, is it that the accounting messages only need to be sent when the station first derives the PMK-R0? 

About IAPP, I wasn't referring to the use of it here. I think mandating use of IAPP for sake of authentication or accounting perhaps leads to more complications. 

Vidya

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]] 
> Sent: Thursday, August 11, 2005 7:21 PM
> To: Bernard Aboba
> Cc: Narayanan Vidya-CVN065; [email-masked]; 
> [email-masked]; Korus Mike-CMK013
> Subject: Re: AAA for Handovers
> 
> 
> Hi,
> 
> On Thu, Aug 11, 2005 at 04:52:51PM -0700, Bernard Aboba wrote:
> 
> > > However, AAA servers can authenticate accounting messages by 
> > > including a Class attribute in its access accept message. 
> According 
> > > to RFC2865, the NAS SHOULD echo the given A/V pair, regardless of 
> > > value, in all its accounting messages that pertain to the 
> session, 
> > > including Accounting-Start.
> > 
> > Yes, but Class was created to link the accounting message to a 
> > previous authentication on the same NAS.  In pre-emptive keying the 
> > problem is linking an accounting message on one NAS to an 
> > authentication that occurred previously on another NAS.
> > 
> > Specifically, with pre-emptive keying, getting an 
> Accounting message 
> > with an echo'd class attribute doesn't actually demonstrate 
> that the 
> > user authenticated to the NAS, since no evidence is provided to the 
> > AAA server.
> 
> No, but it does demonstrate that the second NAS obtained it 
> from the first one, possibly with other context and 
> credentials, as part part of an IAPP.
> 
> > This means that any NAS that received a Class attribute 
> along with the 
> > pushed key can subsequently send an Accounting-Start regardless of 
> > whether the user actually connected to the NAS and actually 
> used the 
> > key.
> 
> I would say the sequence would be
> 
> 0. user connects to NAS X
> 1. AAA receives authentication request from NAS X
> 2. AAA sends key + Class + other authorization parameters to 
> nas X 3. AAA sends key to nas Y, Z, etc.
> 
> and nas Y and Z will only be able to use the key and send 
> accounting if they are trusted by nas X, because nas X 
> decided to give them Class. 
> 
> Or am I shifting the problem too easily to the NASes? Is the 
> underlying assumption for this work that there's no IAPP 
> operating at all?
> 
> > > cannot fabricate sessions that never took place, because the home 
> > > AAA can test whether the unique value of Class corresponds to a 
> > > session autenticated by it earlier.
> > 
> > If the AAA server sends pre-emptive notifications to several NAS 
> > devices, each one of them can pretend that the user 
> connected to it, 
> > and can generate Accounting records with the correct Class 
> attribute.  
> > Without user authentication there is no way for the AAA 
> server to know 
> > whether the Accounting-Start messages are valid.
> 
> Not if those notifications don't include Class. Class would 
> then only be transported between NASes through an IAPP, at 
> the actual handoff time.
> 
> > > And by tying the accounting record
> > > to a specific authentication instance, the home AAA can verify if 
> > > the session duration given by Acct-Session-Time in 
> Accounting-Stop 
> > > messages doesn't exceed the time granted in its earlier 
> > > Access-Accept.
> > 
> > The problem is that pre-emptive keying does not require a client to 
> > demonstrate possession of the key to the AAA server.  The 
> AAA server 
> > just pushes the key out and assumes that it is either used 
> or expires 
> > on the NAS.  As a result, there may be no corresponding 
> authentication 
> > instance for each accounting record sent by a NAS.  That means that 
> > the AAA server cannot verify the Acct-Session-Time or even 
> whether the 
> > session started at all.
> 
> I think if there is one Class per session, instead of one 
> Class per session per NAS, this problem does not occur.
> 
> > > The secure tying of accounting to an earlier 
> authentication can be 
> > > done securely by the home AAA if the home AAA generates Class as
> > >
> > >   nonce + locally-unique-session-id + HMAC(Class + local-secret)
> > 
> > Unfortunately in pre-emptive keying there may be no "local-secret" 
> > between the NAS and the home AAA server.
> 
> No, local as in only known on the AAA server. It's talking to 
> itself via the NAS, which only echos Class after all.
> 
> > > Or, is the AAA server keeping track of the fact that the MN 
> > > authenticated through the target NAS and checks that when 
> receiving 
> > > the Accounting-Start?
> > 
> > The AAA server doesn't need to check this in real-time but if a 
> > question arises it is helpful to have logs to be able to figure out 
> > what happened.
> > 
> > > On the other hand, if it is the latter, doesn't this 
> cause concern 
> > > for the state build-up in the AAA server?
> > 
> > For forensic purposes, it isn't necessary for the AAA 
> server to keep 
> > state on authentications and corresponding accounting 
> records; logging 
> > is sufficient.  However, both pre-emptive keying and key-request 
> > require the AAA server to cache key state, which does represent a 
> > fundamental change.
> 
> As long as such caching it can be done on a layer above the 
> core protocol as given in RFC2865, -6, -9, it needn't be any 
> worse than other schemes that use accounting information for 
> subsequent authentications.
> 
> > > As illustrated above, the home AAA /can/ check that the MN was 
> > > authenticated by it before accepting an accounting start.
> > 
> > In pre-emptive keying, there is no corresponding 
> authentication on the 
> > NAS that produces the accounting-start.
> > 
> > > Other than that, I would like to second a preference 
> towards a key 
> > > request (as a form of lightweight authentication; of 
> course the home 
> > > AAA must see /some/ form of credentials or session cookie 
> before it 
> > > should hand out keying material) rather than the AAA pushing 
> > > material outwards.
> > 
> > Key-Request does not bring up these concerns because there 
> can be an 
> > authentication corresponding to each accounting-start.  This means 
> > that a log can verify that the client authenticated to the 
> AAA server 
> > via a particular NAS and this can be correlated with a subsequent 
> > accounting-start.
> 
> Exactly. The model where a user session is a set of 
> lightweight RADIUS sessions, one session per NAS contact, is 
> probably easier to design and implement.
> 
> I think we should only choose one of the extremes: either use 
> a full RADIUS authentication/start/interim/stop per NAS 
> contact, implying we must solve caching and reauthentication 
> speed issues at the EAP layer, or use one RADIUS 
> authentication/start/interim/stop per full user session, and 
> let handoff be done wholly outside RADIUS, through an IAPP.
> 
> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           [email-masked]      
> tel. +31 (0)70 3906153           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: Fri, 12 Aug 2005 02:04:29 +0000
Date: Thu, 11 Aug 2005 19:03:31 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Emile van Bergen <[email-masked]>
cc: Narayanan Vidya-CVN065 <[email-masked]>, [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: Re: AAA for Handovers

> > Specifically, with pre-emptive keying, getting an Accounting message with
> > an echo'd class attribute doesn't actually demonstrate that the user
> > authenticated to the NAS, since no evidence is provided to the AAA server.
>
> No, but it does demonstrate that the second NAS obtained it from the
> first one, possibly with other context and credentials, as part part of
> an IAPP.

The IRTF pre-emptive keying proposal does not involve IAPP.  See:
http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-04.txt

> 0. user connects to NAS X
> 1. AAA receives authentication request from NAS X
> 2. AAA sends key + Class + other authorization parameters to nas X
> 3. AAA sends key to nas Y, Z, etc.
>
> and nas Y and Z will only be able to use the key and send accounting if
> they are trusted by nas X, because nas X decided to give them Class.

In pre-emptive keying, there is no transport of attributes between NASes,
because the NAS obtains the attributes directly from the AAA server.

> Or am I shifting the problem too easily to the NASes? Is the underlying
> assumption for this work that there's no IAPP operating at all?

I think you're confusing the IRTF pre-emptive keying proposal with another
proposal.

> > If the AAA server sends pre-emptive notifications to several NAS devices,
> > each one of them can pretend that the user connected to it, and can generate
> > Accounting records with the correct Class attribute.  Without user
> > authentication there is no way for the AAA server to know whether the
> > Accounting-Start messages are valid.
>
> Not if those notifications don't include Class. Class would then only be
> transported between NASes through an IAPP, at the actual handoff time.

The IRTF pre-emptive keying proposal doesn't involve IAPP, so this not
possible.

> I think if there is one Class per session, instead of one Class per
> session per NAS, this problem does not occur.

It can occur either way because any NAS that obtains a pre-emptive key can
issue an Accounting-Start with the same Class attribute.

> Exactly. The model where a user session is a set of lightweight RADIUS
> sessions, one session per NAS contact, is probably easier to design and
> implement.

That was the feedback provided by 802.11r participants.

> I think we should only choose one of the extremes: either use a full
> RADIUS authentication/start/interim/stop per NAS contact, implying we
> must solve caching and reauthentication speed issues at the EAP layer,
> or use one RADIUS authentication/start/interim/stop per full user
> session, and let handoff be done wholly outside RADIUS, through an IAPP.

As I understand it, IEEE 802.11r supports both of these modes as well as
as "Key Request" mode.  At the last meeting, the group was looking at
features to cut, so if you have an opinion, bring your occam's razor with
you :)

BTW, if a specification supports multiple modes, it's worth considering
whether *all* of them need to satisfy the Housley Criteria.  As long as
there is one mode that does satisfy the criteria, then operators who value
security can deploy it.  There is a distinction between making
security "mandatory to implement" and "mandatory to use".  As long as one
mode is secure and its implementation is mandatory, then I think the
"mandatory to implement" requirement is satisfied.

--
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, 12 Aug 2005 00:21:02 +0000
Date: Fri, 12 Aug 2005 02:20:49 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Narayanan Vidya-CVN065 <[email-masked]>, [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: Re: AAA for Handovers
Mail-Followup-To: Bernard Aboba <[email-masked]>, Narayanan Vidya-CVN065 <[email-masked]>, [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>

Hi,

On Thu, Aug 11, 2005 at 04:52:51PM -0700, Bernard Aboba wrote:

> > However, AAA servers can authenticate accounting messages by including a
> > Class attribute in its access accept message. According to RFC2865, the
> > NAS SHOULD echo the given A/V pair, regardless of value, in all its
> > accounting messages that pertain to the session, including
> > Accounting-Start.
> 
> Yes, but Class was created to link the accounting message to a previous
> authentication on the same NAS.  In pre-emptive keying the problem
> is linking an accounting message on one NAS to an authentication that
> occurred previously on another NAS.
> 
> Specifically, with pre-emptive keying, getting an Accounting message with
> an echo'd class attribute doesn't actually demonstrate that the user
> authenticated to the NAS, since no evidence is provided to the AAA server.

No, but it does demonstrate that the second NAS obtained it from the
first one, possibly with other context and credentials, as part part of
an IAPP.

> This means that any NAS that received a Class attribute along with the
> pushed key can subsequently send an Accounting-Start regardless of
> whether the user actually connected to the NAS and actually used the key.

I would say the sequence would be

0. user connects to NAS X
1. AAA receives authentication request from NAS X
2. AAA sends key + Class + other authorization parameters to nas X
3. AAA sends key to nas Y, Z, etc.

and nas Y and Z will only be able to use the key and send accounting if
they are trusted by nas X, because nas X decided to give them Class. 

Or am I shifting the problem too easily to the NASes? Is the underlying
assumption for this work that there's no IAPP operating at all?

> > cannot fabricate sessions that never took place, because
> > the home AAA can test whether the unique value of Class corresponds to a
> > session autenticated by it earlier.
> 
> If the AAA server sends pre-emptive notifications to several NAS devices,
> each one of them can pretend that the user connected to it, and can generate
> Accounting records with the correct Class attribute.  Without user
> authentication there is no way for the AAA server to know whether the
> Accounting-Start messages are valid.

Not if those notifications don't include Class. Class would then only be
transported between NASes through an IAPP, at the actual handoff time.

> > And by tying the accounting record
> > to a specific authentication instance, the home AAA can verify if the
> > session duration given by Acct-Session-Time in Accounting-Stop messages
> > doesn't exceed the time granted in its earlier Access-Accept.
> 
> The problem is that pre-emptive keying does not require a client to
> demonstrate possession of the key to the AAA server.  The AAA server
> just pushes the key out and assumes that it is either used or expires
> on the NAS.  As a result, there may be no corresponding authentication
> instance for each accounting record sent by a NAS.  That means that
> the AAA server cannot verify the Acct-Session-Time or even whether the
> session started at all.

I think if there is one Class per session, instead of one Class per
session per NAS, this problem does not occur.

> > The secure tying of accounting to an earlier authentication can be done
> > securely by the home AAA if the home AAA generates Class as
> >
> >   nonce + locally-unique-session-id + HMAC(Class + local-secret)
> 
> Unfortunately in pre-emptive keying there may be no "local-secret" between
> the NAS and the home AAA server.

No, local as in only known on the AAA server. It's talking to itself
via the NAS, which only echos Class after all.

> > Or, is the AAA server keeping track of the fact that the MN
> > authenticated through the target NAS and checks that when receiving
> > the Accounting-Start?
> 
> The AAA server doesn't need to check this in real-time but if a question
> arises it is helpful to have logs to be able to figure out what happened.
> 
> > On the other hand, if it is the latter, doesn't this cause
> > concern for the state build-up in the AAA server?
> 
> For forensic purposes, it isn't necessary for the AAA server to keep
> state on authentications and corresponding accounting records; logging is
> sufficient.  However, both pre-emptive keying and key-request require
> the AAA server to cache key state, which does represent a fundamental
> change.

As long as such caching it can be done on a layer above the core
protocol as given in RFC2865, -6, -9, it needn't be any worse than other
schemes that use accounting information for subsequent authentications.

> > As illustrated above, the home AAA /can/ check that the MN was
> > authenticated by it before accepting an accounting start.
> 
> In pre-emptive keying, there is no corresponding authentication on the NAS
> that produces the accounting-start.
> 
> > Other than that, I would like to second a preference towards a key
> > request (as a form of lightweight authentication; of course the home AAA
> > must see /some/ form of credentials or session cookie before it should
> > hand out keying material) rather than the AAA pushing material outwards.
> 
> Key-Request does not bring up these concerns because there can be an
> authentication corresponding to each accounting-start.  This means that a
> log can verify that the client authenticated to the AAA server via a
> particular NAS and this can be correlated with a subsequent
> accounting-start.

Exactly. The model where a user session is a set of lightweight RADIUS
sessions, one session per NAS contact, is probably easier to design and
implement.

I think we should only choose one of the extremes: either use a full
RADIUS authentication/start/interim/stop per NAS contact, implying we
must solve caching and reauthentication speed issues at the EAP layer,
or use one RADIUS authentication/start/interim/stop per full user
session, and let handoff be done wholly outside RADIUS, through an IAPP.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Thu, 11 Aug 2005 23:53:01 +0000
Date: Thu, 11 Aug 2005 16:52:51 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Emile van Bergen <[email-masked]>
cc: Narayanan Vidya-CVN065 <[email-masked]>, [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: Re: AAA for Handovers

> However, AAA servers can authenticate accounting messages by including a
> Class attribute in its access accept message. According to RFC2865, the
> NAS SHOULD echo the given A/V pair, regardless of value, in all its
> accounting messages that pertain to the session, including
> Accounting-Start.

Yes, but Class was created to link the accounting message to a previous
authentication on the same NAS.  In pre-emptive keying the problem
is linking an accounting message on one NAS to an authentication that
occurred previously on another NAS.

Specifically, with pre-emptive keying, getting an Accounting message with
an echo'd class attribute doesn't actually demonstrate that the user
authenticated to the NAS, since no evidence is provided to the AAA server.
This means that any NAS that received a Class attribute along with the
pushed key can subsequently send an Accounting-Start regardless of
whether the user actually connected to the NAS and actually used the key.

> cannot fabricate sessions that never took place, because
> the home AAA can test whether the unique value of Class corresponds to a
> session autenticated by it earlier.

If the AAA server sends pre-emptive notifications to several NAS devices,
each one of them can pretend that the user connected to it, and can generate
Accounting records with the correct Class attribute.  Without user
authentication there is no way for the AAA server to know whether the
Accounting-Start messages are valid.

> And by tying the accounting record
> to a specific authentication instance, the home AAA can verify if the
> session duration given by Acct-Session-Time in Accounting-Stop messages
> doesn't exceed the time granted in its earlier Access-Accept.

The problem is that pre-emptive keying does not require a
client to demonstrate possession of the key to the AAA
server.  The AAA server just pushes the key out and assumes
that it is either used or expires on the NAS.  As a result,
there may be no corresponding authentication instance for each
accounting record sent by a NAS.  That means that the AAA server
cannot verify the Acct-Session-Time or even whether the session started at all.

> The secure tying of accounting to an earlier authentication can be done
> securely by the home AAA if the home AAA generates Class as
>
>   nonce + locally-unique-session-id + HMAC(Class + local-secret)

Unfortunately in pre-emptive keying there may be no "local-secret" between
the NAS and the home AAA server.

> Or, is the AAA server keeping track of the fact that the MN
> authenticated through the target NAS and checks that when receiving
> the Accounting-Start?

The AAA server doesn't need to check this in real-time but if a question
arises it is helpful to have logs to be able to figure out what happened.

> On the other hand, if it is the latter, doesn't this cause
> concern for the state build-up in the AAA server?

For forensic purposes, it isn't necessary for the AAA server to keep
state on authentications and corresponding accounting records; logging is
sufficient.  However, both pre-emptive keying and key-request require
the AAA server to cache key state, which does represent a fundamental
change.

> As illustrated above, the home AAA /can/ check that the MN was
> authenticated by it before accepting an accounting start.

In pre-emptive keying, there is no corresponding authentication on the NAS
that produces the accounting-start.

> Other than that, I would like to second a preference towards a key
> request (as a form of lightweight authentication; of course the home AAA
> must see /some/ form of credentials or session cookie before it should
> hand out keying material) rather than the AAA pushing material outwards.

Key-Request does not bring up these concerns because there can be an
authentication corresponding to each accounting-start.  This means that a
log can verify that the client authenticated to the AAA server via a
particular NAS and this can be correlated with a subsequent
accounting-start.

--
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, 11 Aug 2005 23:51:12 +0000
Date: Fri, 12 Aug 2005 01:51:05 +0200
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Technical comments on draft-ietf-radext-ieee802-00.txt
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Thu, Aug 11, 2005 at 10:45:35AM -0400, Nelson, David wrote:

> Submitter name: David Nelson
> Submitter email address: [email-masked]
> Date first submitted: August 10, 2005
> Reference: (missing from the RADEXT archive ???)
> Document: VLAN, Priority and Filtering Attributes
> Comment type: 'T' Technical
> Priority: '0' Must fix
> Section: 3.1
> Rationale/Explanation of issue:
> 
> Integer 
>     
>          The Integer field is four octets in length.  The format of the 
>          Integer field consists of two parts, the first consuming high-
>          order octet and the second consuming the remaining three lower-
>          order octets.  The high-order octet field indicates if the 
>          VLANID is allowed for tagged or untagged packets.  The second 
>          part is the 12-bit 802.1Q VLAN VID value that has been padded 
>          out to consume the remaining three lower-order octets.  A 
>          sample encoding follows:  
> 
> 
> This is not an Integer data type.  It is a multi-field Octet String
> (complex data type).
> 
> Requested changes:
> 
> Express a String data type (with sub-fields).

Disagree. Integers are not monotonic counters only. If two integers need
to be tied together, are of fixed length and together fit in 4 octets, I
see no reason not to use RADIUS integers.

What's next, sending IPv4 addresses as a complex type consisting of 4
decimal variable length strings? 

I know we've always used a dedicated label for IP addresses in RADIUS
dicationaries, but they are encoded and can be handled exactly the same
as integers everywhere in the server, up to the point where you reach
the very end of the chain, in modules that deal with ASCII
representations.

Cheers,

Emile.
-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Thu, 11 Aug 2005 23:39:17 +0000
Date: Fri, 12 Aug 2005 01:39:07 +0200
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: It's all in the timing...
Mail-Followup-To: Alan DeKok <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Wed, Aug 10, 2005 at 06:11:45PM -0400, Alan DeKok wrote:

> "Nelson, David" <[email-masked]> wrote:
> > I have a general concern, or meta-issue, to raise regarding the WGLC of
> > draft-ietf-radext-ieee802-00.txt.  The VLAN, Priority and Filtering
> > Attributes draft proposes new RADIUS attributes of base data type String
> > (Octet String) that are, in fact, multi-field structures a.k.a. complex
> > data types.
> 
>   Like ARAP-Features, Login-LAT-Group, Framed-Appletalk-Link,
> Framed-Appletalk-Zone ...
> 
> > My frustration is that I don't see a good solution.  The Design
> > Guidelines for RADIUS Attributes must be given time to mature and obtain
> > consensus.  It does not seem reasonable to delay the VLAN, Priority and
> > Filtering Attributes draft until the design guidelines are ready.  I
> > guess the best I can hope for is that work on the design guidelines
> > progresses rapidly, and that any substantial disconnects between the
> > design guidelines and the VLAN, Priority and Filtering Attributes draft
> > can be reconciled before it goes out for IETF Last Call.
> 
>   Sure.
> 
>   I also have no objection to publishing the VLAN... draft without the
> benefit of the final Design Guidelines draft.  There are already
> complex data types in RADIUS attributes, so adding a few more
> shouldn't be a serious problem.

Seconded. I would also like to reiterate my plea for layering. 

Let's keep RADIUS to deal with big endian numeric and variable length
octet strings (possibly interpreted as UTF-8 if they need to be
displayed), and keep it at that.

Interpretation of values, applying boundaries and so forth should always
be done on a higher layer.

I thing we should not try and invent an ASN.1 for RADIUS or another
RFC2869 (creating a data structure by tying attributes together using a
tag, where the syntax of the pair (tag-value or just value) is dependent
of the value(!) of the potential tag (> 0x1f means no tag). Hackish
seems a nice word for that solution).

Let's keep the attribute field in the basic protocol a simple transport
for simple ordinals and octet strings, and build on that to do the rest.

The day that RADIUS requires some form of a DTD so that the protocol can
do part of the application's work of verifying the syntax of its own
input is the day that I quit my RADIUS work. If an application refuses
to check its own input syntax /at all cost/, have it use XML, not
RADIUS.

All types are /not/ created equal. Complex types belong on a higher
layer. It should be possible to parse a RADIUS packet using a simple
dictionary containing only name, number and 4 types, before passing it
onwards to an application, whether that's done through a database,
XML-RPC, SOAP, BEEP, HTTP GET, or whatever.

Of course, a recommendation for a field separator and escape method may
be useful if application developers are really incapable of coming up
with anything to use. I'd suggest something light weight, like HTTP's
request URIs (field1&field2&ben%26jerry).  If an application wants
fields to carry names, they can be encoded as var=value&var=value, again
as in HTTP.

I favour independent, simple layers and the KISS principle, especially
in security protocols.

If a proposal is being done to merely prevent another tagged attribute
invention for allowing simple sets, then I suggest either creating a
container attribute type that is to be parsed as the RADIUS attribute
field (ie. allowing it to contain a list of A/V pairs), or the HTTP
request URI approach given above. But, please, keep it /simple/ and stay
away from application specific types below the application.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Thu, 11 Aug 2005 22:58:16 +0000
Date: Fri, 12 Aug 2005 00:57:39 +0200
From: Emile van Bergen <[email-masked]>
To: Narayanan Vidya-CVN065 <[email-masked]>
Cc: 'Bernard Aboba' <[email-masked]>, [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: Re: AAA for Handovers
Mail-Followup-To: Narayanan Vidya-CVN065 <[email-masked]>, 'Bernard Aboba' <[email-masked]>, [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>

Hi,

On Thu, Aug 11, 2005 at 09:53:52AM -0500, Narayanan Vidya-CVN065 wrote:

> 
> > Pre-emptive keying seeds the key cache at potential points of
> > attachment, but the EAP peer only authenticates with the 
> > target NAS, the AAA server never confirms that the EAP peer 
> > used the key.  The only indication the AAA server receives is 
> > an Accounting-Start from the target NAS, indicating that the 
> > EAP peer has connected.
> > 
> > Because the AAA server can never confirm that the EAP peer
> > was even considering the target NAS, it has no way to know 
> > whether the Accounting-Start it received is authentic.  This 
> > enables a rogue operator to generate fraudulent accounting 
> > records that cannot be easily checked by the AAA server.
> > 
> 
> I am not very familiar with how accounting works. Is the
> Accounting-Start message not authenticated? If it is authenticated
> using an SA shared between the NAS and the AAA server, I am wondering
> why that isn't enough to trust the NAS. 

Accounting messages are signed using the Request Authenticator and
possibly Message-Authenticator (required in case of EAP), by the RADIUS
client (ie. NAS or proxy).

There is generally no SA between NAS and AAA (the endpoints), only
between individual RADIUS link partners.

However, AAA servers can authenticate accounting messages by including a
Class attribute in its access accept message. According to RFC2865, the
NAS SHOULD echo the given A/V pair, regardless of value, in all its
accounting messages that pertain to the session, including
Accounting-Start. 

Indeed, many roaming agreements even require NASes to do so. Support
also seems very widely implemented, perhaps because it's a trivial
thing, and I would advocate to require the NAS to support it for new
applications, just like Message-Authenticator support was required in
RFC 2869 if EAP is used.

If the home AAA chooses a new value of Class per session, A rogue proxy
operator can change the value of all attributes in the accounting
request, but cannot fabricate sessions that never took place, because
the home AAA can test whether the unique value of Class corresponds to a
session autenticated by it earlier. And by tying the accounting record
to a specific authentication instance, the home AAA can verify if the
session duration given by Acct-Session-Time in Accounting-Stop messages
doesn't exceed the time granted in its earlier Access-Accept.

The secure tying of accounting to an earlier authentication can be done
securely by the home AAA if the home AAA generates Class as 

  nonce + locally-unique-session-id + HMAC(Class + local-secret)

The rogue proxy or NAS can replay Class values in forged accounting
messages, but the home AAA can always be programmed to allow only one
start and one stop record for each session.

> > The requirement that the EAP peer demonstrate interest in the 
> > target NAS and prove its identity means that there is an 
> > authentication attempt to go along with the Accounting-Start.
> 
> Is it that the AAA server relies on the successive timing of the
> authentication via the target NAS and the Accounting-Start message?
> Or, is the AAA server keeping track of the fact that the MN
> authenticated through the target NAS and checks that when receiving
> the Accounting-Start? If it is the former, isn't there a problem with
> pre-authentication itself? The MN may have pre-authenticated via a
> target NAS well before handoff, but an Accounting-Start may be sent
> much later. On the other hand, if it is the latter, doesn't this cause
> concern for the state build-up in the AAA server? 

As illustrated above, the home AAA /can/ check that the MN was
authenticated by it before accepting an accounting start. There's
currently nothing in RADIUS itself that requires tying accounting to
authentication. Some home AAA policies will cause some connection
between accounting and subsequent authentications to exist, eg.  by
subtracting time from a user's voucher or locking a session, but such a
connection is always rather indirect and application specific.

With respect to timing, a home AAA can only be certain that it has sent
an accept before it can ever receive a valid accounting start. The rest
is variable.

Other than that, I would like to second a preference towards a key
request (as a form of lightweight authentication; of course the home AAA
must see /some/ form of credentials or session cookie before it should
hand out keying material) rather than the AAA pushing material outwards.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Thu, 11 Aug 2005 20:54:21 +0000
Date: Thu, 11 Aug 2005 13:54:13 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 119: More NITs

Issue 119: More NITs
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 11, 2005
Reference:
Document: DIGEST-03
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:
General:

RADIUS RFCs use the term "packet" to refer to RADIUS Access-Request,
Challenge, Accept and Reject messages, not "message". Please change
"message" to "packet" throughout the document.

Section 3

The term 'HTTP-style' denotes any protocol that uses HTTP-like
headers and uses HTTP digest authentication as described in
[RFC2617]. Examples are HTTP and SIP.

Why is this here? Shouldn't this be moved to the terminology section?

Section 3.1

Change:

" If this attribute is present in an Access-Request message, the
RADIUS server MUST view the Access-Request as a Digest one."

to:

" If this attribute is present in an Access-Request message, a
RADIUS server implementing this specification MUST treat the
Access-Request as a request for Digest Authentication."

Change:

"The attribute proves the user knows the password
and MUST only be used in Access-Requests."

To:

"This attribute (which enables the user to prove possession of the
password) MUST only be used in Access-Requests"

Change:

" When using HTTP digest, the text field is 32 octets long and
contains hexadecimal representation of 16 octet digest value as
it was calculated by the authenticated client. Other digest
algorithms MAY define different digest lengths. The text field
MUST be copied from request-digest of digest-response
([RFC2617]) without quotes."

To:

" When using HTTP digest, the text field is 32 octets long and
contains a hexadecimal representation of the 16 octet digest value as
it was calculated by the authenticated client. Other digest
algorithms MAY define different digest lengths. The text field
MUST be copied from request-digest of digest-response
([RFC2617]) without quotes."

Section 3.3

Change:

" This attribute holds a nonce to be used in the HTTP Digest
calculation. If the Access-Request had a Digest-Method and a
Digest-URI but no Digest-Nonce attribute and the RADIUS server
is configured to choose nonces, it MUST put a Digest-Nonce
attribute into its Access-Challenge message. This attribute
MUST only be used in Access-Request and Access-Challenge
messages."

to:

" This attribute holds a nonce to be used in the HTTP Digest
calculation. If the Access-Request had a Digest-Method and a
Digest-URI but no Digest-Nonce attribute and the RADIUS server
is configured to choose nonces, it MUST put a Digest-Nonce
attribute into its Access-Challenge message. This attribute
MUST only be used in Access-Request and Access-Challenge
messages."

Section 3.4

Change:

" This text proves the RADIUS server knows the password. If the
previously received Digest-Qop attribute was 'auth-int'
(without quotes), the RADIUS server MUST send a Digest-HA1
attribute instead of Digest-Response-Auth. The Digest-
Response-Auth attribute MUST only be used in Access-Accept
messages. The RADIUS client puts the attribute value without
quotes into the rspauth directive of the Authentication-Info
header."

To:

" This attribute enables the RADIUS server to prove possesion
of the password. If the previously received Digest-Qop
attribute was 'auth-int' (without quotes), the RADIUS server
MUST send a Digest-HA1 attribute instead of a Digest-Response-Auth
attribute. The Digest-Response-Auth attribute MUST only be used
in Access-Accept messages. The RADIUS client puts the attribute
value without quotes into the rspauth directive of the
Authentication-Info header."

Section 3.11

Change:

" This attribute holds the client nonce parameter that is used in
the HTTP Digest calculation. It MUST only be used in Access-
Request messages.u"

To:

" This attribute holds the client nonce parameter that is used in
the HTTP Digest calculation. It MUST only be used in Access-
Request messages."

Section 3.13

Change:

" This attribute holds the user name parameter that is used in
the HTTP digest calculation. The RADIUS server MUST NOT use
this value for password finding, but only for digest
calculation purpose. In order to find the user record
containing the password, the RADIUS server MUST use the value
of the ([RFC2865] -)User-Name attribute. This attribute MUST
only be used in Access-Request packets."

To:

" This attribute holds the user name used in the HTTP digest
calculation. The RADIUS server MUST use this attribute
only for the purposes of calculating the digest. In order to
determine the appropriate user credentials, the RADIUS
server MUST use the User-Name (1) attribute, and MUST NOT
use the Digest-Username attribute. This attribute MUST
only be used in Access-Request packets."

Section 3.15

Change:

" If the Digest header contains several unknown parameters, then
the RADIUS implementation MUST repeat this attribute and each
instance MUST contain one different unknown Digest parameter/
value combination.
This attribute MUST ONLY be used in Access-Request, Access-
Challenge, or Access-Accept messages."

To:

" If the Digest header contains several unknown parameters, then
the RADIUS implementation MUST repeat this attribute and each
instance MUST contain one different unknown Digest parameter/
value combination. This attribute MUST ONLY be used in
Access-Request, Access-Challenge, or Access-Accept messages."

In Section 3.20, change:

"However, the exact mapping of
this attribute to SIP can change due to new developments in the
protocol.
This attribute MUST only be used when the RADIUS client wants
to authorize SIP users and MUST only be used in Access-Request
messages."

To:

"However, the exact mapping of this attribute to SIP can change
due to new developments in the protocol. This attribute MUST
only be used in Access-Request messages, when the RADIUS client
wants to authorize SIP users."

Section 4

Please remove Section 4 (Migration Path to Diameter) as was discussed
at IETF 63.

Section 5

Please reformat the attribute table in the format used in other RADIUS
RFCs,
such as RFC 2865 Section 5.44:

The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.

Request Accept Reject Challenge # Attribute
0-1     0-1      0       0      1 User-Name
0-1     0        0       0      2 User-Password [Note 1]

--
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, 11 Aug 2005 20:52:54 +0000
Date: Thu, 11 Aug 2005 13:52:48 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 120: Message-Authenticator

Issue 120: Message-Authenticator
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 11, 2005
Reference:
Document: DIGEST-03
Comment type: T
Priority: S
Section: 8
Rationale/Explanation of issue:

The document appears to mandate use of Message-Authenticator in all RADIUS
usage.

Section 8

Change:

"8. Security Considerations

The RADIUS extensions described in this document make RADIUS a
transport protocol for the data that is required to perform a digest
calculation. It adds the vulnerabilities of HTTP Digest (see
[RFC2617], section 4) to those of RADIUS (see [RFC2865], Section 8 or
Section 4 of [RFC3579]).

If an attacker gains control over a RADIUS client or RADIUS proxy, he
can perform man-in-the-middle attacks even if the paths between A, B
and B, C (Figure 2) have been secured with TLS or IPsec.

The RADIUS server MUST check the Digest-Realm attribute it has
received from a client. If the RADIUS client is not authorized to
serve HTTP-style clients of that realm, it might be compromised.

RADIUS clients implementing the extension described in this document
authenticate layer 3 requests received from the Internet. This is in
contrast to the original use of RADIUS, where layer 2 sessions are
authenticated. In layer 2 access networks, attackers can usually
tracked down more easily.

An attacker could try to overload the RADIUS infrastructure by
excessively sending HTTP-style requests. To make simple denial of
service attacks more difficult, the nonce issuer (RADIUS client or
server) MUST check if it has generated the nonce received from an
HTTP-style client. This SHOULD be done statelessly. For example, a
nonce could consist of a cryptographically random part and some kind
of signature of the RADIUS client, as described in [RFC2617], section
3.2.1.

RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
attributes in Access-Challenge messages. A man in the middle can
modify or remove those attributes in a bidding down attack. In this
case, the RADIUS client would use a weaker authentication scheme than
intended. RfC 3579 [RFC3579], section 3.2 describes a Message-
Authenticator attribute which MUST be used to improve the integrity
protection of RADIUS messages. The RADIUS server can use this
attribute to verify the identity of the RADIUS client.

The Digest-HA1 attribute contains no random components if the
algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary
attacks easier and can be used for replay attacks.

HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. Instead of TLS, IPsec can be used,
too. TLS or IPsec secure the connection while Digest Authentication
authenticates the user. The RADIUS transaction can be regarded as
one leg on the path between the HTTP-style client and the HTTP-style
server. To prevent the RADIUS transaction from being the weakest hop
on the path, a RADIUS client receiving an HTTP-style request via TLS
or IPsec MUST use an equally secure connection to the RADIUS server.
There are two ways to achieve this:
o the RADIUS client rejects HTTP-style requests received over TLS or
IPsec
o the operator of the RADIUS client takes actions to ensure that
RADIUS traffic is exclusively sent and received using IPsec.
When using IPsec, it MUST be set up as described [RFC3579] section
4.2."

To:

"8. Security Considerations

The RADIUS extensions described in this document enable RADIUS to
transport the data that required to perform a digest calculation.
As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see
[RFC2617], section 4) in addition to RADIUS security vulnerabilities
described in [RFC2865] Section 8 and [RFC3579] Section 4.

An attacker compromising a RADIUS client or proxy can carry out
man-in-the-middle attacks even if the paths between A, B
and B, C (Figure 2) have been secured with TLS or IPsec.

The RADIUS server MUST check the Digest-Realm attribute it has
received from a client. If the RADIUS client is not authorized to
serve HTTP-style clients of that realm, it might be compromised.

RADIUS clients implementing the extension described in this document
may authenticate HTTP-style requests received over the Internet. As
compared with use of RADIUS to authenticate link layer network
access, an attacker may find it easier to cover their tracks in
such a scenario.

An attacker can attempt a denial of service attack on one or
more RADIUS servers by sending a large number of HTTP-style
requests. To make simple denial of service attacks more difficult,
the nonce issuer (RADIUS client or server) MUST check if it has
generated the nonce received from an HTTP-style client.
This SHOULD be done statelessly. For example, a nonce could
consist of a cryptographically random part and some kind
of signature provided by the RADIUS client, as described in [RFC2617],
section
3.2.1.

RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
attributes in Access-Challenge messages. A man in the middle can
modify or remove those attributes in a bidding down attack, causing
the RADIUS client to use a weaker authentication scheme than
intended.

The Message-Authenticator attribute, described in [RFC3579]
section 3.2 MUST be included in Access-Request, Access-Challenge,
Access-Reject and Access-Accept messages that contain attributes
described in this specificaiton.

The Digest-HA1 attribute contains no random components if the
algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary
attacks easier and enables replay attacks.

HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. Instead of TLS, IPsec can be used,
too. TLS or IPsec secure the connection while Digest Authentication
authenticates the user. The RADIUS transaction can be regarded as
one leg on the path between the HTTP-style client and the HTTP-style
server. To prevent RADIUS from representing the weak link, a
RADIUS client receiving an HTTP-style request via TLS
or IPsec MUST use an equally secure connection to the RADIUS server.
There are two ways to achieve this:
o the RADIUS client may reject HTTP-style requests received over TLS or
IPsec
o the RADIUS client require that traffic be sent and recieved over
IPsec.
RADIUS over IPsec, if used, MUST conform to the requirements
described in [RFC3579] section 4.2."

--
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, 11 Aug 2005 20:52:10 +0000
Date: Thu, 11 Aug 2005 13:51:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 121: Data Representation

Issue 121: Data Representation
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 11, 2005
Reference:
Document: DIGEST-03
Comment type: T
Priority: S
Section: 3.5
Rationale/Explanation of issue:

In Section 3.5, it says:

" Text
It is recommended that this text be base64 or hexadecimal data."

For interoperability, you need to choose the representation or at least
specify how it can be determined which representation is to be used.

--
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, 11 Aug 2005 19:07:11 +0000
Date: Thu, 11 Aug 2005 12:07:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 118:  Editorial NITs

Issue 118: Editorial NITs
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 11, 2005
Reference:
Document: DIGEST-03
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1.1

HTTP-style protocol
a protocol using HTTP digest, like HTTP, SIP.

Change "a protocol" to "A protocol"

The combination of realm and digest URI the use of which is
authorized by the RADIUS server.

Change "URI the" to "URI, the"

Please include definitions of NAS, UA and UAS in the terminology section.

Section 1.3

"digest into the message" -> "digest within the message"

Change:

" Instead of maintaining a local user database, the server could use
RADIUS. However, RADIUS does not support HTTP digest without an
extension like the one described in this document. The RADIUS client
can not send a User-Password attribute as it does not receive a
password from the HTTP-style client. The RADIUS mechanism for CHAP
resembles HTTP digest, but the digest algorithms are not compatible.

This document extends RADIUS to support Digest Authentication, via
addition as a native authentication mechanism. An implementation
supporting this extension MUST include a Digest-Response attribute
within an Access-Request packet where Digest authentication is
desired. An Access-Request MUST NOT contain both a Digest-Response
attribute and another authentication attribute, such as User-
Password, CHAP-Password, or EAP-Message.

This document defines new attributes that enable the RADIUS server to
perform the digest calculation defined in [RFC2617]."

To:

" Instead of maintaining a local user database, the server could use
RADIUS. However, RADIUS [RFC2865] does not include support for
HTTP digest authentication. The RADIUS client can not use the
User-Password attribute, since it does not receive a password
from the HTTP-style client. The CHAP-Challenge and CHAP-Password
attributes are also not suitable since the CHAP algorithm is
not compatible with HTTP digest.

This document defines new attributes that enable the RADIUS server to
perform the digest calculation defined in [RFC2617], providing
support for Digest Authentication as a native authentication
mechanism within RADIUS. An implementation supporting this
extension MUST include a Digest-Response attribute
within an Access-Request packet where Digest authentication is
desired. An Access-Request MUST NOT contain both a Digest-Response
attribute and another authentication attribute, such as User-
Password, CHAP-Password, or EAP-Message."

Change:

" The nonces required by the digest algorithm are either generated by
the RADIUS client or by the RADIUS server. A mix of nonce generation
modes is not supported.

RADIUS clients and servers can support one, or both nonce generation
modes.

If the RADIUS server generates nonces, its RADIUS clients MUST NOT
try to generate nonces. If the RADIUS server does not generate
nonces, its RADIUS clients MUST generate nonces locally. If at least
one HTTP-style client requires AKA authentication [RFC3310], the
RADIUS server MUST generate nonces and its RADIUS clients MUST NOT
generate nonces locally. The nonce generation mode is a configurable
parameter"

To:

" The nonces required by the digest algorithm are either generated by
the RADIUS client or by the RADIUS server. A mix of nonce generation
modes is not supported. RADIUS clients and servers can support one,
or both nonce generation modes.

If the RADIUS server generates nonces, its RADIUS clients MUST NOT
try to generate nonces. If the RADIUS server does not generate
nonces, its RADIUS clients MUST generate nonces locally. If at least
one HTTP-style client requires AKA authentication [RFC3310], the
RADIUS server MUST generate nonces and its RADIUS clients MUST NOT
generate nonces locally. The nonce generation mode is a configurable
parameter."

Section 1.3.1

change "without authorization header" to "without an authorization header"
in this section.

"If credentials were accepted B" -> "If credentials were accepted, B"

Section 1.3.2

change:

" In most cases, the operation outlined in Section 1.3.1 is sufficient.
It reduces the load on the RADIUS server to a minimum. However, when
using AKA [RFC3310] the nonce is partially derived from a precomputed
authentication vector. These authentication vectors are often stored
centrally.

Figure 3 depicts a scenario, where the RADIUS server chooses nonces.
It shows a generic case where entities A and B communicate in the
front-end using protocols such as HTTP/SIP, while entities B and C
communicate in the back-end using RADIUS."

To:

" While the usage scenario described in Section 1.3.1 minimizes the load
on the RADIUS server, alternatives are required in some situations. When
using AKA [RFC3310] the nonce is partially derived from a precomputed
authentication vector, which is often stored centrally.

Figure 3 depicts a scenario in which the RADIUS server chooses nonces.
In this case entities A and B communicate in the using HTTP or SIP,
while entities B and C communicate using RADIUS."

Change:

" The relevant order of messages sent in this scenario is as follows:"

to:

" The following messages are sent in this scenario:"

Section 2.1

The first paragraph seems a bit awkard. Does this really belong
in Section 2.1, or might it belong in the Security Considerations
Section?

Change:

" If the messages between RADIUS client and RADIUS server are not
protected with IPsec, the RADIUS client MUST NOT accept secured
connections (like https or sips) from its HTTP-style clients (or else
the HTTP-style clients would have a false sense of security)."

To:

" The attributes described in this document are sent in cleartext.
Therefore were a RADIUS client to accept secured connections
(https or sips) from HTTP-style clients, this could result in
information intentionally protected by HTTP-style clients being
sent in the clear during the RADIUS exchange.

If the messages between RADIUS client and RADIUS server are not
protected with IPsec, the RADIUS client MUST NOT accept secured
connections (like https or sips) from its HTTP-style clients, so
that HTTP-style clients are not provided with a false sense of
security."

Change:

" On reception of an HTTP-style request message, the RADIUS client
checks whether it is responsible to authenticate the request. There
are situation where an HTTP-style request traverses several proxies,
and each of the proxies request to authenticate the HTTP-style
client. In this situation, it is a valid scenario that a HTTP-style
request received at a HTTP-style server contains several sets of
credentials. The 'realm' directive in HTTP is the key that the
RADIUS client can use to determine which credential is applicable.
It may happen also that none of the realms are of interest to the
RADIUS client, in which case the RADIUS client MUST consider that no
credentials (of interest) were sent. In any case, a RADIUS client
MUST send zero or exactly one credential to the RADIUS server. The
RADIUS client MUST choose the credential of the (Proxy-)Authorization
header where the realm directive matches its locally configured realm
value.

If such a header is present and contains HTTP digest information, the
RADIUS client checks the 'nonce' parameter. If the RADIUS client
generates nonces but did not issue the received nonce, it responds
with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to
the HTTP-style client. In this error response, the RADIUS client
sends a new nonce.

If the RADIUS client recognizes the nonce or does not generate
nonces, it takes the header directives and puts them into a RADIUS
Access-Request message. It puts the 'response' directive into a
Digest-Response attribute and the realm / nonce / digest-uri / qop /
algorithm / cnonce / nc / username / opaque directives into the
respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-
Username / Digest-Opaque attributes. The request method is put into
the Digest-Method attribute. The RADIUS clients adds a Message-
Authenticator (see [RFC3579]) attribute. Now, the RADIUS client
sends the Access-Request message to the RADIUS server.

The RADIUS server processes the message and responds with an Access-
Accept or an Access-Reject message."

To:

"On reception of an HTTP-style request message, the RADIUS client
checks whether it is authorized to authenticate the request. Where
an HTTP-style request traverses several proxies and each of the
proxies request to authenticate the HTTP-style client the request
at the HTTP-style server may contain multiple credential sets.

The RADIUS client can use the 'realm' directive in HTTP to determine
which credentials are applicable. Where none of the realms are of
interest, the RADIUS client MUST behave as though no
relevant credentials were sent. In all situations the RADIUS client
MUST send zero or exactly one credential to the RADIUS server. The
RADIUS client MUST choose the credential of the (Proxy-)Authorization
header if the realm directive matches its locally configured realm.

If such a (Proxy-)Authorization header is present and contains
HTTP digest information, the RADIUS client checks the 'nonce'
parameter. If the RADIUS client generates nonces but did not issue
the received nonce, it responds with a 401 (Unauthorized) or
407 (Proxy Authentication Required) to the HTTP-style client.
In this error response, the RADIUS client sends a new nonce.

If the RADIUS client recognizes the nonce or does not generate
nonces, it takes the header directives and puts them into a RADIUS
Access-Request message. It puts the 'response' directive into a
Digest-Response attribute and the realm / nonce / digest-uri / qop /
algorithm / cnonce / nc / username / opaque directives into the
respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-
Username / Digest-Opaque attributes. The request method is put into
the Digest-Method attribute. The RADIUS client adds a Message-
Authenticator attribute, defined in [RFC3579] and sends the
Access-Request message to the RADIUS server.

The RADIUS server processes the message and responds with an Access-
Accept or an Access-Reject."

--
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, 11 Aug 2005 19:02:34 +0000
Date: Thu, 11 Aug 2005 12:02:04 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 117:  Transport Behavior

Issue 117: Transport Behavior
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 11, 2005
Reference:
Document: DIGEST-03
Comment type: T
Priority: S
Section: 2.1, 2.2
Rationale/Explanation of issue:

In at least two places, this document changes the basic transport behavior
of RADIUS. If a RADIUS client does not receive a response from a RADIUS
server, it retransmits the Request or fails over to another RADIUS server.
A RADIUS client that automatically rejects user access without
retransmission or failover is badly behaved.

In general, a RADIUS server only silently discards a packet if
it is invalid, such as a packet containing a Request Authenticator
(Accounting) or Message-Authenticator attribute that does not verify.
Unless there is a loading problem, silently discarding packets is a bad
idea since the client will just retransmit or failover to another RADIUS
server. If the Access-Request is valid but is requesting an unauthorized
service, the correct response is an Access-Reject, not silent discard.

In Section 2.1,

Change:

" The RADIUS server MAY have added a Digest-Nextnonce attribute into an
Access-Accept message. If the RADIUS client discovers this, it puts
the contents of this attribute into a 'nextnonce' directive. Now it
can send an HTTP-style response.

If the RADIUS client did receive an HTTP-style request without a
(Proxy-)Authorization header matching its locally configured realm
value, it obtains a new nonce and sends an error response (401 or
407) containing a (Proxy-)Authenticate header.

If the RADIUS client receives an Access-Reject or no response from
the RADIUS server, it sends an error response to the HTTP-style
request it has received.

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 message, 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 message. The RADIUS
server chooses a nonce and responds with an Access-Challenge
containing a Digest-Nonce attribute.

The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
Realm, 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 receives an Access-Challenge message in response
to an Access-Request containing a Digest-Nonce attribute, the RADIUS
server did not accept the nonce. If a Digest-Stale attribute is
present in the Access-Challenge and has a value of 'true' (without
quotes), the RADIUS client sends an error (401 or 407) response
containing WWW-/Proxy-Authenticate header with the directive 'stale'
and the digest directives derived from the Digest-* attributes."

To:

" The RADIUS server MAY include a Digest-Nextnonce attribute within an
Access-Accept message. A RADIUS client receiving a Digest-Nextnonce
attribute places the contents of this attribute into a 'nextnonce'
directive within a response sent to the HTTP-style client.

If the RADIUS client receives an HTTP-style request without a
(Proxy-)Authorization header matching its locally configured realm
value, it obtains a new nonce and sends an error response (401 or
407) containing a (Proxy-)Authenticate header.

If the RADIUS client receives an Access-Reject it sends an error
response to the HTTP-style request it has received. If the
RADIUS client does not receive a response, it retransmits or fails
over to another RADIUS server as described in [RFC2865].

The RADIUS client has three ways to obtain nonces: it can generate
them locally, it may receive a Digest-Nextnonce attribute within an
Access-Accept message, or it may ask the RADIUS server to generate one.
To do the latter, it sends an Access-Request containing Digest-Method
and Digest-URI attributes, but without a Digest-Nonce attribute. The
RADIUS client then adds a Message-Authenticator attribute to the
Access-Request message. The RADIUS server chooses a nonce and responds
with an Access-Challenge containing a Digest-Nonce attribute.

The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
Realm, Digest-Domain and Digest-Opaque attributes in the
Access-Challenge carrying the nonce. If these attributes are present, the
RADIUS client MUST use them.

If the RADIUS client sends an Access-Request containing a Digest-Nonce
attribute and receives an Access-Challenge message in response,
the RADIUS server did not accept the nonce. If a Digest-Stale attribute is
present in the Access-Challenge and has a value of 'true' (without
quotes), the RADIUS client sends an error (401 or 407) response
containing WWW-/Proxy-Authenticate header with the directive 'stale'
and the digest directives derived from the Digest-* attributes."

In Section 2.2,

Change:

" If the RADIUS server receives an Access-Request message with a
Digest-Method and a Digest-URI attribute but without a Digest-Nonce
attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce
attribute and sends it in an Access-Challenge message to the RADIUS
client. The RADIUS server MUST add Digest-Realm, Message-
Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or
more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes
to the Access-Challenge message. If the server cannot choose a
nonce, it replies with an Access-Reject message.

If the RADIUS server receives an Access-Request message containing a
Digest-Response attribute, it looks for the following attributes:
Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
Digest-Algorithm, Digest-Username. Depending on the content of
Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body-
Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and
[RFC3310] for details. If the Digest-Algorithm attribute is missing,
'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque
attribute along with the nonce, the Access-Request MUST have a
matching Digest-Opaque attribute.

If mandatory attributes are missing, it MUST respond with an Access-
Reject message. If the attributes are present, the RADIUS server
calculates the digest response as described in [RFC2617]. To look up
the password, the RADIUS server uses the RADIUS User-Name attribute.
The RADIUS server MUST check if the user identified by the User-Name
attribute
o is authorized to access the protection space defined by the
Digest-URI and Digest-Realm attributes,
o is authorized to use the URI included in the SIP-AOR attribute, if
this attribute is present.
If any of those checks fails, the RADIUS server MUST send an Access-
Reject.

Correlation between User-Name and SIP-AOR AVP values is required just
to avoid that any user can register or misuse a SIP-AOR allocated to
another user.

A RADIUS server MUST check if the RADIUS client is authorized to
serve users of the realm mentioned in the Digest-Realm attribute. If
the RADIUS client is not authorized, the RADIUS server silently
discards the Access-Request message. Other actions taken by the
RADIUS server are out of scope of this document. However, the RADIUS
server should notify the operator and may take additional action such
as discarding all future requests from this client, until some
management action tells it to do so again.

All values required for the digest calculation are taken from the
Digest attributes described in this document. If the calculated
digest response equals the value received in the Digest-Response
attribute, the authentication was successful. If not, the RADIUS
server responds with an Access-Reject."

to:

" If the RADIUS server receives an Access-Request message with
Digest-Method and Digest-URI attributes, but without a Digest-Nonce
attribute, sends an Access-Challenge message to the RADIUS client
containing a nonce within a Digest-Nonce atribute.
The RADIUS server MUST include Digest-Realm and Message-Authenticator
attributes within the Access-Challenge and SHOULD include Digest-Algorithm
and one or more Digest-Qop attributes. The RADIUS server MAY include
Digest-Domain and Digest-Opaque attributes in the Access-Challenge
message. If the server cannot choose a nonce, it replies with an
Access-Reject message.

If the RADIUS server receives an Access-Request message containing a
Digest-Response attribute, it looks for the following attributes:
Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
Digest-Algorithm, Digest-Username. Depending on the content of
Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body-
Hash, Digest-CNonce and Digest-AKA-Auts attributes; see [RFC2617] and
[RFC3310] for details. If the Digest-Algorithm attribute is missing,
'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque
attribute along with the nonce, the Access-Request MUST have a
matching Digest-Opaque attribute.

If mandatory attributes are missing, the RADIUS server MUST respond
with an Access-Reject. If the required attributes are present, the
RADIUS server calculates the digest response as described in [RFC2617].
The RADIUS server determines the required credentials based on the
contents of the User-Name attribute sent in the Access-Request.
The RADIUS server MUST check if the user identified by the User-Name
attribute:
o is authorized to access the protection space defined by the
Digest-URI and Digest-Realm attributes,
o is authorized to use the URI included in the SIP-AOR attribute, if
this attribute is present.
If any of these checks fail, the RADIUS server MUST send an Access-Reject.

Correlation between User-Name and SIP-AOR AVP values is required to
prevent a user from registering or misusing a SIP-AOR allocated to
another user.

A RADIUS server MUST check if the RADIUS client is authorized to
serve users of the realm provided in the Digest-Realm attribute. If
the RADIUS client is not authorized, the RADIUS server MUST send
an Access-Reject. The RADIUS server SHOULD log the event so as
to notify the operator, and MAY take additional action such
as sending an Access-Reject in response to all future requests
from this client, until this behavior is reset by management action.

All values required for the digest calculation are taken from the
Digest attributes described in this document. If the calculated
digest response equals the value received in the Digest-Response
attribute, the authentication was successful. If not, the RADIUS
server responds with an Access-Reject."

--
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, 11 Aug 2005 15:00:02 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: AW: Do we have consensus on the Digest Auth draft issues?
Date: Thu, 11 Aug 2005 16:59:53 +0200

Bernard wrote:
> Dave wrote:
> > The substantive issue with the draft-ietf-radext-diget-auth-03.txt 
> > seems to be how to deal with Diameter interoperability of the two 
> > different sources of nonce.  The general sense of the room at IETF-63 
> > seemed to be that the Digest Auth draft needed to support both modes, 
> > and that the companion Diameter draft would need to follow suit.  This 
> > places the Diameter compatibility action item with the Diameter 
> > document.
> >
> > Does the WG at large agree?  Please reply.
> 
> Personally, I agree.  But then again, I was the person who 
> first suggested moving the  Diameter compatibility section to 
> the Diameter document :)
> 
> > Assuming that we do agree, then what action item doe we have w.r.t. 
> > the Diameter document?
> 
> I think the implication is that the Diameter document (which 
> has been in simulaneous WG last call with Digest) needs to 
> own the compatibility section.
> 

I am preparing a -04 version of the draft correcting a few nits
-- like the text/table mismatch discovered by Hideo Morishita --
and without the Diameter migration section. I have asked Miguel
Garcia whether he could add the client-side nonce generation mode
and the RADIUS/Diameter migration section into
draft-ietf-diameter-sip-app. If there are no new issues with -03,
I will submit -04 tomorrow.

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: Thu, 11 Aug 2005 14:57:55 +0000
Content-class: urn:content-classes:message
Subject: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:57:40 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: David Nelson
Submitter email address: [email-masked]=20
Date first submitted: August 10, 2005
Reference: (missing from the RADEXT archive ???)
Document: VLAN, Priority and Filtering Attributes=20
Comment type: 'E' Editorial
Priority: '1' Should fix
Section: 4.1
Rationale/Explanation of issue:

4.1.  Acct-NAS-Filter-Rule

          The first eight octets of this string are used for a 64-bit=20
          value of the rule counter.  The remaining octets are used to=20
          specify which filter rule the counter value is for.  The rule=20
          specification MUST conform to the syntax rules specified for=20
          NAS-Filter-Rule[TODO].

[TODO] indicates an open action item.

Requested changes:

Provide the [TODO].

--
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, 11 Aug 2005 14:55:13 +0000
Content-class: urn:content-classes:message
Subject: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:54:16 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: August 10, 2005
Reference: (missing from the RADEXT archive ???)
Document: VLAN, Priority and Filtering Attributes=20
Comment type: 'E' Editorial
Priority: '1' Should fix
Section: 3.5
Rationale/Explanation of issue:

Clarification of the text.

Requested changes:

         Furthermore, the concatenated filter list=20
         must abide to the following rules of precedence and ordering:=20
         =20
            1) A flush rule MUST appear before all other rule types.=20

Change "A flush rule" to "A flush rule, when present,".

            2) Base encapsulation filter rules MUST appear after a=20
               flush rule and before IP tunnel, HTTP redirect, IP=20
               filter, and/or HTTP filter rules.

Change "a flush rule" to "any flush rule".

          dir        "in" is from the terminal, "out" is to the=20
                     terminal, "inout" is from and to the terminal.

The term "terminal" is not defined in the draft.  I suspect it
identifies the network entity which contains the IEEE 802.1X Supplicant
function, but this should perhaps be clarified.

General comment:  I'd much rather that we use ABNF to define the
NAS-Filter-Rule formal syntax, however I'm not prepared to submit that
text just now.  :-)

--
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, 11 Aug 2005 14:54:12 +0000
From: Narayanan Vidya-CVN065 <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: RE: AAA for Handovers
Date: Thu, 11 Aug 2005 09:53:52 -0500

> Pre-emptive keying seeds the key cache at potential points of
> attachment, but the EAP peer only authenticates with the 
> target NAS, the AAA server never confirms that the EAP peer 
> used the key.  The only indication the AAA server receives is 
> an Accounting-Start from the target NAS, indicating that the 
> EAP peer has connected.
> 
> Because the AAA server can never confirm that the EAP peer
> was even considering the target NAS, it has no way to know 
> whether the Accounting-Start it received is authentic.  This 
> enables a rogue operator to generate fraudulent accounting 
> records that cannot be easily checked by the AAA server.
> 

I am not very familiar with how accounting works. Is the Accounting-Start message not authenticated? If it is authenticated using an SA shared between the NAS and the AAA server, I am wondering why that isn't enough to trust the NAS. 

> 
> The requirement that the EAP peer demonstrate interest in the 
> target NAS and prove its identity means that there is an 
> authentication attempt to go along with the Accounting-Start.
> 
> 

Is it that the AAA server relies on the successive timing of the authentication via the target NAS and the Accounting-Start message? Or, is the AAA server keeping track of the fact that the MN authenticated through the target NAS and checks that when receiving the Accounting-Start? If it is the former, isn't there a problem with pre-authentication itself? The MN may have pre-authenticated via a target NAS well before handoff, but an Accounting-Start may be sent much later. On the other hand, if it is the latter, doesn't this cause concern for the state build-up in the AAA server? 

> 
> From what I can tell, the security of the "Key Request" 
> scheme is equal to or better than pre-emptive keying, without 
> requiring server-initiated messages or changes to the lower 
> layer neighbor reporting mechanisms.
> 

It seemed like there was concern about evolving key hierarhies - is that not true? For e.g., typically in EAP, the MSK is generated and using that MSK, the NAS and STA derive transient keys. In 802.11r, it seems like the R0, R1, R2 keys (I think they are called PMK-Rx) are derived successfully from one another, R0 being the MSK (in most cases). I noticed that there was no freshness added in generating these PMKs. Are such schemes as secure as regular EAP key derivation? 

> 
> One thing to keep in mind is that the total transaction time 
> is not the only factor determining whether a handoff can be 
> completed in time. A more important factor is the key cache 
> hit rate and the lead time.  If knowledge of key state is 
> synchronized and the neighboring NASes can be determined well 
> ahead of time, then the introduction of one or more 
> roundtrips to the AAA server may not matter that much because 
> EAP authentication or "Key Request" may be a rare event.
> 
> As an example, in a building where there are two WLAN 
> switches, an EAP peer with an awareness of the key cache 
> boundaries would only need to authenticate with each switch 
> once a key cache entry had expired.  So if the key lifetime 
> is 24 hours, the peer might authenticate with each switch at 
> the beginning of the day, and then not do any other EAP 
> authentications until the next day.
> 
> In such a situation the extra round-trips to the AAA server 
> of an EAP pre-authentication or "Key Request" do not affect 
> performance or AAA server loading that adversely.
> 

Yes, to an extent this becomes dependent on topology and makes it somewhat difficult to generalize the requirements here. 

> 
> I think it would probably be worth bringing the issue up in 
> IEEE 802.11r, so as to clarify exactly what (if anything) 
> they want from the IETF. From my perspective, a very valuable 
> contribution would be to develop a requirements document that 
> states clearly what the problem is and what a good solution 
> would look like.  For example, to date there are a lot of 
> different notions of what "fast" means, or what scenarios 
> need to be supported and why.  Without consensus on what the 
> problem is or how we know when it is solved, it is difficult 
> to make much progress.
> 

Okay. 

Thanks,
Vidya

--
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, 11 Aug 2005 14:46:17 +0000
Content-class: urn:content-classes:message
Subject: Issue: Technical comments on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:45:35 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: August 10, 2005
Reference: (missing from the RADEXT archive ???)
Document: VLAN, Priority and Filtering Attributes
Comment type: 'T' Technical
Priority: '0' Must fix
Section: 3.1
Rationale/Explanation of issue:

Integer=20
   =20
         The Integer field is four octets in length.  The format of the=20
         Integer field consists of two parts, the first consuming high-
         order octet and the second consuming the remaining three lower-
         order octets.  The high-order octet field indicates if the=20
         VLANID is allowed for tagged or untagged packets.  The second=20
         part is the 12-bit 802.1Q VLAN VID value that has been padded=20
         out to consume the remaining three lower-order octets.  A=20
         sample encoding follows: =20

This is not an Integer data type.  It is a multi-field Octet String
(complex data type).

Requested changes:

Express a String data type (with sub-fields).

--
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, 11 Aug 2005 14:42:24 +0000
Content-class: urn:content-classes:message
Subject: Issue: Technical comments on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:42:06 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: August 10, 2005
Reference: (missing from the RADEXT archive ???)
Document: VLAN, Priority and Filtering Attributes
Comment type: 'T' Technical
Priority: '0' Must fix
Section: 2.2
Rationale/Explanation of issue:

Text appears to create retroactive normative requirements on existing
implementations.

Requested changes:

Change:

      Similarly, if a NAS conforming to this specification receives a=20
      CoA message that contains an attribute from this document that it=20
      does not recognize or cannot apply, it MUST NOT terminate the=20
      session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101)=20
      set to "Unsupported Attribute"(401). =20

To:

      Similarly, if a NAS conforming to this specification and also
      conforming to RFC 3576 [RFC3576] receives a CoA message that=20
      contains an attribute from this document that it does not=20
      recognize or cannot apply, it MUST NOT terminate the session and
      MUST generate a CoA-NAK packet with Error-Cause (101) set to
      "Unsupported Attribute"(401). =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, 11 Aug 2005 14:36:36 +0000
Content-class: urn:content-classes:message
Subject: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:36:04 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C59E82.0076EB40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Submitter name: David Nelson

Submitter email address: [email-masked]

Date first submitted: August 10, 2005

Reference: (missing from the RADEXT archive ???)

Document: VLAN, Priority and Filtering Attributes

Comment type: 'E' Editorial

Priority: '1' Should fix

Section: 2.1

Rationale/Explanation of issue:

=20

This section seems out of place.

=20

2.1 Capability Advertisement=20

      =20

      RADIUS does not currently define a method by which a NAS can=20

      advertise its capabilities and in many instances, it would be=20

      desirable for the home network to know what capabilities are=20

      supported by the NAS to ensure proper operational behavior. The=20

      attributes defined in this document are intended to be used to=20

      enforce policy by the NAS. If a NAS does not recognize these=20

      attributes it will most likely ignore them and the desired policy=20

      will not be enforced. A method for the NAS advertising the=20

      capability to support these attributes would help the RADIUS=20

      server understand if the intended policies can be enforced. As a=20

      result, the attributes in this document, in particular NAS-Filter-

      Rule(TBD), can benefit from capability advertisement, if=20

      available. =20

=20

Requested changes:

=20

Should this entire section perhaps be part of the Security
Considerations?

=20

------_=_NextPart_001_01C59E82.0076EB40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Submitter name: =
David Nelson<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Submitter email =
address: <a
href=3D"mailto:[email-masked]">[email-masked]</a><o:p></o:p=
></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Date first =
submitted: August
10, 2005<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Reference: (missing =
from the
RADEXT archive ???)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Document: VLAN, =
Priority and
Filtering Attributes<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Comment type: 'E' =
Editorial<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Priority: '1' =
Should fix<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Section: =
2.1<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Rationale/Explanation of
issue:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This section seems =
out of
place.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>2.1 Capability =
Advertisement
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RADIUS does not
currently define a method by which a NAS can =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; advertise its
capabilities and in many instances, it would be =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; desirable for the home
network to know what capabilities are <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; supported by the NAS
to ensure proper operational behavior. The <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attributes defined in
this document are intended to be used to <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enforce policy by the
NAS. If a NAS does not recognize these <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attributes it will
most likely ignore them and the desired policy =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will not be enforced.
A method for the NAS advertising the <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; capability to support
these attributes would help the RADIUS <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; server understand if
the intended policies can be enforced. As a =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; result, the attributes
in this document, in particular NAS-Filter-<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rule(TBD), can benefit
from capability advertisement, if <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; available.&nbsp; =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Requested =
changes:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Should this entire =
section
perhaps be part of the Security =
Considerations?<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C59E82.0076EB40--

--
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, 11 Aug 2005 14:33:04 +0000
Content-class: urn:content-classes:message
Subject: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:32:18 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C59E81.79D7F458
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Submitter name: David Nelson

Submitter email address: [email-masked] Date first submitted:
August 10, 2005

Reference: (missing from the RADEXT archive ???)

Document: VLAN, Priority and Filtering Attributes Comment type: 'E'
Editorial

Priority: '1' Should fix

Section: 2

Rationale/Explanation of issue:

=20

Better phrasing.

=20

Requested changes:

=20

(1)

=20

The first paragraph is awkwardly worded.  Perhaps the following would be
an improvement.

=20

      In this section we provide an elaboration of the requirements=20

      briefly described in the Introduction.

=20

(2)

=20

      For example, the user maybe on=20

      a prepaid plan and all the resources have been used up.

=20

Change "maybe" to "may be" and "resources have" to "credit balance has".

=20

(3)

=20

      For example, the ability to block and=20

      redirect traffic is required for TCP users, cell phone users,

      WiFi users.

=20

Change "TCP users" to "IP users".

=20

(4)

=20

Change:

=20

      As pointed out by [NASREQ] the use Filter-Id is not roaming=20

      friendly and it is recommended that instead one should use NAS-

      Filter-Rule(TBD) AVP.  For this reason, this document introduces=20

      NAS-Filter-Rule(TBD) to RADIUS.

=20

To:

=20

      As pointed out by [NASREQ] the use Filter-Id is not roaming=20

      friendly and it is recommended that instead one should adapt=20

      the Diameter NAS-Filter-Rule AVP as a RADIUS NAS-Filter-Rule(TBD)

      attribute.

=20

=20

------_=_NextPart_001_01C59E81.79D7F458
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Submitter name: =
David Nelson<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Submitter email =
address:
[email-masked] Date first submitted: August 10, =
2005<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Reference: (missing =
from the
RADEXT archive ???)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Document: VLAN, =
Priority and
Filtering Attributes Comment type: 'E' =
Editorial<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Priority: '1' =
Should fix<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Section: =
2<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Rationale/Explanation of
issue:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Better =
phrasing.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Requested =
changes:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>(1)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The first paragraph =
is
awkwardly worded.&nbsp; Perhaps the following would be an =
improvement.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In this section we
provide an elaboration of the requirements <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; briefly described in
the Introduction.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>(2)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For example, the user
maybe on <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a prepaid plan and all
the resources have been used up.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Change =
&quot;maybe&quot; to
&quot;may be&quot; and &quot;resources have&quot; to &quot;credit =
balance
has&quot;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>(3)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For example, the
ability to block and <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; redirect traffic is
required for TCP users, cell phone users,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WiFi =
users.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Change &quot;TCP =
users&quot;
to &quot;IP users&quot;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>(4)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Change:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As pointed out by
[NASREQ] the use Filter-Id is not roaming <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; friendly and it is
recommended that instead one should use =
NAS-<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filter-Rule(TBD) AVP.&nbsp;
For this reason, this document introduces <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAS-Filter-Rule(TBD)
to RADIUS.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>To:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;As pointed out by
[NASREQ] the use Filter-Id is not roaming <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; friendly and it is
recommended that instead one should adapt <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Diameter
NAS-Filter-Rule AVP as a RADIUS =
NAS-Filter-Rule(TBD)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
attribute.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C59E81.79D7F458--

--
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, 11 Aug 2005 14:29:42 +0000
Content-class: urn:content-classes:message
Subject: Issue: Editorial commets on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:28:59 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C59E81.0368A6E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Submitter name: David Nelson

Submitter email address: [email-masked]

Date first submitted: August 10, 2005

Reference: (missing from the RADEXT archive ???)

Document: VLAN, Priority and Filtering Attributes

Comment type: 'E' Editorial

Priority: '1' Should fix

Section: 1.1

Rationale/Explanation of issue:

=20

The following definitions are not used in the draft:

=20

Access Point

Association

Station

=20

Requested change:

=20

Please delete them.

=20

=20

------_=_NextPart_001_01C59E81.0368A6E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Submitter name: David Nelson<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Submitter email address: =
[email-masked]<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Date first submitted: August 10, =
2005<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Reference: (missing from the RADEXT archive =
???)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Document: VLAN, Priority and Filtering =
Attributes<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Comment type: 'E' Editorial<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Priority: '1' Should fix<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Section: 1.1<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Rationale/Explanation of issue:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The following =
definitions
are not used in the draft:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Access =
Point<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Association<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Station<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Requested =
change:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Please delete =
them.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C59E81.0368A6E0--

--
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, 11 Aug 2005 14:27:24 +0000
Content-class: urn:content-classes:message
Subject: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:26:12 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: August 10, 2005
Reference: (missing from the RADEXT archive ???)
Document: VLAN, Priority and Filtering Attributes
Comment type: 'E' Editorial
Priority: '1' Should fix
Section: 1
Rationale/Explanation of issue:

Better phrasing.

Requested changes:

(1)=20

       Within the confines of RADIUS authentication, authorization, and
       accounting (AAA) environments, there is a general dearth of
       standardized RADIUS attributes to limit user access using dynamic
       VLANs, filters or redirection.
=20
=20
Could we change "a general dearth of" to "a requirement for"?  It sounds
more positive.

(2)

      IEEE 802.1X-2004 [IEEE8021X] provides "network port=20
      authentication" for IEEE 802 [IEEE802] media, including Ethernet=20
      [IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i].

Remove this sentence as it appears in the second paragraph as well.

--
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, 11 Aug 2005 14:15:55 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt
Date: Thu, 11 Aug 2005 10:15:07 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

> My WGLC comments on the subject draft are included herein.

I wanted to send my comments by the close of WGLC, but I will now
proceed to re-submit each of these items as RADEXT 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: Thu, 11 Aug 2005 06:37:40 +0000
Date: Wed, 10 Aug 2005 23:37:01 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 114: WGLC Review

Issue 114: WGLC Review
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 10, 2005
Reference:
Document: IEEE802-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Accounting

I do not understand the purpose of the accounting functionality in the
draft.

The focus of this document is VLAN attribute, priority and filtering. How
does Acct-EAP-Auth-Method fit into that? I think this is a leftover WLAN
attribute which should be removed.

Acct-NAS-Filter-Rule attribute. The purpose of this attribute is to keep
count
of hits on filter rules. This duplicates functionality under development
in
other WGs such as IPFIX, and so I'd question whether this is appropriate
functionality for RADIUS accounting.

Overview

I do not understand the purpose of Section 2, Overview. Most of it seems
like it could be deleted without losing anything.

" As described in the Introduction section, it may be desirable to a
control user's access to network resources (e.g. the Internet)
with greater standardized explicitness than what current RADIUS
attributes provide. In this section we will examine these
requirements in more detail. "

What is "standardized explicitness?" The filtering functionality defined
in this document is no more granular than what is already supported in the
Filter-ID attribute. So this sentence seems inaccurate.

" Besides IEEE 802.1X networks, there is a corollary need within
Internet Service Provider (ISP) environments for standardized
authorization attributes."

What is an IEEE 802.1X network? Do you mean an IEEE 802 network?
RADIUS has supported authorization attributes for a long time, this
sentence makes it seem like this is the first time that authorization
attributes have been defined in RADIUS. Also, mixing ISPs and IEEE 802
functionality in the same document is a symptom of a deeper problem which
Greg Weber has brought up -- it is not clear what devices need to do in
order to comply with the document, if compliance is even possible.

" From time to time, an ISP requires to
restrict a user's access to the Internet and redirect their
traffic to an alternate location. For example, the user maybe on
a prepaid plan and all the resources have been used up."

Since this implies that the document is actually aimed at prepaid,
I think you need a reference here.

The ability to block user's traffic is required at service
initiation and once service has been established. These
capabilities must also be available across access technologies and
various business scenarios. For example, the ability to block and
redirect traffic is required for TCP users, cell phone users, WiFi
users. As well, this capability must work whether the user is in
their home network or roaming in a visited network which may or
may not have a direct roaming relationship with the user's home
network.

This seems like a list of requirements that this document was supposed to
satisfy. However, I would question whether in fact these requirements
are legitimate. This documented started out focussed on IEEE 802
functionality -- how did it somehow morph into a document relating to
prepaid, portals, etc.?

" Blocking access refers to setting up access control rules at the
NAS such that when the user initiates IP traffic, the NAS examines
the set of rules associated with the service granted to the user.
These rules determine what traffic is allowed to proceed through
the NAS and what traffic will be blocked. Today this capability
is supported in RADIUS and is configurable during service
establishment and mid-service via the Filter-Id(11) attribute. To
use Filter-Id to control access to network resources the rules
need to be configured apriori at each NAS. Filter-Id(11) is used
in an Access-Accept to specify the name of the filter rule(s) to
apply to this session. To effect a change mid-service
(dynamically), the Filter-Id(11) is included in a Change-of-
Authorization (COA) packet as described in [RFC3676]. Upon
receiving the Filter-Id(11) the NAS starts to apply the rules
specified by the Filter-Id(11)."

I'm not sure why this document needs to discuss Filter-ID, which is not
defined here.

" As pointed out by [NASREQ] the use Filter-Id is not roaming
friendly and it is recommended that instead one should use NAS-
Filter-Rule(TBD) AVP. For this reason, this document introduces
NAS-Filter-Rule(TBD) to RADIUS."

What does "roaming friendly" mean? Filter-ID has been used in roaming
for many years by cooperating parties. Perhaps the issue is requiring
pre-established filters to be set on the NAS? This paragraph appears
to be deprecating an existing RADIUS attribute without a clear
justification.

--
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, 11 Aug 2005 03:04:02 +0000
Content-class: urn:content-classes:message
Subject: Issue: WGLC comments on draft-ietf-radext-ieee802-00.txt
Date: Wed, 10 Aug 2005 23:02:56 -0400
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: WGLC comments on draft-ietf-radext-ieee802-00.txt
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: 8/10/05
Reference: N/A
Document: draft-ietf-radext-ieee802-00.txt
Comment type: T/E
Priority: S
Section: various
Rationale/Explanation of issue:

1) Compliance vs. Functional Coherence
Most of the RADIUS RFCs tend to address a single functional
area, e.g. IPv6 attributes, EAP, tunneling, etc.  This is
good because RFCs tend to become checkmarks on RFPs or
customer requirements.  This documents seems to combine
functionality that is only related to IEEE 802 (VLANs) and
things that are independent of access type.  For example,
filtering and redirection can apply equally usefully to
PPP-based L2 connections.  If I'm a vendor of PPPoA-based
DSL termination NASes, I can't claim compliance to this
potential RFC unless I support all the VLAN oriented=20
attributes because the compliance language in section 1.2
requires an all or nothing approach to compliance.  Can=20
the authors clarify why the NAS-Filter-Rule/QoS-Filter-Rule
attributes are combined with the 802 specific attributes?
I would think these should be addressed via separate documents.

2) Compliance vs. Optional Functionality
I did not understand how the "options" in section 3.5 relate
to the compliance language in section 1.2.  If I do not=20
support the "Cnt" option for counting rule hits, can I still
claim compliance with this document?  Are these optionally
specified or optionally supported?

3) Accounting
The accounting requirements do not seem to be fully treated
by the draft.  Section A.3 has a MUST requirement related to
accounting.  I would think that MUST requirements should be
treated by the text, not in an appendix.  Why does redirection
require a STOP/START pair?  Can't this information be conveyed
via an INTERIM record for the same session?  If the Service-
Type is not changing, I'd think that an INTERIM would suffice.

4) NAS-Filter-Rule proto specification
I could not understand some parts of the specification; I=20
guess Pasi has already commented on this.  In particular, the
proto spec:
  proto  <l2:<ether2[:val]|rmon_str>> type[:val]|ipprot|ip|http>
there are not an equal number of "<" and ">" and the=20
"type[:val]" part is not described.  The "ipprot" does not
provide for a value part.

5) Attribute concatenation
I didn't understand how the language in section 3.6 about
concatenating QoS-Filter-Rule(s) works.  If these are simply
concatenated, how does an implementation distinguish between
multiple 'small' QoS-Filter-Rules and a single larger=20
attribute?  What if I want to send one QoS-Filter-Rule which
spans 253, followed by one which does not?

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/>

Envelope-to: [email-masked]
Delivery-date: Wed, 10 Aug 2005 22:11:02 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: It's all in the timing... 
Cc: [email-masked]
Date: Wed, 10 Aug 2005 18:11:45 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> I have a general concern, or meta-issue, to raise regarding the WGLC of
> draft-ietf-radext-ieee802-00.txt.  The VLAN, Priority and Filtering
> Attributes draft proposes new RADIUS attributes of base data type String
> (Octet String) that are, in fact, multi-field structures a.k.a. complex
> data types.

  Like ARAP-Features, Login-LAT-Group, Framed-Appletalk-Link,
Framed-Appletalk-Zone ...

> My frustration is that I don't see a good solution.  The Design
> Guidelines for RADIUS Attributes must be given time to mature and obtain
> consensus.  It does not seem reasonable to delay the VLAN, Priority and
> Filtering Attributes draft until the design guidelines are ready.  I
> guess the best I can hope for is that work on the design guidelines
> progresses rapidly, and that any substantial disconnects between the
> design guidelines and the VLAN, Priority and Filtering Attributes draft
> can be reconciled before it goes out for IETF Last Call.

  Sure.

  I also have no objection to publishing the VLAN... draft without the
benefit of the final Design Guidelines draft.  There are already
complex data types in RADIUS attributes, so adding a few more
shouldn't be a serious problem.

  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: Wed, 10 Aug 2005 22:08:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Do we have consensus on the Digest Auth draft issues? 
Date: Wed, 10 Aug 2005 18:08:22 -0400
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

>   Are minutes available?

Not yet.  I'm still waiting for the second note taker to send me his raw
minutes, and then I will edit the two sets of notes into one document.

The streaming audio archive is available, if you want to listen.

--
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: Wed, 10 Aug 2005 22:06:12 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Do we have consensus on the Digest Auth draft issues? 
Cc: [email-masked]
Date: Wed, 10 Aug 2005 18:06:37 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> I'm starting a few threads on the RADEXT WG mailing list to follow up on
> issues discussed at the IETF-63 RADEXT session.

  Are minutes available?

  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: Wed, 10 Aug 2005 21:51:27 +0000
Date: Wed, 10 Aug 2005 14:51:16 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: Re: Do we have consensus on the Digest Auth draft issues?

> The substantive issue with the draft-ietf-radext-diget-auth-03.txt seems
> to be how to deal with Diameter interoperability of the two different
> sources of nonce.  The general sense of the room at IETF-63 seemed to be
> that the Digest Auth draft needed to support both modes, and that the
> companion Diameter draft would need to follow suit.  This places the
> Diameter compatibility action item with the Diameter document.
>
> Does the WG at large agree?  Please reply.

Personally, I agree.  But then again, I was the person who first suggested
moving the  Diameter compatibility section to the Diameter document :)

> Assuming that we do agree, then what action item doe we have w.r.t. the
> Diameter document?

I think the implication is that the Diameter document (which has been in
simulaneous WG last call with Digest) needs to own the compatibility
section.

--
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, 10 Aug 2005 21:45:12 +0000
Date: Wed, 10 Aug 2005 14:44:56 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Narayanan Vidya-CVN065 <[email-masked]>
cc: [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: RE: AAA for Handovers

> Can this not be addressed by providing a mechanism in AAA to carry target NAS-IDs
> from the current NAS through which the STA is authenticating? I agree
> that it is unrealistic to expect the AAA server to have complete
> knowledge of the topology. By allowing this information to be carried in
> RADIUS to the server, the topology information can still come from the
> STA - of course, this will require some support from EAP as well to get
> this from the STA to the current NAS, but it still seems like it can be
> done. So, in this model, the AAA server will only derive keys for the
> requested target NAS devices - so, the station will know where the keys
> are sent. Am I missing something?

While technologies such as 802.11 allow a NAS to discover the L2 address
of its neighbors (e.g. IEEE 802.11k Neighbor Report), there is currently
no mechanism to allow discovery of L3 addresses or names.  So today an AP
has no way to learn the L3 address of a neighbor, let alone the neighbor
NAS-Identifier.  So before the AAA client could provide this information
to the server it would need a mechanism to obtain it.  In the case of
802.11, this would probably imply the addition of an L3 address or
NAS-Identifier IE to the Beacon/Probe Response.  I think that IEEE 802.11r
does include support for the latter, but not the former.

> Yes, true. I have wondered why RFC3576 wasn't made a bit more generic,
> with "disconnect" being one type of message. But, why is this style bad?

The issue is that RFC 3576 has not been widely implemented.  There are a
few devices that support it (e.g. Airespace WLAN switches) and a few
servers.  This makes it possible to deploy RFC 3576 in an intra-domain
scenario, but in inter-domain scenarios you'd need to upgrade all the
intervening proxies and there are some substantial security issues to deal.
For example, you'd need to make sure one ISP couldn't disconnect or change
authorization for another ISP's users.  The end result of this is
that building a proxy that supports RFC 3576 in a secure way
is non-trivial.

> > Finally, questions were also raised about whether the
> > mechanism satisfied the criteria in draft-housley since the
> > pre-emptive keying scheme does not authenticate the user
> > through the NAS that it will connect to.
>
> Maybe I'm not remembering draft-housley properly - what threat does this introduce?
> If the AAA server shares an SA with the target NAS, and the MN can be
> properly authenticated, why is it important that the MN be authenticated
> through that NAS?

Pre-emptive keying seeds the key cache at potential points of attachment,
but the EAP peer only authenticates with the target NAS, the AAA server
never confirms that the EAP peer used the key.  The only indication the
AAA server receives is an Accounting-Start from the target NAS, indicating
that the EAP peer has connected.

Because the AAA server can never confirm that the EAP peer was even
considering the target NAS, it has no way to know whether the
Accounting-Start it received is authentic.  This enables a rogue operator
to generate fraudulent accounting records that cannot be easily checked by
the AAA server.

> > As a result, the focus of work on fast handoff has shifted
> > away from pre-emptive keying schemes initiated by the server,
> > toward "key request" schemes initiated by the peer.
> > Advantages of "Key Request" include:
> >
> > a. The station can send an authenticated "Key Request" via
> > the target NAS, sychronizing the key state between the peer,
> > NAS and server and enabling integration between roaming and
> > key management on the peer.
> >
>
> Obviously, this is straightforward - but, are there security reasons why this is better?

The requirement that the EAP peer demonstrate interest in the target NAS
and prove its identity means that there is an authentication attempt to go
along with the Accounting-Start.

> > b. A conventional AAA Request/Response conversation is
> > sufficient; server initiated messages are not required.
>
> I guess I am trying to see if by adding new AAA messages, we can achieve better security along with faster handoffs.

>From what I can tell, the security of the "Key Request" scheme is equal to
or better than pre-emptive keying, without requiring server-initiated
messages or changes to the lower layer neighbor reporting mechanisms.

> > c. "Key Request" relies on local information available to the
> > station rather than a global map of the topology kept on the
> > AAA server, so that it scales better in roaming scenarios.
>
> As I mentioned above, perhaps this model can still be preserved?

The nice thing about "Key Request" is that the peer figures out who the
neighbors are, so the AAA server or NAS doesn't have to.

Note also that in inter-media handoffs, the peer's idea of a "neighbor"
may not correspond to the AP's idea.

> I was not aware that a proactive approach was considered by 802.11r -
> any particular reason why it was rejected? Is it simply to avoid making
> changes to AAA or due to other reasons?

Since both "Key Request" and "pre-emptive keying" approaches require AAA
changes, I don't think that this was the deciding factor.  My
understanding is that "Key Request" is more in tune with the
station-initiated nature of 802.11 roaming than "pre-emptive keying", and
that this coupled with the RFC 3576 deployment issues and potential
security concerns lead to "Key Request" being preferred.

> Yes, and therein lies the problem. At least for requirements we have on handoff
> times for some of the applications we are seeing, it seems rather
> unacceptable to have any need for conversation with the AAA server at
> the time of handoff. This is leading to designs that include intermediate key
> hierarchy branches off the MSK as Madjid pointed out.

One thing to keep in mind is that the total transaction time is not the
only factor determining whether a handoff can be completed in time.
A more important factor is the key cache hit rate and the lead time.  If
knowledge of key state is synchronized and the neighboring NASes can be
determined well ahead of time, then the introduction of one or more
roundtrips to the AAA server may not matter that much because EAP
authentication or "Key Request" may be a rare event.

As an example, in a building where there are two WLAN switches, an EAP
peer with an awareness of the key cache boundaries would
only need to authenticate with each switch once a key cache entry had
expired.  So if the key lifetime is 24 hours, the peer might
authenticate with each switch at the beginning of the day, and then not do
any other EAP authentications until the next day.

In such a situation the extra round-trips to the AAA server of an EAP
pre-authentication or "Key Request" do not affect performance or AAA
server loading that adversely.

> This is true. However, is it because AAA lacks support for this or is
> it the "key request" approach is technically a better one?

AAA servers don't support either pre-emptive keying or key request, so
that's probably not a factor.

> I do realize that the pre-emptive handoff work as written in the IRTF
> draft does not satisfy all requirements. Is it worth looking at whether
> it will be more applicable with some changes, such as a method to send
> multiple NAS-IDs to the AAA server?

I think it would probably be worth bringing the issue up in IEEE 802.11r,
so as to clarify exactly what (if anything) they want from the IETF.
>From my perspective, a very valuable contribution would be to
develop a requirements document that states clearly what the problem is
and what a good solution would look like.  For example, to date there are
a lot of different notions of what "fast" means, or what scenarios need to
be supported and why.  Without consensus on what the problem is or how
we know when it is solved, it is difficult to make much progress.

--
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, 10 Aug 2005 21:04:46 +0000
Content-class: urn:content-classes:message
Subject: Do we have consensus on the Digest Auth draft issues?
Date: Wed, 10 Aug 2005 17:04:14 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I'm starting a few threads on the RADEXT WG mailing list to follow up on
issues discussed at the IETF-63 RADEXT session.

The first is the status of the RADIUS Digest Authentication draft.

The substantive issue with the draft-ietf-radext-diget-auth-03.txt seems
to be how to deal with Diameter interoperability of the two different
sources of nonce.  The general sense of the room at IETF-63 seemed to be
that the Digest Auth draft needed to support both modes, and that the
companion Diameter draft would need to follow suit.  This places the
Diameter compatibility action item with the Diameter document.

Does the WG at large agree?  Please reply.

Assuming that we do agree, then what action item doe we have w.r.t. the
Diameter document?

There is some substantial schedule pressure to get the Digest Auth draft
(-04) to the IESG, as 3GPP2 has a normative dependency on its
publication.

--
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, 10 Aug 2005 20:02:37 +0000
Content-class: urn:content-classes:message
Subject: It's all in the timing...
Date: Wed, 10 Aug 2005 16:01:58 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I have a general concern, or meta-issue, to raise regarding the WGLC of
draft-ietf-radext-ieee802-00.txt.  The VLAN, Priority and Filtering
Attributes draft proposes new RADIUS attributes of base data type String
(Octet String) that are, in fact, multi-field structures a.k.a. complex
data types.  The prose of the draft describes the content and
delimitation of the various fields.  This seems clear enough.

My concern is that RADEXT is prepared to send this draft to the IESG for
approval and publication before another WG work item, Design Guidelines
for RADIUS Attributes, has been completed.  My sincere thanks go to Greg
Weber for stepping up to work on this document.  The new attributes
specified in the VLAN, Priority and Filtering Attributes draft may very
well fall within the design guidelines that are eventually set for
complex data types in Design Guidelines for RADIUS Attributes.  However,
if they are not, then RADEXT will be in the position of publishing a
Standards Track RFC that introduces attributes that do not follow its
own design guidelines.  IMHO, this would be a Very Bad Thing (tm).  It
would be at least inconsistent and at most down right embarrassing.

My frustration is that I don't see a good solution.  The Design
Guidelines for RADIUS Attributes must be given time to mature and obtain
consensus.  It does not seem reasonable to delay the VLAN, Priority and
Filtering Attributes draft until the design guidelines are ready.  I
guess the best I can hope for is that work on the design guidelines
progresses rapidly, and that any substantial disconnects between the
design guidelines and the VLAN, Priority and Filtering Attributes draft
can be reconciled before it goes out for IETF Last Call.

Other suggestions are more than welcome...

The WG's initial schedule, as captured in the charter, was to complete
the design guidelines work early on.  Had that happened as planned, this
sort of dependency problem would not have arisen.  But we are where we
are.

-- Dave

--
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, 10 Aug 2005 18:56:07 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt
Date: Wed, 10 Aug 2005 14:55:13 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

My WGLC comments on the subject draft are included herein.

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

1.  Introduction=20
      =20
      Within the confines of RADIUS authentication, authorization, and=20
      accounting (AAA) environments, there is a general dearth of=20
      standardized RADIUS attributes to limit user access using dynamic=20
      VLANs, filters or redirection.

Could we change "a general dearth of" to "a requirement for"?  It sounds
more positive.

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

      User traffic redirection is supported with or without tunneling.=20
      Tunneling support is provided using the tunnel attributes defined=20
      in [RFC2868].  Redirection of traffic in mid-session may break=20
      applications.

Remove "or without".  I thought we had agreed to remove support for
non-tunneled IP redirection.

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

      IEEE 802.1X-2004 [IEEE8021X] provides "network port=20
      authentication" for IEEE 802 [IEEE802] media, including Ethernet=20
      [IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i].

Remove this sentence as it appears in the second paragraph as well.

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

1.1  Terminology

The following definitions are not used in the draft:

Access Point
Association
Station

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

2.  Overview

The first paragraph is awkwardly worded.  Perhaps the following would be
an improvement.

      In this section we provide an elaboration of the requirements=20
      briefly described in the Introduction.

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

      For example, the user maybe on=20
      a prepaid plan and all the resources have been used up.

Change "maybe" to "may be" and "resources have" to "credit balance has".

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

      For example, the ability to block and=20
      redirect traffic is required for TCP users, cell phone users,
      WiFi users.

Change "TCP users" to "IP users".

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

Change:

      As pointed out by [NASREQ] the use Filter-Id is not roaming=20
      friendly and it is recommended that instead one should use NAS-
      Filter-Rule(TBD) AVP.  For this reason, this document introduces=20
      NAS-Filter-Rule(TBD) to RADIUS.

To:

      As pointed out by [NASREQ] the use Filter-Id is not roaming=20
      friendly and it is recommended that instead one should adapt=20
      the Diameter NAS-Filter-Rule AVP as a RADIUS NAS-Filter-Rule(TBD)
      attribute.

-----------

2.1. Capability Advertisement=20
      =20
      RADIUS does not currently define a method by which a NAS can=20
      advertise its capabilities and in many instances, it would be=20
      desirable for the home network to know what capabilities are=20
      supported by the NAS to ensure proper operational behavior. The=20
      attributes defined in this document are intended to be used to=20
      enforce policy by the NAS. If a NAS does not recognize these=20
      attributes it will most likely ignore them and the desired policy=20
      will not be enforced. A method for the NAS advertising the=20
      capability to support these attributes would help the RADIUS=20
      server understand if the intended policies can be enforced. As a=20
      result, the attributes in this document, in particular NAS-Filter-
      Rule(TBD), can benefit from capability advertisement, if=20
      available. =20

Should this entire section perhaps be part of the Security
Considerations?

-----------

Change:

      Similarly, if a NAS conforming to this specification receives a=20
      CoA message that contains an attribute from this document that it=20
      does not recognize or cannot apply, it MUST NOT terminate the=20
      session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101)=20
      set to "Unsupported Attribute"(401). =20

To:

      Similarly, if a NAS conforming to this specification and also
      conforming to RFC 3576 [RFC3576] receives a CoA message that=20
      contains an attribute from this document that it does not=20
      recognize or cannot apply, it MUST NOT terminate the session and
      MUST generate a CoA-NAK packet with Error-Cause (101) set to
      "Unsupported Attribute"(401). =20

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

3.1.  Egress-VLANID

Integer=20
   =20
         The Integer field is four octets in length.  The format of the=20
         Integer field consists of two parts, the first consuming high-
         order octet and the second consuming the remaining three lower-
         order octets.  The high-order octet field indicates if the=20
         VLANID is allowed for tagged or untagged packets.  The second=20
         part is the 12-bit 802.1Q VLAN VID value that has been padded=20
         out to consume the remaining three lower-order octets.  A=20
         sample encoding follows: =20

This is not an Integer data type.  It is a multi-field Octet String
(complex data type).

-----------

3.4. User-Priority-Table=20
   =20
      Description=20
   =20
         IEEE 802.1D clause 7.5.1 discusses how to regenerate (or re-
         map) user priority on frames received at a port.

Change "IEEE 802.1D" to "IEEE 802.1D [IEEE8021D]".
-----------

3.5.  NAS-Filter-Rule

         Furthermore, the concatenated filter list=20
         must abide to the following rules of precedence and ordering:=20
         =20
            1) A flush rule MUST appear before all other rule types.=20

Change "A flush rule" to "A flush rule, when present,".

            2) Base encapsulation filter rules MUST appear after a=20
               flush rule and before IP tunnel, HTTP redirect, IP=20
               filter, and/or HTTP filter rules.

Change "a flush rule" to "any flush rule".

          dir        "in" is from the terminal, "out" is to the=20
                     terminal, "inout" is from and to the terminal.

The term "terminal" is not defined in the draft.  I suspect it
identifies the network entity which contains the IEEE 802.1X Supplicant
function, but this should perhaps be clarified.

General comment:  I'd much rather that we use ABNF to define the
NAS-Filter-Rule formal syntax, however I'm not prepared to submit that
text just now.  :-)

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

4.1.  Acct-NAS-Filter-Rule

          The first eight octets of this string are used for a 64-bit=20
          value of the rule counter.  The remaining octets are used to=20
          specify which filter rule the counter value is for.  The rule=20
          specification MUST conform to the syntax rules specified for=20
          NAS-Filter-Rule[TODO].

Provide the [TODO].

--
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, 10 Aug 2005 18:42:25 +0000
From: Narayanan Vidya-CVN065 <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: RE: AAA for Handovers
Date: Wed, 10 Aug 2005 13:42:02 -0500

Hi Bernard,
Thanks for the detailed explanation. This was very helpful to me. Please see some questions/comments inline. 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Wednesday, August 10, 2005 11:38 AM
> To: Narayanan Vidya-CVN065
> Cc: [email-masked]; [email-masked]; Korus Mike-CMK013
> Subject: Re: AAA for Handovers
> 
> 
> > A while ago, some work was done in the IRTF on RADIUS for
> handovers in
> > the aaaarch-handoff draft, but it seems to have rather died now.
> 
> The extension specified in the draft was implemented, and
> experimental measurements were made that showed that the 
> technique was effective in intra-domain use.
> 
> However, in other scenarios there are potential efficiency
> issues since in 802.11 handoff is station-initiated and yet 
> pre-emptive keying does not allow the station to know where 
> keys have been sent.  As a result, the key state between the 
> peer, authenticator and server is not kept in sync and the 
> station may not be able to make effective roaming decisions.  
> For example, in roaming scenarios the server would be 
> unlikely to have a complete knowledge of the topology and 
> thus would be unable to determine where to send keying material.
> 

Can this not be addressed by providing a mechanism in AAA to carry target NAS-IDs from the current NAS through which the STA is authenticating? I agree that it is unrealistic to expect the AAA server to have complete knowledge of the topology. By allowing this information to be carried in RADIUS to the server, the topology information can still come from the STA - of course, this will require some support from EAP as well to get this from the STA to the current NAS, but it still seems like it can be done. So, in this model, the AAA server will only derive keys for the requested target NAS devices - so, the station will know where the keys are sent. Am I missing something? 

> This causes pre-emptive keying to be ineffective in 
> inter-domain use.  There are also concerns about intra-domain 
> deployments because pre-emptive keying requires RFC 
> 3576-style server-initiated messages.
> 

Yes, true. I have wondered why RFC3576 wasn't made a bit more generic, with "disconnect" being one type of message. But, why is this style bad? 

> Finally, questions were also raised about whether the 
> mechanism satisfied the criteria in draft-housley since the 
> pre-emptive keying scheme does not authenticate the user 
> through the NAS that it will connect to.
> 

Maybe I'm not remembering draft-housley properly - what threat does this introduce? If the AAA server shares an SA with the target NAS, and the MN can be properly authenticated, why is it important that the MN be authenticated through that NAS? 

> As a result, the focus of work on fast handoff has shifted 
> away from pre-emptive keying schemes initiated by the server, 
> toward "key request" schemes initiated by the peer.  
> Advantages of "Key Request" include:
> 
> a. The station can send an authenticated "Key Request" via 
> the target NAS, sychronizing the key state between the peer, 
> NAS and server and enabling integration between roaming and 
> key management on the peer.
> 

Obviously, this is straightforward - but, are there security reasons why this is better? 

> b. A conventional AAA Request/Response conversation is 
> sufficient; server initiated messages are not required.
> 

I guess I am trying to see if by adding new AAA messages, we can achieve better security along with faster handoffs. 

> c. "Key Request" relies on local information available to the 
> station rather than a global map of the topology kept on the 
> AAA server, so that it scales better in roaming scenarios.
> 

As I mentioned above, perhaps this model can still be preserved? 

> > Thinking about this a little further, it seems like such a 
> design is 
> >becoming popular due to the lack of a method in AAA to 
> pre-authenticate 
> >to multiple authenticators (NAS-es) and proactively 
> distribute keys to 
> >the NAS-es.
> 
> As I understand it, IEEE 802.11r supports both conventional 
> pre-authentication as well as a "Key Request" mode.  However, 
> it does not support pre-emptive keying.
> 
> Note that the terms "pre-authentication" and "proactive" are 
> mutually exclusive. Pre-authentication schemes (such as Key 
> Request) are station initiated; "proactive" schemes are 
> server-initiated.  Typically a given approach will do one or 
> the other, but not both.  My understanding is that IEEE 
> 802.11r has rejected the "proactive" approach.

Yes, since pre-authentication and proactive aren't the same thing, I included both terms in my statement above :) I was not aware that a proactive approach was considered by 802.11r - any particular reason why it was rejected? Is it simply to avoid making changes to AAA or due to other reasons? 

> 
> Note that "Key Request" schemes do not eliminate the need for 
> a conversation between the NAS and AAA server, they merely 
> shorten it.  For example, a "fast resume" typically requires 
> 2.5 roundtrips, while a Key Request might be completed in a 
> single round-trip.
> 

Yes, and therein lies the problem. At least for requirements we have on handoff times for some of the applications we are seeing, it seems rather unacceptable to have any need for conversation with the AAA server at the time of handoff. This is leading to designs that include intermediate key hierarchy branches off the MSK as Madjid pointed out. 

> >It seems to me that if the IETF worked on this and matured 
> it enough, 
> >people would be willing to use it to provide more secure faster 
> >handoffs.
> 
> Dorothy Stanley the IEEE 802.11 liaison has mentioned that 
> IEEE 802.11r may make a liaison request for work on fast 
> handoff.  However, based on the discussion that has occurred 
> so far, it seems unlikely that such a request will relate to 
> pre-emptive keying.  "Key Request" approaches have a lot more 
> support at this point.
> 

This is true. However, is it because AAA lacks support for this or is it the "key request" approach is technically a better one? 

> >Especially since some work was done in this space earlier 
> on, it seems 
> >like it might be worth looking into. The IRTF draft was ahead of its 
> >time when it was written - but, it seems like the timing for such a 
> >task would be perfect now.
> 
> As mentioned earlier, the IRTF work on pre-emptive handoff is 
> not moving forward because it does not satisfy the problem 
> requirements as they are currently understood.  

I do realize that the pre-emptive handoff work as written in the IRTF draft does not satisfy all requirements. Is it worth looking at whether it will be more applicable with some changes, such as a method to send multiple NAS-IDs to the AAA server? 

Thanks,
Vidya

> Current work 
> is focused on "Key Request" approaches. However, some 
> fundamental questions remain about how "Key Request" would work:
> 
> a. How are the keys to be named?  Can the key naming scheme 
> used in the EAP key management framework be used?
> 
> b. Can different media simultaneously use the key request 
> scheme?  If so, does the AAA server need to maintain a 
> different cache for each media or can a single cache be supported?
> 
> c. How is the key request authenticated?
> 
> d. How does the peer direct the key request to the correct 
> AAA server? How does this work if the EAP method in question 
> does not provide a Server-ID so that the peer is unaware of 
> where its keys are being cached?
> 

--
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, 10 Aug 2005 18:34:58 +0000
Content-class: urn:content-classes:message
Subject: Issue: HTTP NAS-Filter-Rules always assume port 80
Date: Wed, 10 Aug 2005 11:34:42 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: "Congdon, Paul T (ProCurve)" <[email-masked]>

HTTP NAS-Filter-Rules always assume port 80
Submitter name: Paul Congdon=20
Submitter email address: [email-masked]
Date first submitted: 08-10-2005
Reference: N/A
Document: draft-ietf-radext-ieee802-00.txt=20
Comment type: T
Priority: S
Section: 3.5

Rationale/Explanation of issue:

There appears to be no way to augment the HTTP rules with a port number
if we want to attempt to match HTTP traffic on something other than port
80.  This is likely useful in enterprise environments where proxies may
be used and browsers are configured to use something other than port 80.
Seems like we should add the ports options seen in the IP filter to the
HTTP rule.

Requested change:

Add the {port/port-port}[,ports[,...]] option that appears in the IP
rule to the HTTP rule as well.

--
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, 10 Aug 2005 18:27:16 +0000
Content-class: urn:content-classes:message
Subject: Issue: redir_cnt not included as method of redirection removal
Date: Wed, 10 Aug 2005 11:26:21 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: "Congdon, Paul T (ProCurve)" <[email-masked]>

redir_cnt not included as method of redirection removal
Submitter name: Paul Congdon
Submitter email address: [email-masked]
Date first submitted: 08-10-2005
Reference: N/A
Document: draft-ietf-radext-ieee802-00.txt
Comment type: T
Priority: S
Section: A.2.3, Pg 27, last paragraph
Rationale/Explanation of issue:
This section talks about how the redirection process can be disabled.
Since we added the redir_cnt parameter to the rule we should include it
as a mechanism for disabling redirection.  Also it isn't clear if a new
session is created when the redir_cnt value becomes zero.  If a new
session is created, then the accounting records should also be sent.  I
will propose that we insert a paragraph before the last paragraph in
this clause so the accounting scheme will remain intact.
Requested change:
Insert a paragraph before the last paragraph that describes the
redir_cnt scheme.  Suggest something like the following words: "When
HTTP redirection is established via a NAS-Filter-Rule (TBD) it also
possible to have HTTP redirection automatically removed by including a
redir_cnt parameter along with the rule.  The rule will be removed from
the active rule set when the rule matches redir_cnt number of times.
When the rule is removed, HTTP redirection will also be removed."

--
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, 10 Aug 2005 16:38:19 +0000
Date: Wed, 10 Aug 2005 09:38:03 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Narayanan Vidya-CVN065 <[email-masked]>
cc: [email-masked], [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: Re: AAA for Handovers

> A while ago, some work was done in the IRTF on RADIUS for handovers in the
> aaaarch-handoff draft, but it seems to have rather died now.

The extension specified in the draft was implemented, and experimental
measurements were made that showed that the technique was effective in
intra-domain use.

However, in other scenarios there are potential efficiency
issues since in 802.11 handoff is station-initiated and yet
pre-emptive keying does not allow the station to know where keys
have been sent.  As a result, the key state between the
peer, authenticator and server is not kept in sync and the station may not
be able to make effective roaming decisions.  For example, in roaming
scenarios the server would be unlikely to have a complete knowledge of
the topology and thus would be unable to determine where to send keying material.

This causes pre-emptive keying to be ineffective in
inter-domain use.  There are also concerns about intra-domain
deployments because pre-emptive keying requires RFC 3576-style
server-initiated messages.

Finally, questions were also raised about whether the mechanism satisfied
the criteria in draft-housley since the pre-emptive keying scheme does not
authenticate the user through the NAS that it will connect to.

As a result, the focus of work on fast handoff has shifted away from
pre-emptive keying schemes initiated by the server, toward "key request"
schemes initiated by the peer.  Advantages of "Key Request" include:

a. The station can send an authenticated "Key Request" via the target
NAS, sychronizing the key state between the peer, NAS and
server and enabling integration between roaming and key management on the
peer.

b. A conventional AAA Request/Response conversation is sufficient; server
initiated messages are not required.

c. "Key Request" relies on local information available to the station
rather than a global map of the topology kept on the AAA server, so that
it scales better in roaming scenarios.

> Thinking about this a little further, it seems like such a design is becoming popular due to the lack
>of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively
>distribute keys to the NAS-es.

As I understand it, IEEE 802.11r supports both conventional
pre-authentication as well as a "Key Request" mode.  However, it does not
support pre-emptive keying.

Note that the terms "pre-authentication" and "proactive" are mutually
exclusive. Pre-authentication schemes (such as Key Request) are station
initiated; "proactive" schemes are server-initiated.  Typically a given
approach will do one or the other, but not both.  My understanding is that
IEEE 802.11r has rejected the "proactive" approach.

Note that "Key Request" schemes do not eliminate the need for a
conversation between the NAS and AAA server, they merely shorten it.  For
example, a "fast resume" typically requires 2.5 roundtrips, while a Key
Request might be completed in a single round-trip.

>It seems to me that if the IETF worked on this and matured it enough,
>people would be willing to use it to provide more secure faster handoffs.

Dorothy Stanley the IEEE 802.11 liaison has mentioned that IEEE 802.11r
may make a liaison request for work on fast handoff.  However, based on
the discussion that has occurred so far, it seems unlikely that such a
request will relate to pre-emptive keying.  "Key Request" approaches
have a lot more support at this point.

>Especially since some work was done in this space earlier on, it seems
>like it might be worth looking into. The IRTF draft was ahead of its time
>when it was written - but, it seems like the timing for such a task would
>be perfect now.

As mentioned earlier, the IRTF work on pre-emptive handoff is not moving
forward because it does not satisfy the problem requirements as they are
currently understood.  Current work is focused on "Key Request"
approaches. However, some fundamental questions remain about how
"Key Request" would work:

a. How are the keys to be named?  Can the key naming scheme used in the
EAP key management framework be used?

b. Can different media simultaneously use the key request scheme?  If so,
does the AAA server need to maintain a different cache for each media or
can a single cache be supported?

c. How is the key request authenticated?

d. How does the peer direct the key request to the correct AAA server?
How does this work if the EAP method in question does not provide a
Server-ID so that the peer is unaware of where its keys are being cached?

--
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, 10 Aug 2005 16:08:58 +0000
From: Narayanan Vidya-CVN065 <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, Korus Mike-CMK013 <[email-masked]>
Subject: RE: AAA for Handovers
Date: Wed, 10 Aug 2005 11:08:33 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C59DC5.C0F957DC
Content-Type: text/plain

Hi Madjid,
Thanks for a prompt response on the topic. While I agree with you that there are things that need to be synergized between AAA and EAP for complete support, I think that it would be useful for AAA to provide a framework to do this first. I have read the draft you posted on the EAP ML. It seems to me that if AAA can mature the handover operation a little further and provide a framework, it would help in solving the issue of EAP-AAA-handovers. So, in general, I don't want to get into the discussion of EAP particulars yet - I'd like to first understand the motivations and issues from the AAA side first. 
 
Since there are people in these WGs that have looked into this before, I am really interested in hearing their thoughts on reviving this work. In general, Jari seemed supportive of the idea when I talked to him. If there are others who also feel the same, perhaps it would make sense to take a look at doing this in the IETF. 
 
Thanks,
Vidya

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 
Sent: Wednesday, August 10, 2005 10:34 AM
To: Narayanan Vidya-CVN065; [email-masked]
Cc: [email-masked]; Korus Mike-CMK013
Subject: RE: AAA for Handovers

Hi Vidya,
 
This is a topic that has been discussed over many mailing lists and not sure if a long thread on this topic is something people like to relive. However, unfortunately, I for one have not found a recipe from IETF yet (or at least a simply digestible for an amateur EAPer like myself). So non-IETF bodies are starting to do their own methods with varying degree of regard for Housely criteria, because the limited understanding of the specification and frankly in my believe limited IETF specifications.
 
Issues that I see:
 
1) As you mentioned, the common understanding of RADIUS being incapable of doing server-initiated messaging. This seems to not be the case anymore with CoA RFC, but I am not sure if CoA messaging can be used to push keys to multiple NASes.
 
2) A related issues is EAP's limited capability in key transport (AAA key or MSKs are only sent to the authenticator and no other entities). Also key transport and encryption standards are generally not well understood.
 
3) Micro mobility in many systems forces people to have base stations or access points to work at a level below the NAS for a variety of reasons, from no need for RADIUS client in the BS, to not sharing the EAP master keys at a BS that can be easily hacked. This means people are inventing key hierarchies that feed off the EAP master keys and generated BS-specific keys to prevent "domino effects". so this can't even be solved by AAA server proactively pushing keys. and Going back to AAA server for each key generation is not desirable.
 
4) Lack of standardized authorization attributes and messaging to allow the EAP keys to bootstrap other mechanisms such as Mobile IP and so on. People invent bootstrapping mechanisms without regard to the initial EAP key lifetimes or authorizations or without the ability to cross check these life times. The AAA community needs to simply take control by providing authorization directives to the NAS on what it can and cannot do with the keys.
 
5) Channel binding is a very hard topic to understand and to provide a cure for.
 
I tried to start a discussion on this topic in the EAP group by sending a draft talking about EAP and handover support,
http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt <http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt> 
 
but seeing your email and doing the short list above, I think both EAP and RADIUS need to be worked together. 

One of the major issues is that there are people on the list that do not think there are any problems with the existing specification, so I would say the more constructive thing to do (instead of engaging in intractable debates on the list) is to work on a draft that lists the issues (I tried both above and in my draft) and then solicit answers to see if the issues have convincing answers, if not try to solve it either in EAP or in RADext or find the right IETF venue to solve the problems, unless IETF does not want to deal with this and will rather have IEEE work on it.
 
Madjid

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Narayanan Vidya-CVN065
Sent: Wednesday, August 10, 2005 9:57 AM
To: [email-masked]
Cc: [email-masked]; Korus Mike-CMK013
Subject: AAA for Handovers

All,
I had a brief chat with Jari Arkko on this topic in Paris and he suggested I bring it up on the RADEXT mailing list. 
 
A while ago, some work was done in the IRTF on RADIUS for handovers in the aaaarch-handoff draft, but it seems to have rather died now. Currently, there seems to be no efforts to advance such work in the IETF or IRTF. I was wondering if reviving some work along the same lines might be an option people would support or desire. 
 
Some thoughts on why this work would be useful: 
 
It is quite evident that performing an entire EAP method exchange upon handoff introduces significant increase in handoff times. It seems that people are getting around going to the AAA server every time by defining evolving keys and introducing local KDCs. An example is the path 802.11r is taking. 802.11r has introduced an evolving key hierarchy that allows the STA to handoff without having to perform a full EAP exchange. It is generally accepted (at least seems to be) that this is inherently less secure than performing regular EAP - however, this is viewed as important to be able to have acceptable handoff times. Being of the IETF mentality, to me, these mechanisms do not seem to satisfy all the Housley criteria as they should. However, without changes in AAA, I don't have a better answer to reducing handoff times. 
 
Thinking about this a little further, it seems like such a design is becoming popular due to the lack of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively distribute keys to the NAS-es. If there was a way to do this, it would be possible to derive multiple keys at the AAA server for a mobile node corresponding to target NAS devices and proactively push the keys to those devices without the need for a complete authentication and key derivation upon handoff. It would allow significant reduction in the signaling required to establish keys at NAS-es. 
 
It seems to me that if the IETF worked on this and matured it enough, people would be willing to use it to provide more secure faster handoffs. Especially since some work was done in this space earlier on, it seems like it might be worth looking into. The IRTF draft was ahead of its time when it was written - but, it seems like the timing for such a task would be perfect now. 
 
Any thoughts? 
 
Thanks,
Vidya

------_=_NextPart_001_01C59DC5.C0F957DC
Content-Type: text/html
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C59DC5.C0F957DC--

--
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, 10 Aug 2005 15:33:52 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: Narayanan Vidya-CVN065 <[email-masked]>, [email-masked]
Cc: [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: RE: AAA for Handovers
Date: Wed, 10 Aug 2005 10:33:39 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C59DC0.E1B45090
Content-Type: text/plain

Hi Vidya,
 
This is a topic that has been discussed over many mailing lists and not sure if a long thread on this topic is something people like to relive. However, unfortunately, I for one have not found a recipe from IETF yet (or at least a simply digestible for an amateur EAPer like myself). So non-IETF bodies are starting to do their own methods with varying degree of regard for Housely criteria, because the limited understanding of the specification and frankly in my believe limited IETF specifications.
 
Issues that I see:
 
1) As you mentioned, the common understanding of RADIUS being incapable of doing server-initiated messaging. This seems to not be the case anymore with CoA RFC, but I am not sure if CoA messaging can be used to push keys to multiple NASes.
 
2) A related issues is EAP's limited capability in key transport (AAA key or MSKs are only sent to the authenticator and no other entities). Also key transport and encryption standards are generally not well understood.
 
3) Micro mobility in many systems forces people to have base stations or access points to work at a level below the NAS for a variety of reasons, from no need for RADIUS client in the BS, to not sharing the EAP master keys at a BS that can be easily hacked. This means people are inventing key hierarchies that feed off the EAP master keys and generated BS-specific keys to prevent "domino effects". so this can't even be solved by AAA server proactively pushing keys. and Going back to AAA server for each key generation is not desirable.
 
4) Lack of standardized authorization attributes and messaging to allow the EAP keys to bootstrap other mechanisms such as Mobile IP and so on. People invent bootstrapping mechanisms without regard to the initial EAP key lifetimes or authorizations or without the ability to cross check these life times. The AAA community needs to simply take control by providing authorization directives to the NAS on what it can and cannot do with the keys.
 
5) Channel binding is a very hard topic to understand and to provide a cure for.
 
I tried to start a discussion on this topic in the EAP group by sending a draft talking about EAP and handover support,
http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt <http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt> 
 
but seeing your email and doing the short list above, I think both EAP and RADIUS need to be worked together. 

One of the major issues is that there are people on the list that do not think there are any problems with the existing specification, so I would say the more constructive thing to do (instead of engaging in intractable debates on the list) is to work on a draft that lists the issues (I tried both above and in my draft) and then solicit answers to see if the issues have convincing answers, if not try to solve it either in EAP or in RADext or find the right IETF venue to solve the problems, unless IETF does not want to deal with this and will rather have IEEE work on it.
 
Madjid

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Narayanan Vidya-CVN065
Sent: Wednesday, August 10, 2005 9:57 AM
To: [email-masked]
Cc: [email-masked]; Korus Mike-CMK013
Subject: AAA for Handovers

All,
I had a brief chat with Jari Arkko on this topic in Paris and he suggested I bring it up on the RADEXT mailing list. 
 
A while ago, some work was done in the IRTF on RADIUS for handovers in the aaaarch-handoff draft, but it seems to have rather died now. Currently, there seems to be no efforts to advance such work in the IETF or IRTF. I was wondering if reviving some work along the same lines might be an option people would support or desire. 
 
Some thoughts on why this work would be useful: 
 
It is quite evident that performing an entire EAP method exchange upon handoff introduces significant increase in handoff times. It seems that people are getting around going to the AAA server every time by defining evolving keys and introducing local KDCs. An example is the path 802.11r is taking. 802.11r has introduced an evolving key hierarchy that allows the STA to handoff without having to perform a full EAP exchange. It is generally accepted (at least seems to be) that this is inherently less secure than performing regular EAP - however, this is viewed as important to be able to have acceptable handoff times. Being of the IETF mentality, to me, these mechanisms do not seem to satisfy all the Housley criteria as they should. However, without changes in AAA, I don't have a better answer to reducing handoff times. 
 
Thinking about this a little further, it seems like such a design is becoming popular due to the lack of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively distribute keys to the NAS-es. If there was a way to do this, it would be possible to derive multiple keys at the AAA server for a mobile node corresponding to target NAS devices and proactively push the keys to those devices without the need for a complete authentication and key derivation upon handoff. It would allow significant reduction in the signaling required to establish keys at NAS-es. 
 
It seems to me that if the IETF worked on this and matured it enough, people would be willing to use it to provide more secure faster handoffs. Especially since some work was done in this space earlier on, it seems like it might be worth looking into. The IRTF draft was ahead of its time when it was written - but, it seems like the timing for such a task would be perfect now. 
 
Any thoughts? 
 
Thanks,
Vidya

------_=_NextPart_001_01C59DC0.E1B45090
Content-Type: text/html
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C59DC0.E1B45090--

--
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, 10 Aug 2005 14:57:34 +0000
From: Narayanan Vidya-CVN065 <[email-masked]>
To: [email-masked]
Cc: [email-masked], Korus Mike-CMK013 <[email-masked]>
Subject: AAA for Handovers
Date: Wed, 10 Aug 2005 09:56:58 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C59DBB.BFD17B78
Content-Type: text/plain

All,
I had a brief chat with Jari Arkko on this topic in Paris and he suggested I bring it up on the RADEXT mailing list. 
 
A while ago, some work was done in the IRTF on RADIUS for handovers in the aaaarch-handoff draft, but it seems to have rather died now. Currently, there seems to be no efforts to advance such work in the IETF or IRTF. I was wondering if reviving some work along the same lines might be an option people would support or desire. 
 
Some thoughts on why this work would be useful: 
 
It is quite evident that performing an entire EAP method exchange upon handoff introduces significant increase in handoff times. It seems that people are getting around going to the AAA server every time by defining evolving keys and introducing local KDCs. An example is the path 802.11r is taking. 802.11r has introduced an evolving key hierarchy that allows the STA to handoff without having to perform a full EAP exchange. It is generally accepted (at least seems to be) that this is inherently less secure than performing regular EAP - however, this is viewed as important to be able to have acceptable handoff times. Being of the IETF mentality, to me, these mechanisms do not seem to satisfy all the Housley criteria as they should. However, without changes in AAA, I don't have a better answer to reducing handoff times. 
 
Thinking about this a little further, it seems like such a design is becoming popular due to the lack of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively distribute keys to the NAS-es. If there was a way to do this, it would be possible to derive multiple keys at the AAA server for a mobile node corresponding to target NAS devices and proactively push the keys to those devices without the need for a complete authentication and key derivation upon handoff. It would allow significant reduction in the signaling required to establish keys at NAS-es. 
 
It seems to me that if the IETF worked on this and matured it enough, people would be willing to use it to provide more secure faster handoffs. Especially since some work was done in this space earlier on, it seems like it might be worth looking into. The IRTF draft was ahead of its time when it was written - but, it seems like the timing for such a task would be perfect now. 
 
Any thoughts? 
 
Thanks,
Vidya

------_=_NextPart_001_01C59DBB.BFD17B78
Content-Type: text/html
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C59DBB.BFD17B78--

--
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, 10 Aug 2005 13:39:13 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt
Date: Wed, 10 Aug 2005 16:37:05 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Here are my comments:

1. The second paragraph in the introduction reads:

For example, in IEEE 802.1X [IEEE8021X] environments, which=20
      provides "network port authentication" for IEEE 802 [IEEE802]=20
      media, including Ethernet [IEEE8023], Token Ring and 802.11=20
      [IEEE80211i] wireless LANS, there exists a strong desire to=20
      control authorization beyond just the untagged VLAN parameter=20
      based on tunnel attributes in [RFC2868].=20

- The syntax of this phrase sounds broken. Replacing 'provides' by
'provide' would help
- No reference for Token Ring
- 802.11i defines the security of the wireless LAN, and not the wireless
LAN

2. It would be good to add abbreviations to section 1.1 - for example
NAS, etc.=20

3. The term WiFi user in Section 2 is not explained

4.  The diagrams in 3.1, 4.1, 4.2  have missing delimiters

5. Section 3.4:

There are eight=20
         possible user priorities, according to the IEEE 802 standard.=20

Should be IEEE 802.1Q standard

6. Section 7 - I believe that some text should be added about the threat
resulting from intentional or accidental mis-configuration of filtering
capabilities in IEEE 802.1 bridges which can result in blocking or
degradation of service of traffic related to specific ports, users, or
applications.=20

Regards,

Dan
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, July 11, 2005 6:35 AM
> To: [email-masked]
> Subject: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt
>=20
> This is an announcement of RADEXT WG last call on "VLAN,=20
> Priority, and Filtering Attributes" prior to sending this=20
> document to the IESG for consideration as a Proposed=20
> Standard. The document will be available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt
>=20
> Until it arrives on the archive, it will be available at:
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-ieee802-00.txt
>=20
> RADEXT WG last call will last until August 10, 2005. Please=20
> send comments to the RADEXT WG mailing list in the format=20
> described on the RADEXT Issues
> list:
> http://www.drizzle.com/~aboba/RADEXT/
>=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, 04 Aug 2005 04:57:57 +0000
Date: Thu, 04 Aug 2005 00:57:04 -0400
To: <[email-masked]>
From: David Mitton <[email-masked]>
Subject: RE: Issue: Vendor Specifc Attribute Values 

On 7/26/2005 03:57 PM, Nelson, David wrote:

>Alan DeKok writes...
>
> >   2882 uses Vendor-Specific Enumerations (VSE's).  We should use that
> > here.
>
>RFC 2882 is certainly a fact-based document.  It reports existing
>deployment behaviors.  Its abstract reads:
>
>Abstract
>
>    This document describes current practices implemented in NAS products
>    that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The
>    purpose of this effort is to give examples that show the need for
>    addressing and standardizing these types of ad-hoc functions.  Since
>    many of these features require a matching server support component,
>    the ability to deploy and manage interoperable NAS and AAA server
>    products is severely hindered.
>
>    These practices are documented here to show functions that are
>    obviously desired in developing future AAA protocols for NAS
>    deployment.
>
>IMHO, we should be careful about inferring any desired or implied level
>of standardization of any of the practices reported in 2882.  If there
>is no good reason to the contrary, then following existing convention
>may be a good thing.  OTOH, the fact that one or more vendors chose to
>implement a needed (or desired) function in a particular fashion should
>not set a binding precedent on the RADEXT WG.  These extensions, in all
>likelihood, received no IETF review, or even third party review, prior
>to their implementation and deployment.  We should look at these "ad
>hoc" extensions with a critical eye.

Indeed,
         one of my working titles for RFC 2882, was "RADIUS Worse Practices"

Dave.  

--
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, 03 Aug 2005 18:22:13 +0000
Date: Wed, 03 Aug 2005 11:17:22 -0700
To: "Alan DeKok" <[email-masked]>
From: Ignacio Goyret <[email-masked]>
Subject: Re: Issue: Vendor Specifc Attribute Values 
Cc: [email-masked]

At 00:46 8/3/2005 -0400, Alan DeKok wrote:
>Ignacio Goyret <[email-masked]> wrote:
>> The method described in RFC2882 was used by one vendor and it works so long
>> as the bottom 16-bits of the vendor-id is not repeated, something that was
>> true then but it hasn't been for a long time.
>
>  I'm not sure why you think 2^16 was passed a long time ago.

You are correct. Sorry for the confusion. Please, ignore that part of my comments.

>> My impression is that if assignment of new values was easier, the need for
>> VSEs would tend to disappear. As it stands, it is a process that takes a
>> good year at least.
>
>  There will *always* be a need for people to define site-local VSA's
>and VSE's.  Without a standard method of doing so, they will choose
>methods that destroy protocol interoperability.

Yes, of course, there must be a well defined method to the madness.
I'm not arguing against VSAs or VSEs.

My point was that the main reason d'etre for VSAs and VSEs is the very long
process to get new numbers. If that process could be sped up somehow (without
detrimental of the protocol, of course), I'm positive it would reduce the
current massive need for VSAs and VSEs.

--
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: Wed, 03 Aug 2005 04:46:29 +0000
From: "Alan DeKok" <[email-masked]>
To: Ignacio Goyret <[email-masked]>
Subject: Re: Issue: Vendor Specifc Attribute Values 
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Date: Wed, 03 Aug 2005 00:46:34 -0400
Message-Id: <[email-masked]>

Ignacio Goyret <[email-masked]> wrote:
> The method described in RFC2882 was used by one vendor and it works so long
> as the bottom 16-bits of the vendor-id is not repeated, something that was
> true then but it hasn't been for a long time.

http://www.iana.org/assignments/enterprise-numbers

  Goes up to 23642 as of today.  At the current rate, it will be a
number of years before the assignments hit 2^16.

  I'm not sure why you think 2^16 was passed a long time ago.

> My impression is that if assignment of new values was easier, the need for
> VSEs would tend to disappear. As it stands, it is a process that takes a
> good year at least.

  There will *always* be a need for people to define site-local VSA's
and VSE's.  Without a standard method of doing so, they will choose
methods that destroy protocol interoperability.

  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: Wed, 03 Aug 2005 02:55:13 +0000
Date: Tue, 02 Aug 2005 19:51:20 -0700
To: "Nelson, David" <[email-masked]>
From: Ignacio Goyret <[email-masked]>
Subject: RE: Issue: Vendor Specifc Attribute Values 
Cc: "Alan DeKok" <[email-masked]>, <[email-masked]>

>>   2882 uses Vendor-Specific Enumerations (VSE's).  We should use that
>> here.
>
>RFC 2882 is certainly a fact-based document.  It reports existing
>deployment behaviors.  Its abstract reads:
...
>
>IMHO, we should be careful about inferring any desired or implied level
>of standardization of any of the practices reported in 2882.  If there
>is no good reason to the contrary, then following existing convention
>may be a good thing.

>OTOH, the fact that one or more vendors chose to
>implement a needed (or desired) function in a particular fashion should
>not set a binding precedent on the RADEXT WG.  These extensions, in all
>likelihood, received no IETF review, or even third party review, prior
>to their implementation and deployment.  We should look at these "ad
>hoc" extensions with a critical eye.

May be we should note here that some of this vendor behavior was caused
by the attitude in the original RADIUS WG where any idea not implemented
by certain vendor (now defunct) were systematically rejected.

This (probably only apparent) inflexibility of the WG forced many vendors
to find their own way to solve attribute and value assignments, in many
cases, without much thought for multi-vendor interoperability.

That was then, this is now.

The method described in RFC2882 was used by one vendor and it works so long
as the bottom 16-bits of the vendor-id is not repeated, something that was
true then but it hasn't been for a long time. Ignoring this very serious
limitation means that multi-vendor interoperability cannot be guaranteed
nor implied. Please, let's not make that the rule.

My impression is that if assignment of new values was easier, the need for
VSEs would tend to disappear. As it stands, it is a process that takes a
good year at least.

Sorry, I somehow got derailed out of topic.

--
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, 03 Aug 2005 01:49:02 +0000
Date: Tue, 2 Aug 2005 18:48:21 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Presentations online

I've updated the presentations for today's meeting.  If your presentation
isn't online yet, or if we don't have the right version, let me know:

http://www.drizzle.com/~aboba/IETF63/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: Tue, 02 Aug 2005 13:23:37 +0000
Date: Tue, 2 Aug 2005 06:22:48 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF 63 Presentations Online

RADEXT WG presentations for IETF 63 are online at:
http://www.drizzle.com/~aboba/IETF63/radext/

If you haven't sent your presentation to Dave or myself, please do so
ASAP.

--
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/>