Subject: AW: Issue 79; digest-auth realm validation
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 31 Mar 2005 10:31:32 +0200

> 
> [Joe] I agree that the case that is interesting is when the RADIUS
> server supports RADIUS clients that support different realms. I don't
> see how it is possible that a RADIUS client will never see HTTP-style
> requests from other realms, but perhaps I am missing something.
Note that Digest-Realm has nothing to do with the realm that is used
by RADIUS proxies to route a RADIUS message to the right server.
Digest-Realm is part of the challenge that is sent to the HTTP-style
client. This leads to a different attack scenario:
- the attacker sends a challenge to the HTTP-style client, using the
realm value he is interested in.
- The HTTP-style client constructs a digest response for this realm.
- The attacker obtains Digest-HA1 for the realm and impersonates the
responsible server for this realm.

>Wolfgang wrote:
>> "A RADIUS server MUST check if the RADIUS client is 
>> authorized to use the value it has put into the Digest-Realm 
>> attribute. If the RADIUS client is not authorized to use this 
>> realm value, the RADIUS server sends an Access-Reject. The 
>> RADIUS server considers this client as compromised. It 
>> notifies the operator and rejects all future requests from 
>> this client, until some management action tells it to do so again."
> [Joe] I believe it helps to mitigate the exposures above.  I am most
> concerned about the exposure of Digest-HA1 when the Digest-algorithm
> MD5 is used.  There may be other issues, but that depends on what clients
> expect from a realm. 
Note that MD5 is only allowed if you run IPsec between RADIUS client and server,
to avoid replay attacks. This does not help in your scenario, of course.

Would my text proposal resolve your issue? If not, can you propose
some text?

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, 30 Mar 2005 17:03:26 +0000
content-class: urn:content-classes:message
Subject: RE: Issue 79; digest-auth realm validation
Date: Wed, 30 Mar 2005 09:06:36 -0800
From: "Salowey, Joe" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>
Cc: "Beck01, Wolfgang" <[email-masked]>

=20

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]=20
> Sent: Wednesday, March 30, 2005 6:57 AM
> To: Salowey, Joe; Avi Lior; [email-masked]
> Cc: Beck01, Wolfgang
> Subject: RE: Issue 79; digest-auth realm validation
>=20
> Hi Joe,
>=20
> I just have a comment on this bit:
>=20
> > [Joe] If there is no proxy then the RADIUS server must maintain the=20
> > information associating a RADIUS Client to a set of realms.
> > In the case
> > of the proxies it would be the job of one of the proxies in=20
> the chain=20
> > to validate the authorization and reject the request if it is not=20
> > authorized.
>=20
> Well, this is not part of what RADIUS does.  Its not part of=20
> the protocol.
> The only thing in the protocol is the shared secret.  RADIUS=20
> can only validate that its talking with a client that is=20
> shares a secret with. So there is nothing we can do in the=20
> protocol.  And furthermore RADIUS and Diameter for that=20
> matter are hop by hop protocols.
>
=20
[Joe] RADIUS protocol doesn't typically allow for long term sensitive
information to be passed from the RADIUS server to the RADIUS client.
Perhaps RADIUS should not be used in this way if it cannot support this
kind of authorization. =20

> Having said this any prudent deployment of RADIUS already=20
> does or should do what you say.
>=20
> IMO the only thing that we can say is:  state the problem and=20
> what a RADIUS deployment should do. =20
>=20

[Joe] OK, I think it would be acceptable to leave the description to the
security considerations section.=20

>=20
> > -----Original Message-----
> > From: Salowey, Joe [mailto:[email-masked]]
> > Sent: Tuesday, March 29, 2005 11:41 PM
> > To: Avi Lior; [email-masked]
> > Cc: Beck01, Wolfgang
> > Subject: RE: Issue 79; digest-auth realm validation
> >=20
> >=20
> > =20
> >=20
> > > -----Original Message-----
> > > From: Avi Lior [mailto:[email-masked]]
> > > Sent: Tuesday, March 29, 2005 11:34 AM
> > > To: Salowey, Joe; [email-masked]'
> > > Cc: 'Beck01, Wolfgang'
> > > Subject: RE: Issue 79; digest-auth realm validation
> > >=20
> > > Joe,
> > >=20
> > > So I think I understand what the risk is -- based on the previous=20
> > > emails that you sent.
> > >=20
> > > But this still bothers me:
> > >=20
> > > We could have text in the security section that says
> > something to the
> > > effect: there is a security risk in that the NAS (or proxies for=20
> > > that matter may obtaining digest hashes.
> > >=20
> >=20
> > [Joe] That would be good, but it should also discuss the issue of=20
> > authorization.
> >=20
> > > It's a totally different thing to say that the RADIUS=20
> server should=20
> > > authorize the NAS.  We don't have that concept in RADIUS.=20
>  In RADIUS=20
> > > all clients are trusted via the shared secret.
> > >=20
> >=20
> > [Joe] When RADIUS is used in the typical network access=20
> case where all=20
> > RADIUS clients are essentially equivalent and the RADIUS servers=20
> > authorization is implicit and less important.  When RADIUS=20
> is used in=20
> > environments where the RADIUS clients provide different=20
> services and=20
> > start releasing longer term secret data it becomes a problem.
> >=20
> > > How do you propose that the client be authorized? And even if you=20
> > > authorize the client it maybe a proxy, that is we don't=20
> know what is=20
> > > the ultimate client in RADIUS.
> > >=20
> >=20
> > [Joe] If there is no proxy then the RADIUS server must maintain the=20
> > information associating a RADIUS Client to a set of realms.
> > In the case
> > of the proxies it would be the job of one of the proxies in=20
> the chain=20
> > to validate the authorization and reject the request if it is not=20
> > authorized.
> >=20
> >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: Salowey, Joe [mailto:[email-masked]]
> > > > Sent: Tuesday, March 29, 2005 1:11 PM
> > > > To: Beck01, Wolfgang
> > > > Cc: [email-masked]
> > > > Subject: RE: Issue 79; digest-auth realm validation
> > > >=20
> > > >=20
> > > > =20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: Beck01, Wolfgang [mailto:[email-masked]]
> > > > > Sent: Tuesday, March 29, 2005 7:11 AM
> > > > > To: Salowey, Joe
> > > > > Cc: [email-masked]
> > > > > Subject: Issue 79; digest-auth realm validation
> > > > >=20
> > > > > Joe,
> > > > >=20
> > > > > here is a text proposal:
> > > > > "The RADIUS server MUST check if the user identified by
> > > > >    the User-Name attribute
> > > > >    o  is authorized to access the protection space=20
> > defined by the
> > > > >       Digest-URI and Digest-Realm attributes,
> > > > >    o  is authorized to use the URI included in the SIP-AOR=20
> > > > > attribute, if
> > > > >       this attribute is present.
> > > > >    If any of those checks fails, the RADIUS server=20
> MUST send an
> > > > >    Access-Reject."
> > > > >=20
> > > > > Does this resolve the issue?
> > > > >=20
> > > > [Joe] There is also a need to authorize the application=20
> > > server (radius
> > > > client) to prevent a RADIUS client from obtaining digest=20
> > hashes (HA1
> > > > attribute) for another realm and from advertising a realm=20
> > > that is not=20
> > > > authorized to service.
> > > >=20
> > > > "The RADIUS server MUST check if the RADIUS client making=20
> > > > 	the request=20
> > > > 	o  is authorized to act as part of the protection space=20
> > > > 	   defined by the Digest-URI and Digest-Realm attributes
> > > >       If this check fails, the RADIUS server MUST send an
> > > > 	Access-Reject."
> > > > =20
> > > > I'm not sure if it makes any sense to check the SIP-AOR=20
> > > attribute.  If=20
> > > > the SIP-AOR attribute is not part of the Digest=20
> > calculation done by=20
> > > > the server then I do not think it makes sense to check it.
> > > >=20
> > > >=20
> > > >=20
> > > > > Wolfgang
> > > > >=20
> > > > > --
> > > > > T-Systems International GmbH
> > > > > Technologiezentrum
> > > > > Next Generation IP Services and Systems
> > > > > +49 6151 9372863
> > > > > Am Kavalleriesand 3
> > > > > 64295 Darmstadt
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > --
> > > > > to unsubscribe send a message to
> > > > > [email-masked] with the word 'unsubscribe' in=20
> > > > > a single line as the message text body.
> > > > > archive: <http://psg.com/lists/radiusext/>
> > > > >=20
> > > >=20
> > > > --
> > > > to unsubscribe send a message to=20
> > [email-masked] with
> > > > the word 'unsubscribe' in a single line as the message=20
> text body.
> > > > archive: <http://psg.com/lists/radiusext/>
> > > >=20
> > >=20
> > > --
> > > to unsubscribe send a message to=20
> [email-masked] with
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> > >=20
> >=20
>=20

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

Delivery-date: Wed, 30 Mar 2005 16:55:44 +0000
content-class: urn:content-classes:message
Subject: RE: Issue 79; digest-auth realm validation
Date: Wed, 30 Mar 2005 08:58:25 -0800
From: "Salowey, Joe" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:[email-masked]]=20
> Sent: Wednesday, March 30, 2005 12:55 AM
> To: Salowey, Joe
> Cc: [email-masked]
> Subject: AW: Issue 79; digest-auth realm validation
>=20
> Joe,
>=20
> > [Joe] There is also a need to authorize the application=20
> server (radius
> > client) to prevent a RADIUS client from obtaining digest hashes (HA1
> > attribute) for another realm and from advertising a realm=20
> that is not=20
> > authorized to service.
>=20
> Your issue is valid in a single case:
>=20
> An HTTP-style request passes through the HTTP-style proxies=20
> RADIUS client A (realm A) and RADIUS client B (realm B). Both=20
> clients demand digest authentication and both clients use the=20
> same RADIUS server as back-end.
>=20
> In all other cases, the compromised RADIUS client will never=20
> see HTTP-style requests from other realms.
>=20

[Joe] I agree that the case that is interesting is when the RADIUS
server supports RADIUS clients that support different realms. I don't
see how it is possible that a RADIUS client will never see HTTP-style
requests from other realms, but perhaps I am missing something.

> An attacker gains control over client A. The attacker can now=20
> pretend to be RADIUS client B.
>=20
> If an attacker controls the RADIUS client, the worst case has=20
> already happened. The attacker can provide service to=20
> unauthorized users.
> The attacker can reject the HTTP-style request without=20
> inserting a response-auth directive (btw RADIUS does not=20
> allow to put the necessary attributes into Access-Reject=20
> messages). The attacker can choose not to send a=20
> response-auth directive at all. The attacker can replace QoP=20
> 'auth-int' with 'auth' and modify the HTTP-style content=20
> coming from client B. So adding a paragraph like
>=20

[Joe] It seems that the compromised RADIUS client can pretend to be
providing service for a different realm which in turn allows it to
obtain the Digest-HA1 for users in another realm.  Both of these
exposures are different than the ones you mention.=20

> "A RADIUS server MUST check if the RADIUS client is=20
> authorized to use the value it has put into the Digest-Realm=20
> attribute. If the RADIUS client is not authorized to use this=20
> realm value, the RADIUS server sends an Access-Reject. The=20
> RADIUS server considers this client as compromised. It=20
> notifies the operator and rejects all future requests from=20
> this client, until some management action tells it to do so again."
>=20
> would not add much security.
>=20

[Joe] I believe it helps to mitigate the exposures above.  I am most
concerned about the exposure of Digest-HA1 when the Digest-algorithm MD5
is used.   There may be other issues, but that depends on what clients
expect from a realm.=20

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

Delivery-date: Wed, 30 Mar 2005 14:57:24 +0000
From: Avi Lior <[email-masked]>
To: "'Salowey, Joe'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Cc: "Beck01, Wolfgang" <[email-masked]>
Subject: RE: Issue 79; digest-auth realm validation
Date: Wed, 30 Mar 2005 09:56:52 -0500

Hi Joe,

I just have a comment on this bit:

> [Joe] If there is no proxy then the RADIUS server must maintain the
> information associating a RADIUS Client to a set of realms.  
> In the case
> of the proxies it would be the job of one of the proxies in 
> the chain to
> validate the authorization and reject the request if it is not
> authorized. 

Well, this is not part of what RADIUS does.  Its not part of the protocol.
The only thing in the protocol is the shared secret.  RADIUS can only
validate that its talking with a client that is shares a secret with. So
there is nothing we can do in the protocol.  And furthermore RADIUS and
Diameter for that matter are hop by hop protocols.

Having said this any prudent deployment of RADIUS already does or should do
what you say.

IMO the only thing that we can say is:  state the problem and what a RADIUS
deployment should do.  

> -----Original Message-----
> From: Salowey, Joe [mailto:[email-masked]] 
> Sent: Tuesday, March 29, 2005 11:41 PM
> To: Avi Lior; [email-masked]
> Cc: Beck01, Wolfgang
> Subject: RE: Issue 79; digest-auth realm validation
> 
> 
>  
> 
> > -----Original Message-----
> > From: Avi Lior [mailto:[email-masked]]
> > Sent: Tuesday, March 29, 2005 11:34 AM
> > To: Salowey, Joe; [email-masked]'
> > Cc: 'Beck01, Wolfgang'
> > Subject: RE: Issue 79; digest-auth realm validation
> > 
> > Joe,
> > 
> > So I think I understand what the risk is -- based on the
> > previous emails that you sent.
> > 
> > But this still bothers me:
> > 
> > We could have text in the security section that says 
> something to the
> > effect: there is a security risk in that the NAS (or proxies
> > for that matter may obtaining digest hashes.
> > 
> 
> [Joe] That would be good, but it should also discuss the issue of
> authorization.
> 
> > It's a totally different thing to say that the RADIUS server 
> > should authorize the NAS.  We don't have that concept in 
> > RADIUS.  In RADIUS all clients are trusted via the shared secret.
> > 
> 
> [Joe] When RADIUS is used in the typical network access case where all
> RADIUS clients are essentially equivalent and the RADIUS servers
> authorization is implicit and less important.  When RADIUS is used in
> environments where the RADIUS clients provide different services and
> start releasing longer term secret data it becomes a problem.  
> 
> > How do you propose that the client be authorized? And even if 
> > you authorize the client it maybe a proxy, that is we don't 
> > know what is the ultimate client in RADIUS.
> > 
> 
> [Joe] If there is no proxy then the RADIUS server must maintain the
> information associating a RADIUS Client to a set of realms.  
> In the case
> of the proxies it would be the job of one of the proxies in 
> the chain to
> validate the authorization and reject the request if it is not
> authorized. 
> 
> 
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Salowey, Joe [mailto:[email-masked]]
> > > Sent: Tuesday, March 29, 2005 1:11 PM
> > > To: Beck01, Wolfgang
> > > Cc: [email-masked]
> > > Subject: RE: Issue 79; digest-auth realm validation
> > > 
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Beck01, Wolfgang [mailto:[email-masked]]
> > > > Sent: Tuesday, March 29, 2005 7:11 AM
> > > > To: Salowey, Joe
> > > > Cc: [email-masked]
> > > > Subject: Issue 79; digest-auth realm validation
> > > > 
> > > > Joe,
> > > > 
> > > > here is a text proposal:
> > > > "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."
> > > > 
> > > > Does this resolve the issue?
> > > > 
> > > [Joe] There is also a need to authorize the application 
> > server (radius
> > > client) to prevent a RADIUS client from obtaining digest 
> hashes (HA1
> > > attribute) for another realm and from advertising a realm 
> > that is not 
> > > authorized to service.
> > > 
> > > "The RADIUS server MUST check if the RADIUS client making 
> > > 	the request 
> > > 	o  is authorized to act as part of the protection space 
> > > 	   defined by the Digest-URI and Digest-Realm attributes
> > >       If this check fails, the RADIUS server MUST send an
> > > 	Access-Reject."
> > >  
> > > I'm not sure if it makes any sense to check the SIP-AOR 
> > attribute.  If 
> > > the SIP-AOR attribute is not part of the Digest 
> calculation done by 
> > > the server then I do not think it makes sense to check it.
> > > 
> > > 
> > > 
> > > > Wolfgang
> > > > 
> > > > --
> > > > T-Systems International GmbH
> > > > Technologiezentrum
> > > > Next Generation IP Services and Systems
> > > > +49 6151 9372863
> > > > Am Kavalleriesand 3
> > > > 64295 Darmstadt
> > > > 
> > > > 
> > > > 
> > > > --
> > > > to unsubscribe send a message to
> > > > [email-masked] with the word 'unsubscribe' in 
> > > > a single line as the message text body.
> > > > archive: <http://psg.com/lists/radiusext/>
> > > > 
> > > 
> > > --
> > > to unsubscribe send a message to 
> [email-masked] with
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> > > 
> > 
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 

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

Delivery-date: Wed, 30 Mar 2005 13:16:46 +0000
Date: Wed, 30 Mar 2005 16:10:57 +0300
From: Miguel Garcia <[email-masked]>
To: ext Bernard Aboba <[email-masked]>
CC: Jari Arkko <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>, [email-masked], "Beck01, Wolfgang" <[email-masked]>
Subject: Re: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, Diameter dependency

That's fine. I will send a summary of this discussion to the AAA list 
and will work on a new revision.

I expect then, that the compatibility section will be amended (I will 
synchronize with Wolfgang). But have we decided whether that section 
will included in the Diameter or RADUIS draft? I think I read e-mails 
supporting both approaches, so we need to decided on this. Where does 
this section make sense?

BR,

       Miguel

Bernard Aboba wrote:
> Yes, it makes sense to me to add this mode of operation so that Diameter
> SIP can interoperate with all modes of RADIUS Digest.
> 
> 
>>>Now, we can add this later requirement and provide a solution for it.
>>>Is it the decision that, in order to clear the Diameter SIP app in the
>>>IESG we need to add this mode of operation? At this stage I wouldn't
>>>like to add anything that is essential for the publication of the
>>>document as an RFC.
>>>
>>>/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
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, 30 Mar 2005 08:57:30 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: Issue 79; digest-auth realm validation
Date: Wed, 30 Mar 2005 10:54:57 +0200

Joe,

> [Joe] There is also a need to authorize the application server (radius
> client) to prevent a RADIUS client from obtaining digest hashes (HA1
> attribute) for another realm and from advertising a realm 
> that is not authorized to service.

Your issue is valid in a single case:

An HTTP-style request passes through the HTTP-style proxies
RADIUS client A (realm A) and RADIUS client B (realm B). Both
clients demand digest authentication and both clients use the
same RADIUS server as back-end.

In all other cases, the compromised RADIUS client will never
see HTTP-style requests from other realms.

An attacker gains control over client A. The attacker can
now pretend to be RADIUS client B.

If an attacker controls the RADIUS client, the worst case has already
happened. The attacker can provide service to unauthorized users.
The attacker can reject the HTTP-style request without inserting
a response-auth directive (btw RADIUS does not allow to put the
necessary attributes into Access-Reject messages). The attacker can
choose not to send a response-auth directive at all. The attacker
can replace QoP 'auth-int' with 'auth' and modify the HTTP-style
content coming from client B. So adding a paragraph like

"A RADIUS server MUST check if the RADIUS client is authorized to use
the value it has put into the Digest-Realm attribute. If the RADIUS
client is not authorized to use this realm value, the RADIUS server
sends an Access-Reject. The RADIUS server considers this client as
compromised. It notifies the operator and rejects all future requests
from this client, until some management action tells it to do so again."

would not add much security.

Joe wrote:
> I'm not sure if it makes any sense to check the SIP-AOR 
> attribute.  If the SIP-AOR attribute is not part of the 
> Digest calculation done by the server then I do not think it 
> makes sense to check it.
> 
There are many other message components in SIP that should be covered
by a digest calculation. That's why RfC3261 proposes TLS and S/MIME. 
However, there don't seem to be any SIP vendors supporting S/MIME, even
three years after RfC 3261 has been published.

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, 30 Mar 2005 05:00:43 +0000
Date: Tue, 29 Mar 2005 21:00:13 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Miguel Garcia <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: Re: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, Diameter dependency

Yes, it makes sense to me to add this mode of operation so that Diameter
SIP can interoperate with all modes of RADIUS Digest.

> > Now, we can add this later requirement and provide a solution for it.
> > Is it the decision that, in order to clear the Diameter SIP app in the
> > IESG we need to add this mode of operation? At this stage I wouldn't
> > like to add anything that is essential for the publication of the
> > document as an RFC.
> >
> > /Miguel

--
to unsubscribe send 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, 30 Mar 2005 04:37:43 +0000
content-class: urn:content-classes:message
Subject: RE: Issue 79; digest-auth realm validation
Date: Tue, 29 Mar 2005 20:40:51 -0800
From: "Salowey, Joe" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>
Cc: "Beck01, Wolfgang" <[email-masked]>

=20

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]=20
> Sent: Tuesday, March 29, 2005 11:34 AM
> To: Salowey, Joe; [email-masked]'
> Cc: 'Beck01, Wolfgang'
> Subject: RE: Issue 79; digest-auth realm validation
>=20
> Joe,
>=20
> So I think I understand what the risk is -- based on the=20
> previous emails that you sent.
>=20
> But this still bothers me:
>=20
> We could have text in the security section that says something to the
> effect: there is a security risk in that the NAS (or proxies=20
> for that matter may obtaining digest hashes.
>=20

[Joe] That would be good, but it should also discuss the issue of
authorization.

> It's a totally different thing to say that the RADIUS server=20
> should authorize the NAS.  We don't have that concept in=20
> RADIUS.  In RADIUS all clients are trusted via the shared secret.
>=20

[Joe] When RADIUS is used in the typical network access case where all
RADIUS clients are essentially equivalent and the RADIUS servers
authorization is implicit and less important.  When RADIUS is used in
environments where the RADIUS clients provide different services and
start releasing longer term secret data it becomes a problem. =20

> How do you propose that the client be authorized? And even if=20
> you authorize the client it maybe a proxy, that is we don't=20
> know what is the ultimate client in RADIUS.
>=20

[Joe] If there is no proxy then the RADIUS server must maintain the
information associating a RADIUS Client to a set of realms.  In the case
of the proxies it would be the job of one of the proxies in the chain to
validate the authorization and reject the request if it is not
authorized.=20

>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Salowey, Joe [mailto:[email-masked]]
> > Sent: Tuesday, March 29, 2005 1:11 PM
> > To: Beck01, Wolfgang
> > Cc: [email-masked]
> > Subject: RE: Issue 79; digest-auth realm validation
> >=20
> >=20
> > =20
> >=20
> > > -----Original Message-----
> > > From: Beck01, Wolfgang [mailto:[email-masked]]
> > > Sent: Tuesday, March 29, 2005 7:11 AM
> > > To: Salowey, Joe
> > > Cc: [email-masked]
> > > Subject: Issue 79; digest-auth realm validation
> > >=20
> > > Joe,
> > >=20
> > > here is a text proposal:
> > > "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=20
> > > attribute, if
> > >       this attribute is present.
> > >    If any of those checks fails, the RADIUS server MUST send an
> > >    Access-Reject."
> > >=20
> > > Does this resolve the issue?
> > >=20
> > [Joe] There is also a need to authorize the application=20
> server (radius
> > client) to prevent a RADIUS client from obtaining digest hashes (HA1
> > attribute) for another realm and from advertising a realm=20
> that is not=20
> > authorized to service.
> >=20
> > "The RADIUS server MUST check if the RADIUS client making=20
> > 	the request=20
> > 	o  is authorized to act as part of the protection space=20
> > 	   defined by the Digest-URI and Digest-Realm attributes
> >       If this check fails, the RADIUS server MUST send an
> > 	Access-Reject."
> > =20
> > I'm not sure if it makes any sense to check the SIP-AOR=20
> attribute.  If=20
> > the SIP-AOR attribute is not part of the Digest calculation done by=20
> > the server then I do not think it makes sense to check it.
> >=20
> >=20
> >=20
> > > Wolfgang
> > >=20
> > > --
> > > T-Systems International GmbH
> > > Technologiezentrum
> > > Next Generation IP Services and Systems
> > > +49 6151 9372863
> > > Am Kavalleriesand 3
> > > 64295 Darmstadt
> > >=20
> > >=20
> > >=20
> > > --
> > > to unsubscribe send a message to
> > > [email-masked] with the word 'unsubscribe' in=20
> > > a single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> > >=20
> >=20
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 30 Mar 2005 04:35:43 +0000
Date: Wed, 30 Mar 2005 07:34:53 +0300
From: Jari Arkko <[email-masked]>
To: Miguel Garcia <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: Re: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, Diameter dependency

This makes sense to me.

--Jari

Miguel Garcia wrote:

> Hi:
>
> I did some investigation of what is the reason why Diameter app does 
> not support client generated nonces, and I found out that there is no 
> technical reason why this mode of operation is not supported. We 
> simply never had any requirements to support this scenario.
>
> You might remember that the Diameter SIP app. was originated in 3GPP, 
> where nonces are generated in the Diameter server. Additionally, the 
> Diameter SIP app. was born earlier than the RADIUS Digest draft. So no 
> requirements led to no support.
>
> Now, we can add this later requirement and provide a solution for it. 
> Is it the decision that, in order to clear the Diameter SIP app in the 
> IESG we need to add this mode of operation? At this stage I wouldn't 
> like to add anything that is essential for the publication of the 
> document as an RFC.
>
> /Miguel
>
> Bernard Aboba wrote:
>
>>> I am more worried about Wolfgang's concerns about "Diameter SIP 
>>> document
>>> is likely to be blocked based on the lack of compatibility with RADIUS
>>> Digest". Can someone expand these concerns, because we should addressed
>>> them. I thought that we have limited compatibility just restricted by
>>> the smaller scope of the RADIUS draft.
>>
>>
>>
>> It is ok for Diameter SIP to be a *superset* of the RADIUS Digest
>> document.  It is not ok for Diameter SIP to be unable to translate 
>> AVPs or
>> modes of operation that occur within RADIUS Digest.
>>
>> From reading the RADIUS Digest Diameter compatibility section, it would
>> appear that Diameter SIP cannot handle a situation where the RADIUS 
>> client
>> generates nonces.  If so, this would mean that Diameter SIP is a 
>> *subset*
>> of RADIUS Digest functionality.
>>
>> -- 
>> to unsubscribe send 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, 29 Mar 2005 23:17:44 +0000
Date: Tue, 29 Mar 2005 21:09:47 +0300
From: Miguel Garcia <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: Re: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, Diameter dependency

Hi:

I did some investigation of what is the reason why Diameter app does not 
support client generated nonces, and I found out that there is no 
technical reason why this mode of operation is not supported. We simply 
never had any requirements to support this scenario.

You might remember that the Diameter SIP app. was originated in 3GPP, 
where nonces are generated in the Diameter server. Additionally, the 
Diameter SIP app. was born earlier than the RADIUS Digest draft. So no 
requirements led to no support.

Now, we can add this later requirement and provide a solution for it. Is 
it the decision that, in order to clear the Diameter SIP app in the IESG 
we need to add this mode of operation? At this stage I wouldn't like to 
add anything that is essential for the publication of the document as an 
RFC.

/Miguel

Bernard Aboba wrote:

>>I am more worried about Wolfgang's concerns about "Diameter SIP document
>>is likely to be blocked based on the lack of compatibility with RADIUS
>>Digest". Can someone expand these concerns, because we should addressed
>>them. I thought that we have limited compatibility just restricted by
>>the smaller scope of the RADIUS draft.
> 
> 
> It is ok for Diameter SIP to be a *superset* of the RADIUS Digest
> document.  It is not ok for Diameter SIP to be unable to translate AVPs or
> modes of operation that occur within RADIUS Digest.
> 
> From reading the RADIUS Digest Diameter compatibility section, it would
> appear that Diameter SIP cannot handle a situation where the RADIUS client
> generates nonces.  If so, this would mean that Diameter SIP is a *subset*
> of RADIUS Digest functionality.
> 
> --
> to unsubscribe send 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
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: Tue, 29 Mar 2005 19:34:18 +0000
From: Avi Lior <[email-masked]>
To: "'Salowey, Joe'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Beck01, Wolfgang'" <[email-masked]>
Subject: RE: Issue 79; digest-auth realm validation
Date: Tue, 29 Mar 2005 14:33:54 -0500

Joe,

So I think I understand what the risk is -- based on the previous emails
that you sent.

But this still bothers me:

We could have text in the security section that says something to the
effect: there is a security risk in that the NAS (or proxies for that matter
may obtaining digest hashes.

It's a totally different thing to say that the RADIUS server should
authorize the NAS.  We don't have that concept in RADIUS.  In RADIUS all
clients are trusted via the shared secret.

How do you propose that the client be authorized? And even if you authorize
the client it maybe a proxy, that is we don't know what is the ultimate
client in RADIUS.

> -----Original Message-----
> From: Salowey, Joe [mailto:[email-masked]] 
> Sent: Tuesday, March 29, 2005 1:11 PM
> To: Beck01, Wolfgang
> Cc: [email-masked]
> Subject: RE: Issue 79; digest-auth realm validation
> 
> 
>  
> 
> > -----Original Message-----
> > From: Beck01, Wolfgang [mailto:[email-masked]]
> > Sent: Tuesday, March 29, 2005 7:11 AM
> > To: Salowey, Joe
> > Cc: [email-masked]
> > Subject: Issue 79; digest-auth realm validation
> > 
> > Joe,
> > 
> > here is a text proposal:
> > "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."
> > 
> > Does this resolve the issue?
> > 
> [Joe] There is also a need to authorize the application server (radius
> client) to prevent a RADIUS client from obtaining digest hashes (HA1
> attribute) for another realm and from advertising a realm 
> that is not authorized to service.
> 
> "The RADIUS server MUST check if the RADIUS client making 
> 	the request 
> 	o  is authorized to act as part of the protection space 
> 	   defined by the Digest-URI and Digest-Realm attributes
>       If this check fails, the RADIUS server MUST send an
> 	Access-Reject."
>  
> I'm not sure if it makes any sense to check the SIP-AOR 
> attribute.  If the SIP-AOR attribute is not part of the 
> Digest calculation done by the server then I do not think it 
> makes sense to check it.
> 
> 
> 
> > Wolfgang
> > 
> > --
> > T-Systems International GmbH
> > Technologiezentrum
> > Next Generation IP Services and Systems
> > +49 6151 9372863
> > Am Kavalleriesand 3
> > 64295 Darmstadt
> > 
> > 
> > 
> > --
> > to unsubscribe send a message to
> > [email-masked] with the word 'unsubscribe' in 
> > a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 
> --
> to unsubscribe send 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, 29 Mar 2005 18:08:35 +0000
content-class: urn:content-classes:message
Subject: RE: Issue 79; digest-auth realm validation
Date: Tue, 29 Mar 2005 10:11:27 -0800
From: "Salowey, Joe" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:[email-masked]]=20
> Sent: Tuesday, March 29, 2005 7:11 AM
> To: Salowey, Joe
> Cc: [email-masked]
> Subject: Issue 79; digest-auth realm validation
>=20
> Joe,
>=20
> here is a text proposal:
> "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=20
> attribute, if
>       this attribute is present.
>    If any of those checks fails, the RADIUS server MUST send an
>    Access-Reject."
>=20
> Does this resolve the issue?
>=20
[Joe] There is also a need to authorize the application server (radius
client) to prevent a RADIUS client from obtaining digest hashes (HA1
attribute) for another realm and from advertising a realm that is not
authorized to service.

"The RADIUS server MUST check if the RADIUS client making=20
	the request=20
	o  is authorized to act as part of the protection space=20
	   defined by the Digest-URI and Digest-Realm attributes
      If this check fails, the RADIUS server MUST send an
	Access-Reject."
=20
I'm not sure if it makes any sense to check the SIP-AOR attribute.  If
the SIP-AOR attribute is not part of the Digest calculation done by the
server then I do not think it makes sense to check it.

> Wolfgang
>=20
> --
> T-Systems International GmbH
> Technologiezentrum
> Next Generation IP Services and Systems
> +49 6151 9372863
> Am Kavalleriesand 3
> 64295 Darmstadt
>=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: Tue, 29 Mar 2005 15:11:32 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Issue 79; digest-auth realm validation
Date: Tue, 29 Mar 2005 17:10:49 +0200

Joe,

here is a text proposal:
"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."

Does this resolve the issue?

Wolfgang

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

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

Delivery-date: Mon, 28 Mar 2005 19:56:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Pre-work item review
Date: Mon, 28 Mar 2005 11:54:51 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Greg Weber" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

>=20
> > > RADIUS Extensions for IEEE 802
> > >
> >=20
> http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.tx
> > t
>=20
> I support the ideas here, but it's unclear if the current=20
> draft is compliant with the 'backward compatibility'=20
> bullet in the charter.  The current text adds data types to=20
> RADIUS for 'extended' attributes (e.g. UInt64??). =20
> One of the co-authors mentioned in MSP that they're moving=20
> away from 'extended attributes', but it's kinda hard to see=20
> if it's compliant with our charter based on 'planned'=20
> changes to the draft.
>

There is an issue logged against this draft related to your comment, so
it will be addressed.

Thanks,

Paul

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

Delivery-date: Mon, 28 Mar 2005 17:48:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Pre-work item review
Date: Mon, 28 Mar 2005 09:47:11 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Greg Weber" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Greg writes...=20

> > > RADIUS Extensions for IEEE 802
> > >
> >=20
> http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.tx
> > t
>=20
> I support the ideas here, but it's unclear if the current=20
> draft is compliant with the 'backward compatibility'=20
> bullet in the charter.  The current text adds data types to=20
> RADIUS for 'extended' attributes (e.g. UInt64??). =20
> One of the co-authors mentioned in MSP that they're moving=20
> away from 'extended attributes', but it's kinda hard to see=20
> if it's compliant with our charter based on 'planned'=20
> changes to the draft.
>=20

As the current draft editor, let me be clear that there is still some
'scrubbing' the document requires in regards to any references to
extended RADIUS attributes.  The intention is to continue molding the
document be in a clear alignment with existing WG mandates.=20

Whether a WG member is comfortable in accepting the current draft (as
opposed to a future draft) to be the basis for a ratified work item is
hopefully a secondary consideration to the primary of whether these
attribute standardization efforts make sense at all.

MS

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

Delivery-date: Mon, 28 Mar 2005 16:59:21 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Pre-work item review
Date: Mon, 28 Mar 2005 08:59:08 -0800

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

...

> 
>> IMHO, a better way to ask this question might have been to ask
the WG
>> if they thought that updating the old MIBs was important enough
to
>> work on ...
> 
> Yes.  Point taken, however, this work was requested by one of our
> Area Directors and is included in the charter, so the chairs
presumed
> that the work needed to be done. 

DO NOT QUESTION AUTHORITY
 
> 
>> ... whether the questions of IEEE 802 attributes (including
whether
>> they are necessary at all) were interesting, etc.,
> 
> This is work that was requested by the IEEE 802.1 WG, and is also
> listed in our charter.  

See above.

...

~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, 28 Mar 2005 16:56:29 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-radext-chargeable-user-id-04.txt
Date: Mon, 28 Mar 2005 11:55:39 -0500
From: "Nelson, David" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>

> This version includes resolution for the issue below submitted by
David
> Nelson -- not shown in the RADEXT issues list yet.

I concur that the -04 draft resolves this issue.

-- 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: Mon, 28 Mar 2005 16:41:17 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-radext-chargeable-user-id-04.txt
Date: Mon, 28 Mar 2005 08:40:31 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, "Bernard Aboba" <[email-masked]>

This version includes resolution for the issue below submitted by David
Nelson -- not shown in the RADEXT issues list yet.  Issue 66 (in the
RADEXT issues list) was addressed in version -03, we need to close it.
Thanks,
Farid

-----
Issue with CUI-03 in the definition of CUI content.

=20

Submitter name: David B. Nelson
Submitter email address: [email-masked]
Date first submitted: 08 March 2005
Reference:
Document: CUI-03
Comment type: T
Priority: S
Section: 1.0, 2.2
Rationale/Explanation of issue: (see below)
Requested change:

=20

In Section 1 Introduction: =20

  "While this
   mechanism is good practice in some circumstances, there are problems
   if local and intermediate networks require a user identity."

No entity other than the home AAA can derive a true user identity from
the CUI, so I would recommend that "require a user identity" (above) be
changed to "require an authenticated surrogate identity to bind the
current session".

=20

In Section 2.2 CUI Attribute:
  "String:
      The string identifies the CUI of the end-user and is of type
      UTF8String.  This string value is a reference to a particular
      user.  The format and the interpretation of the string value , and
      the binding lifetime of the reference to the user is determined
      based on business agreements.  For example, the lifetime can be
      set to one billing period.  In cases where the attribute is used
      to indicate the NAS support for the CUI, the string value contains
      a nul character."

In discussions on the WG mailing list or in other e-mail threads on this
draft, I believe we had reached agreement that the content of the CUI
attribute would be described as an "opaque token", or as an
authenticated surrogate identity, but that only the Home AAA server was
in a position to make any other semantic interpretation of the CUI
content and that all other entities, e.g. proxy servers or NASes, should
treat the CUI as a "cookie", performing a binary-equality-test operation
on two CUI instances, but making no other interpretation of the CUI
content.  That restriction didn't make in into the -03 draft.

I would recommend that "The format and the interpretation of the string
value, and the binding lifetime of the reference to the user is
determined based on business agreements." (above) be changed to "The
format and content of the string value is determined by the Home RADIUS
server.  The binding lifetime of the reference to the user is determined
based on business agreements.  RADIUS entities other than the Home
RADIUS server MUST treat the CUI content as an opaque token, and SHOULD
NOT perform operations on its content other than a binary equality
comparison test, between two instances of CUI."   =20

--------=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Monday, March 28, 2005 8:08 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-radext-chargeable-user-id-04.txt
>=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the RADIUS EXTensions Working=20
> Group of the IETF.
>=20
> 	Title		: Chargeable User Identity
> 	Author(s)	: F. Adrangi, et al.
> 	Filename	: draft-ietf-radext-chargeable-user-id-04.txt
> 	Pages		: 10
> 	Date		: 2005-3-25
> =09
> This document describes a new RADIUS attribute,
>    Chargeable-User-Identity.  This attribute can be used by a home
>    network to identify a user for the purpose of roaming transactions
>    that occur outside of the home network.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeab
le-user-id-04.txt

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

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

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-ietf-radext-chargeable-user-id-04.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-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, 28 Mar 2005 15:41:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Pre-work item review
Date: Mon, 28 Mar 2005 10:40:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Glen Zorn writes...

> This is pertinent to a question I asked in my own response to this
> question.  My (imperfect) understanding of the IETF process is that
> once a draft is adopted as a WG item, change control is ceded to the
> IETF ....

Yes, I agree.

> ... and that whatever state the draft is in when so adopted becomes
> irrelevant (as do, to some extent, the opinions of the authors).

It seems reasonable for the WG to weigh in on whether the current state
of the draft is sufficiently "well-baked" such that the WG is ready to
take on the change control.  While we have an editor to act as scribe,
the WG is collectively responsible for the content going forward, which
generally implies some work.

> IMHO, a better way to ask this question might have been to ask the
> WG if they thought that updating the old MIBs was important enough
> to work on ...

Yes.  Point taken, however, this work was requested by one of our Area
Directors and is included in the charter, so the chairs presumed that
the work needed to be done.

> ... whether the questions of IEEE 802 attributes (including
> whether they are necessary at all) were interesting, etc.,

This is work that was requested by the IEEE 802.1 WG, and is also listed
in our charter.  Of course, there does need to be a sufficient community
of interest, e.g. in the RADEXT WG, for this work to proceed in the
IETF.

> OTOH,
> this assumes that WGs are formed to solve problems, rather than to
> produce approved documents; maybe that's not the way things are.

I think there is some of both in the IETF today, especially to the
extent that we are asked to take on work at the behest of another SDO.
But I do take your point that implicit in the question of whether
specific drafts are ready to be accepted as WG work items is the
sub-question of whether there is a sufficient community of interest to
solve the problem addressed by the drafts.

--
to unsubscribe send 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, 28 Mar 2005 04:24:29 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Greg Weber'" <[email-masked]>, "'Nelson, David'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Pre-work item review
Date: Sun, 27 Mar 2005 20:21:56 -0800

Greg Weber <> supposedly scribbled:

...

>>> RADIUS Extensions for IEEE 802
>>> 
>>
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.
tx
>> t
> 
> I support the ideas here, but it's unclear if the current draft is
> compliant with the 'backward compatibility' 
> bullet in the charter.  The current text adds data types to RADIUS
> for 'extended' attributes (e.g. UInt64??). 
> One of the co-authors mentioned in MSP that they're moving away
from
> 'extended attributes', but it's kinda hard to see if it's
compliant
> with our charter based on 'planned' changes to the draft. 

This is pertinent to a question I asked in my own response to this
question.  My (imperfect) understanding of the IETF process is that
once a draft is adopted as a WG item, change control is ceded to the
IETF and that whatever state the draft is in when so adopted becomes
irrelevant (as do, to some extent, the opinions of the authors).
IMHO, a better way to ask this question might have been to ask the
WG if they thought that updating the old MIBs was important enough
to work on, whether the questions of IEEE 802 attributes (including
whether they are necessary at all) were interesting, etc., instead
of just presenting a laundry list of individual submissions.  OTOH,
this assumes that WGs are formed to solve problems, rather than to
produce approved documents; maybe that's not the way things are.

> 
> Greg

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, 28 Mar 2005 03:49:23 +0000
From: Greg Weber <[email-masked]>
Subject: Re: Pre-work item review
To: [email-masked] (Nelson, David)
Date: Sun, 27 Mar 2005 22:48:45 -0500 (EST)
Cc: [email-masked]

> > RADIUS MIB Revision
> > http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
> > http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
> > http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
> > http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt
> > RFC 3576 MIBs
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-03.txt
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-03.txt

Yes to all the MIBs.

> > RADIUS Extensions for IEEE 802
> >
> http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt

I support the ideas here, but it's unclear if the current
draft is compliant with the 'backward compatibility' 
bullet in the charter.  The current text adds data types
to RADIUS for 'extended' attributes (e.g. UInt64??).  
One of the co-authors mentioned in MSP that they're moving 
away from 'extended attributes', but it's kinda hard to 
see if it's compliant with our charter based on 'planned' 
changes to the draft.

Greg

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

Delivery-date: Sun, 27 Mar 2005 22:08:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Pre-work item review
Date: Mon, 28 Mar 2005 01:08:16 +0300
From: <[email-masked]>
To: <[email-masked]>

> > RADIUS Extensions for IEEE 802
> >
> http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee8
> 02-03.txt

Yes

Cheers,
	Jouni

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

Delivery-date: Sun, 27 Mar 2005 00:56:13 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, <[email-masked]>
Subject: RE: Pre-work item review
Date: Sat, 26 Mar 2005 16:55:27 -0800

Nelson, David <> supposedly scribbled:

> As a reminder to the RADEXT WG members, please respond either
> affirmatively or negatively with respect to each of these
documents.
> Should the draft(s) become a RADEXT WG Work Item?  {Yes | No} 
> 
> You may comment on the four IPv6 MIB update documents as one,
because
> they have highly similar content. 

What does the current content of the drafts have to do with the
question?  

> 
> Silence is not generally accepted as WG consensus, so your active
> reply is requested. 

Interesting, since this flies in the face of several thousand years
of traditional interpretation of silence as assent.  

> 
>> As discussed at today's meeting, we are looking to gauge WG
interest
>> in making the following documents WG work items:
>> 
>> RADIUS MIB Revision
>>
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
>>
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
>>
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
>>
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt

Yes.

>> 
>> RFC 3576 MIBs
>> 
>
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-c
lien
> t-
>> mib-03.txt

Yes.

>> 
>
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-s
erve
> r-
>> mib-03.txt

Yes.

>> 
>> RADIUS Extensions for IEEE 802
>> 
>
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.
txt

Yes.

>> 
>> Please send your comments to the RADEXT mailing list.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Fri, 25 Mar 2005 05:58:14 +0000
Date: Fri, 25 Mar 2005 07:57:50 +0200
From: Jari Arkko <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Pre-work item review

I think the 802 document is a necessary thing. Of course, there
may be technical issues within the document, to be worked out
in this group.

The MIBs... I don't care much about the MIBs personally but they appear
to fall in our area as "mandatory maintenance".

--Jari

Nelson, David wrote:

>As a reminder to the RADEXT WG members, please respond either
>affirmatively or negatively with respect to each of these documents.
>Should the draft(s) become a RADEXT WG Work Item?  {Yes | No}
>
>You may comment on the four IPv6 MIB update documents as one, because
>they have highly similar content.
>
>Silence is not generally accepted as WG consensus, so your active reply
>is requested.
>
>  
>
>>As discussed at today's meeting, we are looking to gauge WG interest
>>    
>>
>in
>  
>
>>making the following documents WG work items:
>>
>>RADIUS MIB Revision
>>http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
>>http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
>>http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
>>http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt
>>
>>RFC 3576 MIBs
>>
>>    
>>
>http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-clien
>t-
>  
>
>>mib-03.txt
>>
>>    
>>
>http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-serve
>r-
>  
>
>>mib-03.txt
>>
>>RADIUS Extensions for IEEE 802
>>
>>    
>>
>http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt
>  
>
>>Please send your comments to the RADEXT mailing list.
>>    
>>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>
>
>  
>

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

Envelope-to: [email-masked]
Delivery-date: Fri, 25 Mar 2005 02:07:25 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Pre-work item review 
Date: Thu, 24 Mar 2005 21:03:08 -0500
Message-Id: <[email-masked]>

> > RADIUS MIB Revision
> > http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
> > http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
> > http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
> > http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt

  Yes.

> > RFC 3576 MIBs
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-clien
> t-mib-03.txt
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-serve
> r-mib-03.txt

  Yes.

> > RADIUS Extensions for IEEE 802

  No opinion as yet.

  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: Thu, 24 Mar 2005 23:04:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Pre-work item review
Date: Thu, 24 Mar 2005 15:03:57 -0800
From: "Narjala, Ranjit S" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

RADIUS Extensions for IEEE 802: Yes

Regards,
- Ranjit =20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nelson, David
Sent: Thursday, March 24, 2005 1:17 PM
To: [email-masked]
Subject: RE: Pre-work item review

As a reminder to the RADEXT WG members, please respond either
affirmatively or negatively with respect to each of these documents.
Should the draft(s) become a RADEXT WG Work Item?  {Yes | No}

You may comment on the four IPv6 MIB update documents as one, because
they have highly similar content.

Silence is not generally accepted as WG consensus, so your active reply
is requested.

> As discussed at today's meeting, we are looking to gauge WG interest
in
> making the following documents WG work items:
>=20
> RADIUS MIB Revision
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt
>=20
> RFC 3576 MIBs
>
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-clien
t-
> mib-03.txt
>
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-serve
r-
> mib-03.txt
>=20
> RADIUS Extensions for IEEE 802
>
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt
>=20
> Please send your comments to the RADEXT mailing list.

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

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

Delivery-date: Thu, 24 Mar 2005 21:17:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Pre-work item review
Date: Thu, 24 Mar 2005 16:17:26 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

As a reminder to the RADEXT WG members, please respond either
affirmatively or negatively with respect to each of these documents.
Should the draft(s) become a RADEXT WG Work Item?  {Yes | No}

You may comment on the four IPv6 MIB update documents as one, because
they have highly similar content.

Silence is not generally accepted as WG consensus, so your active reply
is requested.

> As discussed at today's meeting, we are looking to gauge WG interest
in
> making the following documents WG work items:
>=20
> RADIUS MIB Revision
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt
>=20
> RFC 3576 MIBs
>
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-clien
t-
> mib-03.txt
>
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-serve
r-
> mib-03.txt
>=20
> RADIUS Extensions for IEEE 802
>
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt
>=20
> Please send your comments to the RADEXT mailing list.

--
to unsubscribe send 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, 24 Mar 2005 14:49:35 +0000
Date: Thu, 24 Mar 2005 16:49:18 +0200
From: Jari Arkko <[email-masked]>
To: [email-masked]
Subject: digest issue 11 closure

Checking from the issue tracker this issue and comparing
it against -01. Here's what I found:

>     Due to the weaknesses of Digest authentication (see Section 6), 
>
>Section 6 does not talk about the weaknesses of Digest authentication
>(original RFC reference might give you some security considerations;
>I'm not sure if there's any other document that would talk the
>issue).
>  
>

Ok.

>   Due to the weaknesses of Digest authentication (see Section 6),
>   PKI-based authentication and encryption mechanisms have been
>   introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633].  However,
>    
>
>Digest, TLS, and S/MIME are not necessarily in direct
>competition with each other, as they provide slightly different
>services. For instance, TLS is hbh, and Digest gives you
>freshness which S/MIME does not. Plus all three protect
>different parts of the SIP message.
>  
>
>Suggestion: soften the above statement a bit.
>  
>
Ok (but a nit: s/The majority of today's SIP clients only supports HTTP 
digest./
The majority of today's SIP clients only support HTTP digest, however./
(I think Bernard caught this already so this is not a reason to keep my
issue alive.)

>   SIP service providers whishing to authenticate their clients have the
>   following options: they can
>   o  build a PKI and wait for interopable S/MIME capable SIP
>      implementations,
>   o  build a PKI and wait for SIP implementations supporting TLS with
>      client-side certificates,
>   o  replace their existing RADIUS infrastructure with DIAMETER
>      [RFC3588], when DIAMETER supports HTTP Digest authentication,
>   o  use TLS for server authentication and plaintext passwords (Basic)
>      for client authentication, which can be done with standard RADIUS,
>   o  upgrade their existing RADIUS servers with the functionality
>      described in this document
>
>
>      
>
>   PKI solutions only cover authentication, not authorization (EAP could
>   change this, but its use with SIP is not standardized).  TLS / Basic
>   authentication works only with the limited number of SIP devices that
>   implement TLS.  Basic authentication has been deprecated for SIP in
>   [RFC3261].
>    
>
>Somehow the above arguments feel a bit out of place here. Just
>state that Digest is widely used in SIP, and leave it at that :-)
>  
>
Ok.

>   PKI solutions only cover authentication, not authorization (EAP could
>   change this, but its use with SIP is not standardized).  TLS / Basic
>   authentication works only with the limited number of SIP devices that
>   implement TLS.  Basic authentication has been deprecated for SIP in
>   [RFC3261].
>
>
>      
>
>   Current RADIUS-based AAA infrastructures have been built and debugged
>   over years.  Deficiencies of RADIUS have been mitigated with
>   proprietary (ie costly) extensions.  Operators are therefore
>   reluctant to replace their RADIUS infrastructure in order to enable a
>   single new authentication mechanism.
>    
>
>Same as above. And I'm not sure all deficiences have been
>mitigated.
>  
>
Ok.

>   DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
>   DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
>   DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
>   will be assigned by IANA, if this specification becomes a working
>   group or IESG document.
>    
>
>Here's an idea: I'd prefer the attributes in this and the Diameter
>draft to be constructed with the following rules:
>  
>
>(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
>    and Dig-Authp could all use the same attribute? They all have
>    the same syntax in HTTP (param=value).
>  
>
>(2) If both RADIUS and Diameter are going to define the attributes,
>    IMHO it would make sense to allocate them from the RADIUS space
>    so a conversion box would not have to map attributes.
>  
>
>    Alternative idea: use some of the extended RADIUS attribute
>    format ideas and allocate the numbers from the Diameter space.
>  
>
>(3) Use exactly the set of attributes for the pure digest function
>    (I did not check if this is already the case).
>  
>
Ok, this is mostly as I wanted it to be in the Radius document.
However, I wonder if the current Diameter document should
use individual AVPs instead of Grouped AVP:

      SIP-Authenticate ::= < AVP Header: xx12 >
                           { Digest-Realm }
                           { Digest-Nonce }
                           [ Digest-Domain ]
                           [ Digest-Opaque ]
                           [ Digest-Stale ]
                           [ Digest-Algorithm ]
                           [ Digest-QoP ]
                           [ Digest-HA1]
                         * [ Digest-Auth-Param ]
                         * [ AVP ]

Because translating this grouped AVP appears to require
additional work from a gateway, no? Bernard/Miguel, can
you file on issue to the Diameter document on this.

>   	    +-----+    (1)    +-----+           +-----+
>   	    |     |==========>|     |    (2)    |     |
>   	    |     |           |     |---------->|     |
>   	    |     |           |     |    (3)    |     |
>   	    |     |    (4)    |     |<----------|     |
>   	    |     |<==========|     |           |     |
>   	    |     |    (5)    |     |           |     |
>   	    |     |==========>|     |           |     |
>   	    |  A  |           |  B  |    (6)    |  C  |
>   	    |     |           |     |---------->|     |
>   	    |     |           |     |    (7)    |     |
>   	    |     |           |     |<----------|     |
>   	    |     |    (8)    |     |           |     |
>   	    |     |<==========|     |           |     |
>   	    +-----+           +-----+           +-----+
>    
>
>The choice between the server and client generated
>nonces: is there some guidance on how the client knows
>which one to do? if it believes it may have a user that
>does Digest AKA then it should do use the server generated
>scheme? But how would it know this in a roaming case?
>  
>
>Other ideas?
>

This has been raised by Bernard too, apparently we
didn't do good enough job to fix it.

Conclusion: close issue 11. Bernard's roaming issue
still needs to be kept alive, and I'm suggesting one
new issue on the Diameter SIP document.

--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, 24 Mar 2005 14:31:51 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, o verview section
Date: Thu, 24 Mar 2005 15:31:40 +0100

> > Wolfgang wrote:
> > [mapping of HTTP Authentication parameters into RADIUS attributes]
> > We are still in an Overview Section here, so I think that being vague 
> > doesn't hurt too much.
> 
> Bernard wrote:
> I found myself trying to get more details early on.  Much of 
> the material in Section 3 seems to be at the right level so 
> some of it (a few paragraphs) could be moved up.

Can you agree with exchanging Section 2 (attributes) and
Section 3 (Detailed Description)? Then, you get the details
before jumping into the attributes, but the Overview Section
would not be laden with details.

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, 24 Mar 2005 14:26:36 +0000
Date: Thu, 24 Mar 2005 16:25:54 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Issue] Review of draft-ietf-radext-digest-auth-01.tx t, Diameter dependency

I agree with most of the comments that you Bernard made
in the original review, module the responses that Wolfgang
sent, which also seemed reasonable.

Re: nonce generation incompatibility. First, I agree that
Diameter SIP should be extended to cover client-generated
nonce support. I presume that's possible. If not we need to
know now, because then a change in the RADIUS SIP would
be more appropriate.

Re: making nonces work in roaming setting. Yes, this is
an issue. One way of fixing it is making it possible for
a AAA client go start a process such that the AAA server
comes back and says "I let you do the nonces". This would
be the default, and you would skip this useless roundtrip if
and only if you know for a fact that you are running completely
in an environment that doesn't need server generated nonces.
(Another approach would be cut away the client generated mode
and always do two roundtrips. We can't remove server
mode because some algorithms depend on it.)

Re: location of the compatibility section. I think the two
drafts simply have to progress in lock step. This is obvious
from the nonce discussion, imho. I'd prefer
the compatibility section to be where it is currently.

--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: Wed, 23 Mar 2005 12:54:49 +0000
Date: Wed, 23 Mar 2005 04:54:29 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: AW: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.tx t, Diameter dependency

> I don't think it is a big problem. If you have a RADIUS client and
> Diamter server, configure the RADIUS client to obtain the nonces
> from the server. If you have a Diameter client and a RADIUS server,
> configure your server to provide nonces.

In practice, this won't work because Diameter and RADIUS are inter-domain
protocols.  If a SIP proxy *somewhere* in the system is generating nonces,
it may not be possible to force it to reconfigure.

--
to unsubscribe send 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, 23 Mar 2005 12:52:17 +0000
Date: Wed, 23 Mar 2005 04:51:39 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Miguel Garcia <[email-masked]>
cc: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: Re: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, Diameter dependency

> I am more worried about Wolfgang's concerns about "Diameter SIP document
> is likely to be blocked based on the lack of compatibility with RADIUS
> Digest". Can someone expand these concerns, because we should addressed
> them. I thought that we have limited compatibility just restricted by
> the smaller scope of the RADIUS draft.

It is ok for Diameter SIP to be a *superset* of the RADIUS Digest
document.  It is not ok for Diameter SIP to be unable to translate AVPs or
modes of operation that occur within RADIUS Digest.

>From reading the RADIUS Digest Diameter compatibility section, it would
appear that Diameter SIP cannot handle a situation where the RADIUS client
generates nonces.  If so, this would mean that Diameter SIP is a *subset*
of RADIUS Digest functionality.

--
to unsubscribe send 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, 23 Mar 2005 09:22:14 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: AW: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.tx t, Diameter dependency
Date: Wed, 23 Mar 2005 10:21:28 +0100

> I am more worried about Wolfgang's concerns about "Diameter SIP document 
> is likely to be blocked based on the lack of compatibility with RADIUS 
> Digest". Can someone expand these concerns, because we should addressed 
> them. I thought that we have limited compatibility just restricted by 
> the smaller scope of the RADIUS draft.
Sorry, my quoting was misleading. It is Bernard who is concerned about the
Diameter draft lacking nonce generation at the Diameter client. 

I don't think it is a big problem. If you have a RADIUS client and
Diamter server, configure the RADIUS client to obtain the nonces
from the server. If you have a Diameter client and a RADIUS server,
configure your server to provide nonces.

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, 23 Mar 2005 08:47:07 +0000
Date: Wed, 23 Mar 2005 10:25:10 +0200
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, Diameter dependency

Folks:

Diameter SIP app already has a normative dependency on the RADIUS Digest 
draft (remember the imported Digest-* attributes).

So I don't see a problem in adding or moving that text to the Diameter 
draft.

I am more worried about Wolfgang's concerns about "Diameter SIP document 
is likely to be blocked based on the lack of compatibility with RADIUS 
Digest". Can someone expand these concerns, because we should addressed 
them. I thought that we have limited compatibility just restricted by 
the smaller scope of the RADIUS draft.

/Miguel

Beck01, Wolfgang wrote:

> I think Miguel should be included into the discussion.
> 
>>>[Migration Path to Diameter]
>>>We had some discussion about this. If we move it to 
>>>Diameter, Miguel Garcia suffers from the dependency. Someone has to bear it. Both 
>>>documents have finished WGLC in parallel.
>>
>>I agree that one of the drafts does need this section.  
>>However, the RADIUS Digest authentication is on a tight time 
>>schedule and I am concerned about delays that could result 
>>from keeping this section in it, particularly since the 
>>Diameter SIP document is likely to be blocked based on the 
>>lack of compatibility with RADIUS Digest.  So my advice is to 
>>move it to the Diameter SIP document.
>>
> 
> 
> 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
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, 23 Mar 2005 07:58:29 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, D iameter dependency
Date: Wed, 23 Mar 2005 08:57:52 +0100

I think Miguel should be included into the discussion.
> > [Migration Path to Diameter]
> > We had some discussion about this. If we move it to 
> > Diameter, Miguel Garcia suffers from the dependency. Someone has to bear it. Both 
> > documents have finished WGLC in parallel.
> 
> I agree that one of the drafts does need this section.  
> However, the RADIUS Digest authentication is on a tight time 
> schedule and I am concerned about delays that could result 
> from keeping this section in it, particularly since the 
> Diameter SIP document is likely to be blocked based on the 
> lack of compatibility with RADIUS Digest.  So my advice is to 
> move it to the Diameter SIP document.
> 

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, 22 Mar 2005 18:42:32 +0000
Date: Tue, 22 Mar 2005 10:41:56 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt

> [Migration Path to Diameter]
> We had some discussion about this. If we move it to Diameter, Miguel Garcia
> suffers from the dependency. Someone has to bear it. Both documents have
> finished WGLC in parallel.

I agree that one of the drafts does need this section.  However, the
RADIUS Digest authentication is on a tight time schedule and I am
concerned about delays that could result from keeping this section in it,
particularly since the Diameter SIP document is likely to be blocked
based on the lack of compatibility with RADIUS Digest.  So my advice is to
move it to the Diameter SIP document.

> Proposal:
> "This document defines an extension to the RADIUS protocol to enable
> support of Digest authentication, for use with HTTP-style protocols like
> SIP and HTTP."

Fine.

> [mapping of HTTP Authentication parameters into RADIUS attributes]
> We are still in an Overview Section here, so I think that being vague
> doesn't hurt too much.

I found myself trying to get more details early on.  Much of the material
in Section 3 seems to be at the right level so some of it (a few
paragraphs) could be moved up.

> [mix of nonce generation modes]
> It's a matter of RADIUS client configuration. The client has to be configured
> anyway, as not all RADIUS servers will support this extension. If a RADIUS
> client generates a nonce locally and sends an Access-Request to a server
> that wants to generate nonces itself, this will result in an Access-Reject
> (the server does not recognize the nonce). If a RADIUS client demands a nonce
> from a RADIUS server that is not able to generate nonces, this will result
> in an Access-Reject, too.

Can you say this in the document?

> [format of attribute descriptions]
> Somebody on the list complained about that the repeated
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |   Text..
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> boxes are redundant as none of the attributes is structured.

The issue is that the typing appears to be wrong in several places.

> [Interpretation of Access-Request messages containing a Digest-Response attribute]
> If the RADIUS server discovers a CHAP-Password attribute, it uses CHAP authentication.
> If the RADIUS server discovers Digest-Response, it uses Digest authentication.

What confused me is that you used SHOULD instead of MUST about this.  Is there a
situation where Digest attributes are present where CHAP should be used instead?

> [SHOULD in Digest-Qop section]
> RfC 2617 uses SHOULD, too. If the Digest-Qop is not present, the
> HTTP response will not contain a qop= parameter.

You might add a few words to this effect.

> [SHOULD in Digest-Algorithm section]
> RfC 2617 defines the algorithm parameter as optional. If it
> is missing, MD5 is assumed.

Can you mention this?

> [Digest-Entity-Body-Hash with other algorithms]
> The attribute can be re-used as the Digest-Algorithm indicates
> the digest algorithm to use.

Can you mention this?

> [Digest-Auth-Param in Access-Reject]
> This was meant for extensibility but I don't know of a concrete use
> case. I'll restrict it to Access-Request, Access-Challenge, and
> Access-Accept.

Thanks.

> [RADIUS client behaviour, about moving parts of the description to the Overview section]
> I am not sure if it is possible to explain the process without describing
> each step. As an implementor, I would not like to flip back and forth.
>
> The idea was to give a step-by-step instruction.

Usually the step-by-step occurs *prior* to the attribute definition, not after.

> [Limitations of RADIUS/Diameter interopability]
> The Diameter draft was a result of 3GPP requirements and did not care
> about the early sterman draft. We can't fix this limitation in RADEXT.

I realize that -- but the result is that Diameter and RADIUS won't
interoperate and this is a major problem.  That's why the Diameter/RADIUS
gateway material needs to move to the Diameter SIP document, to keep the
debate from delaying this document.

> [Table of attributes]
> When doing the table, I was copying from some other RADIUS draft. I don't
> think a table is the best way to show complex relationships, like
> "if attribute x is present, attribute y is mandatory".

Nevertheless that is what previous RADIUS RFCs have done using notes.  As
it is, one has to search throughout the document to find this material.

> [Security Considerations, attacker gets access]
> -> attacker gains control of the RADIUS client or RADIUS proxy.

Can you clarify?

> [Security Considerations, RADIUS connection]
> Right, it's not a layer 4 connection. Is 'flow' a better term?

I'd try "transaction".

--
to unsubscribe send 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, 22 Mar 2005 17:27:35 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt
Date: Tue, 22 Mar 2005 18:26:59 +0100

> Here is my review of the document: 
> http://www.drizzle.com/~aboba/RADEXT/dig-rev-01.txt
> 
Thanks Bernard.

[Abstract]
Your proposal:
"The HTTP Digest authentication mechanism, defined in RFC 2617, has also been
adapted to use with SIP, as defined in RFC 3261."
The draft was motivated by SIP, but SIP is only a minor aspect.

Proposal:
"This document specifies an extension to the Remote Authentication
Dial In User Service (RADIUS) to enable support of Digest Authentication
as defined in RfC 2617."

[Migration Path to Diameter]
We had some discussion about this. If we move it to Diameter, Miguel Garcia
suffers from the dependency. Someone has to bear it. Both documents have
finished WGLC in parallel.

[boilerplate sections in TOC]
I'll try to convince xml2rfc to do that.

[HTTP Digest introduction]
Your proposal is lacking the motivation for the use of RADIUS.
"This document defines an extension to the RADIUS protocol to enable 
support of Digest authentication, for use with both SIP and HTTP."
This seems a bit too narrow, as there are people evaluating to use
HTTP digest for other HTTP-style protocols, like MSRP or RTSP.
Proposal:
"This document defines an extension to the RADIUS protocol to enable 
support of Digest authentication, for use with HTTP-style protocols like 
SIP and HTTP."

[Figure 1]
Somebody found figure 2 too detailed and demanded a simpler picture,
like the current figure 1. Your proposed figure seems to be a good
compromise.

[mapping of HTTP Authentication parameters into RADIUS attributes]
We are still in an Overview Section here, so I think that being vague
doesn't hurt too much.

[mix of nonce generation modes]
It's a matter of RADIUS client configuration. The client has to be configured
anyway, as not all RADIUS servers will support this extension. If a RADIUS
client generates a nonce locally and sends an Access-Request to a server
that wants to generate nonces itself, this will result in an Access-Reject
(the server does not recognize the nonce). If a RADIUS client demands a nonce
from a RADIUS server that is not able to generate nonces, this will result
in an Access-Reject, too.

[format of attribute descriptions]
Somebody on the list complained about that the repeated
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   Text..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
boxes are redundant as none of the attributes is structured.

[Interpretation of Access-Request messages containing a Digest-Response attribute]
If the RADIUS server discovers a CHAP-Password attribute, it uses CHAP authentication.
If the RADIUS server discovers Digest-Response, it uses Digest authentication.

[Length of Digest-Response]
Miguel Garcia pointed out that different digest algorithms might use
different response lengths.

[SHOULD in Digest-Qop section]
RfC 2617 uses SHOULD, too. If the Digest-Qop is not present, the
HTTP response will not contain a qop= parameter.

[SHOULD in Digest-Algorithm section]
RfC 2617 defines the algorithm parameter as optional. If it
is missing, MD5 is assumed.

[Digest-Entity-Body-Hash with other algorithms]
The attribute can be re-used as the Digest-Algorithm indicates
the digest algorithm to use.

[Digest-Auth-Param in Access-Reject]
This wa meant for extensibility but I don't know of a concrete use case.
I'll restrict it to Access-Request, Access-Challenge, and Access-Accept.

[RADIUS client behaviour, about moving parts of the description to the Overview section]
I am not sure if it is possible to explain the process without describing
each step. As an implementor, I would not like to flip back and forth.

The idea was to give a step-by-step instruction.

[RADIUS client behaviour, acceptance of https/sips]
I'll add a reference to the Security Considerations section.
Explaining it here will add too much detail to a text which
is already quite detailed.

[Limitations of RADIUS/Diameter interopability]
The Diameter draft was a result of 3GPP requirements and did not care
about the early sterman draft. We can't fix this limitation in RADEXT.

[Table of attributes]
When doing the table, I was copying from some other RADIUS draft. I don't
think a table is the best way to show complex relationships, like
"if attribute x is present, attribute y is mandatory".

[Security Considerations, attacker gets access]
-> attacker gains control of the RADIUS client or RADIUS proxy.

[Security Considerations, performance requirements]
This sentence emphasizes the consequences of the previous one.

[Security Considerations, comparison with layer 2 access RADIUS]
The layer 2 access controlled by NASes is a much more constrained
environment than the open Internet which is the 'access network'
of a HTTP- or SIP proxy.

[Security Considerations, Message-Authenticator]
I did not include Message-Authenticator (and User-Name) in the table,
as they are defined elsewhere. I'll fix that.

[Security Considerations, RADIUS connection]
Right, it's not a layer 4 connection. Is 'flow' a better term?

(I did not include comments where I agree with you)

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, 22 Mar 2005 06:57:08 +0000
Date: Mon, 21 Mar 2005 22:56:55 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz 

>   It's not clear to me.  The text is ambiguous, and I could interpret
> it in many ways, but the examples in 2.3.4 show "client disconnected"
> as a result of RADIUS Access-Reject.

Thanks for the reference.

>    If EAP is negotiated but is not supported by the RADIUS proxy or
>    server, then the server or proxy MUST respond with an Access-Reject.
>    In these cases, the NAS MUST send an LCP-Terminate and disconnect the
>    user.

Well, I guess they really do mean "disconnect" in the case of PPP.

>   While I'm not familiar with the details of 802.11i, I'm not sure
> what it means to be in an "authenticated" state after the session was
> rejected.  Maybe this is just a terminology difference between 802.11i
> and RADIUS.

It's an artifact of the 802.11 state machine, which in 802.11-2003
includes a link layer "authentication" frame that is not used by 802.1X
(or at least 802.1X operates after "open" authentication).  The bottom
line is that the STA is still Associated after failing 802.1X
authentication and can attempt 802.1X authentication again.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 22 Mar 2005 06:12:12 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz 
Cc: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 22 Mar 2005 01:08:22 -0500
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> In my own review of RFC 2869, it would appear that there is a distinction
> made between "no service" and "disconnection". 

  It's not clear to me.  The text is ambiguous, and I could interpret
it in many ways, but the examples in 2.3.4 show "client disconnected"
as a result of RADIUS Access-Reject.

  I agree it's reasonable to say that "no service" != "disconnection".
My only concern then is to clearly scope what kind of service is
permitted after an Access-Reject, if the client isn't disconnected.
Where the semantics or decisions are ambiguous, a simple client
disconnection makes implementation and security analysis easier.

> In the case of PPP, it therefore seems to me that "Access Reject" really
> means that the user does not get to NCP, not necessarily that an
> LCP-Terminate MUST be sent (although that is typically what happens).

  That's reasonable, which means one more issue to address in RFC
2869, Section 7.2.5 page 43, which says:

   If EAP is negotiated but is not supported by the RADIUS proxy or
   server, then the server or proxy MUST respond with an Access-Reject.
   In these cases, the NAS MUST send an LCP-Terminate and disconnect the
   user.

  In that case, the difference in RADIUS client behaviour between
Access-Reject due to authentication failure, and Access-Reject due to
implementations not supporting the requested authentication becomes
problematic.  Again, if an implementor isn't sure, disconnection is
always a safe bet.

> In 802.1X for example, Access-Reject means that packets cannot be
> forwarded by the switch; it doesn't necessarily mean that all link state
> is torn down.  For example, in 802.11i the STA would still be in State 3
> (Authenticated, Associated) even after 802.1X fails.  However, the 802.1X
> controlled port would not allow packets through.

  While I'm not familiar with the details of 802.11i, I'm not sure
what it means to be in an "authenticated" state after the session was
rejected.  Maybe this is just a terminology difference between 802.11i
and RADIUS.

> So far, attributes in an Access-Reject have only been allowed to inform
> the user that service isn't being provided (Reply-Message,
> EAP-Message/EAP-Failure, etc.) or to control retry behavior.

  I agree.  Though the Password-Retry attribute of RFC 2869 is in a
grey area.  I could see an equivalent design be to use Password-Retry
in Access-Challenge.

  Alan DeKok.

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

Delivery-date: Tue, 22 Mar 2005 06:06:50 +0000
Date: Mon, 21 Mar 2005 22:06:15 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: WGLC draft-ietf-radext-digest-auth-01

> now that the WGLC has ended, what are the next steps? Do I need to
> submit the draft to the IESG now?

The IETF process has a number of steps between completion of WGLC and
publication as an RFC.  These steps include:

a. Addressing WGLC issues.  The Issues list indicates that two issues were
not resolved in DIGEST-01 (Issues 7 and 11).  Plus in addition, there are
4 new issues filed.  See http://www.drizzle.com/~aboba/RADEXT/ for
details.

b. Chair review.  Under the PROTO process, the WG Chairs need to review a
document and verify that it is acceptable before forwarding to the IESG.
For my review, see:
http://www.drizzle.com/~aboba/RADEXT/dig-rev-01.txt

c. AD review.  The Area Director needs to complete a review prior to
consideration by the IESG as a whole.

d. IETF Last Call.  This provides an opportunity for the IETF community to
review and comment on the document.

e. IESG review.  Here the IESG reviews the document.

f. DISCUSS comment resolution.

g. RFC Editor Review.

h. IANA Review.

--
to unsubscribe send 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, 21 Mar 2005 21:25:33 +0000
Date: Mon, 21 Mar 2005 13:25:17 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz

In my own review of RFC 2869, it would appear that there is a distinction
made between "no service" and "disconnection".  In the case of AppleTalk
it appears that the user can reauthenticate after an Access-Reject,
although their AppleTalk packets will not be forwarded.  So they have "no
service" but are not "disconnected".

In the case of PPP, it therefore seems to me that "Access Reject" really
means that the user does not get to NCP, not necessarily that an
LCP-Terminate MUST be sent (although that is typically what happens).

In 802.1X for example, Access-Reject means that packets cannot be
forwarded by the switch; it doesn't necessarily mean that all link state
is torn down.  For example, in 802.11i the STA would still be in State 3
(Authenticated, Associated) even after 802.1X fails.  However, the 802.1X
controlled port would not allow packets through.

So far, attributes in an Access-Reject have only been allowed to inform
the user that service isn't being provided (Reply-Message,
EAP-Message/EAP-Failure, etc.) or to control retry behavior.

On Mon, 21 Mar 2005, Nelson, David wrote:

> > Well, a first step might be for the WG Chairs to express the
> > historic semantics of the Access-Reject message and even, perhaps,
> > the WG consensus regarding it (determining that as necessary).
>
> Bernard may see this differently, but my own observation from the
> discussion to date on the list is that the RADEXT WG does not have a
> clear consensus on the semantics of the Access-Reject message and the
> permissible attributes that may appear therein.
>
> I think, historically speaking, that the RADIUS WG probably *did* have a
> clear consensus on what they thought Access-Reject meant, but that was
> then and this is now.  Access-Reject has classically meant "no service".
> I think that some of the RFCs published between the closing of the
> RADIUS WG and the chartering of the RADEXT WG may have blurred the
> classical semantics of Access-Reject.  There is currently a debate over
> what "service" means, although I hope that "no" still means "no".  :-)
>
> It seems to me that the pertinent question is what the RADEXT WG thinks
> is the correct semantics for Access-Reject for current and future RADIUS
> work.
>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send 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, 21 Mar 2005 21:06:38 +0000
Content-class: urn:content-classes:message
Subject: RE: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz
Date: Mon, 21 Mar 2005 16:06:19 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

> Well, a first step might be for the WG Chairs to express the
> historic semantics of the Access-Reject message and even, perhaps,
> the WG consensus regarding it (determining that as necessary).

Bernard may see this differently, but my own observation from the
discussion to date on the list is that the RADEXT WG does not have a
clear consensus on the semantics of the Access-Reject message and the
permissible attributes that may appear therein.

I think, historically speaking, that the RADIUS WG probably *did* have a
clear consensus on what they thought Access-Reject meant, but that was
then and this is now.  Access-Reject has classically meant "no service".
I think that some of the RFCs published between the closing of the
RADIUS WG and the chartering of the RADEXT WG may have blurred the
classical semantics of Access-Reject.  There is currently a debate over
what "service" means, although I hope that "no" still means "no".  :-)

It seems to me that the pertinent question is what the RADEXT WG thinks
is the correct semantics for Access-Reject for current and future RADIUS
work.

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

Envelope-to: [email-masked]
Delivery-date: Mon, 21 Mar 2005 20:51:30 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz 
Cc: "Glen Zorn (gwz)" <[email-masked]>, [email-masked], "'MORAND Lionel RD-CORE-ISS'" <[email-masked]>
Date: Mon, 21 Mar 2005 15:47:42 -0500
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> > FYI, more "Access-Reject doesn't _really_ mean Access-Reject"
> > nonsense, this time (perhaps predictably) from the PANA WG.  I
> > particularly like case #2, where L2 access is denied but IP access
> > is magically provided (avian transport, maybe?).  We _really_ need
> > to do something about this...
> 
> Care to make a proposal about what that "something" might be?

  A new issue submitted for RFC 2869, which is a related topic.

http://ops.ietf.org/lists/radiusext/2005/msg00256.html

  And:

http://www.drizzle.com/~aboba/RADEXT/#Issue%2068

  also addresses the semantics of using Access-Reject outside of the
scope of PPP, and how it should be interpreted.

  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: Mon, 21 Mar 2005 20:49:16 +0000
Date: Mon, 21 Mar 2005 12:49:00 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [Issue] Review of draft-ietf-radext-digest-auth-01.txt

Here is my review of the document:
http://www.drizzle.com/~aboba/RADEXT/dig-rev-01.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: Mon, 21 Mar 2005 20:22:38 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, "'MORAND Lionel RD-CORE-ISS'" <[email-masked]>
Subject: RE: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz
Date: Mon, 21 Mar 2005 12:22:15 -0800

Bernard Aboba <> supposedly scribbled:

> On Mon, 21 Mar 2005, Glen Zorn (gwz) wrote:
> 
>> FYI, more "Access-Reject doesn't _really_ mean Access-Reject"
>> nonsense, this time (perhaps predictably) from the PANA WG.  I
>> particularly like case #2, where L2 access is denied but IP
access is
>> magically provided (avian transport, maybe?).  We _really_ need
to do
>> something about this...
> 
> Care to make a proposal about what that "something" might be?

Well, a first step might be for the WG Chairs to express the
historic semantics of the Access-Reject message and even, perhaps,
the WG consensus regarding it (determining that as necessary).

> 
> FYI, the RADIUS Digest Authentication draft also includes
attributes
> in the Access-Reject. 

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, 21 Mar 2005 19:49:09 +0000
Date: Mon, 21 Mar 2005 11:48:51 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: [email-masked], "'MORAND Lionel RD-CORE-ISS'" <[email-masked]>
Subject: Re: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz

On Mon, 21 Mar 2005, Glen Zorn (gwz) wrote:

> FYI, more "Access-Reject doesn't _really_ mean Access-Reject"
> nonsense, this time (perhaps predictably) from the PANA WG.  I
> particularly like case #2, where L2 access is denied but IP access
> is magically provided (avian transport, maybe?).  We _really_ need
> to do something about this...

Care to make a proposal about what that "something" might be?

FYI, the RADIUS Digest Authentication draft also includes attributes in
the 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: Mon, 21 Mar 2005 19:05:46 +0000
Content-class: urn:content-classes:message
Subject: RE: [Pana] RADIUS Access-Reject and NAP/ISP authz
Date: Mon, 21 Mar 2005 14:05:08 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Glen Zorn writes...

> We _really_ need to do something about this...

The two vehicles within RADEXT to "do something" would be the RADIUS
Issues and Fixes I-D, addressing past confusion, errors and poor
interoperability, and the RADIUS Design Guidelines I-D, which will serve
to guide future RADIUS work.  I have agreed to (initially) serve as
Editor for the RADIUS Issues and Fixes document, and Greg Weber has
agreed to serve as Editor for the RADIUS Design Guidelines document.

Submissions on this subject (and others), for both documents, are
welcomed and encouraged.  Glen, would you like to contribute some text?

--
to unsubscribe send 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, 21 Mar 2005 17:54:44 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: "'MORAND Lionel RD-CORE-ISS'" <[email-masked]>
Subject: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz
Date: Mon, 21 Mar 2005 09:52:13 -0800

FYI, more "Access-Reject doesn't _really_ mean Access-Reject"
nonsense, this time (perhaps predictably) from the PANA WG.  I
particularly like case #2, where L2 access is denied but IP access
is magically provided (avian transport, maybe?).  We _really_ need
to do something about this...

MORAND Lionel RD-CORE-ISS <> supposedly scribbled:

> Hi Alper,
>=20
> I think that we should carefully consider the case of NAP/ISP
> separate authentications.=20
> The idea is to allow two different administrative domains (the
local
> access network and the distant ISP) to authenticate the PaC, based
on
> distinct credentials. The NAP authentication may be required to
> provide L1/L2 access and related local services. The ISP
> authentication is required to provide IP access services.   =20
> Both authentications are based on an end2end EAP dialogues between
> the PaC and the appropriate AAA server (i.e. NAP AAA server or ISP
> AAA server), over PANA and the back-end AAA protocol (RADIUS or
> Diameter).  =20
> As a consequence, the PAA will have two distinct dialogues with
both
> AAA servers. The outcome of a given dialogue (authentication
success
> or failure) should not have to impact the dialogue with the other
> one.  =20
>=20
> Therefore, in the RADIUS case, depending of the local NAP
policies:
>=20
> 1/ If the ISP authentication failed, the PAA may either:
> - Send an Accounting-Start message the NAP AAA server only,
> indicating that a L1/L2 access is provided to the PaC.=20
> - Deny the network access
>=20
> 2/ If the NAP authentication failed, the PAA may either:
> - Send an Accounting-Start message to the ISP AAA server only,
> indicating that the PaC is provided with IP access.=20
> - Deny the network access
>=20
> 3/ If both authentications succeded, an Accounting-Start message
will
> be sent to each AAA server.=20
>=20
> I don't see any problem with this approach. I don't see why an
> Accounting-request would be sent to an AAA server that would have
> rejected the PaC. =20
>=20
> By the way, on the following issue raised by Avi:
>=20
> "There seems to be a conflict between RFC3579 and PANA when
multiple
> authentication is used.=20
>=20
>    This is what RFC 3579 says:
>=20
>    The conversation continues until either a RADIUS Access-Reject
or
>    Access-Accept packet is received from the RADIUS server.
Reception
>    of a RADIUS Access-Reject packet MUST result in the NAS denying
>    access to the authenticating peer.  A RADIUS Access-Accept
packet
>    successfully ends the authentication phase.  The NAS MUST NOT
>    "manufacture" a Success or Failure packet as the result of a
>    timeout. After a suitable number of timeouts have elapsed, the
NAS
>    SHOULD instead end the EAP conversation.
>=20
>    This is clearly against the PANA specification.  Which allows
one
>    AAA authentication to fail and the other to succeed."
>=20
> I think that this actually a non-issue. We could consider that the
> access is authorized due to the reception of "at least" one
> Access-Accept. As I read the RFC 3579, I understand that within a
> RADIUS dialogue, the NAS must not open the door after the
reception
> of an Access-Reject. It's fine and correct for me. But it does not
> preclude to open it based on the reception of a Access-Accept
within
> another dialogue. And the case of multi-authentication was not
> covered by the RFC 3579.      =20
>=20
> BR,
>=20
> Lionel
>=20
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la
part
>> de Alper Yegin Envoy=E9 : vendredi 18 mars 2005 22:37 =C0 :
>> [email-masked] Cc : 'Avi Lior' Objet : [Pana] RADIUS Access-Reject
>> and NAP/ISP authz=20
>>=20
>>=20
>>=20
>> Issue as discovered in draft-lior-pana-radius-00.txt:
>>=20
>> When NAP/ISP separate auth is being carried out, even if one
>> of the auths has failed, PANA session may still "succeed"
>> (based on local policy decision). In that case, sending a
>> RADIUS Accounting Start to the AAA server that had Rejected
>> the client would confuse that server.
>>=20
>> I think the above issue is valid based on the current PANA
>> specification.=20
>>=20
>> IMO, what we failed to explicitly capture in the base
>> specification is, for PANA session to succeed, minimally the
>> ISP authentication must succeed. After all, it is the "ISP"
>> that provides the "IP access service." The NAP authentication
>> is in the picture just to let PaC access differentiated
>> (e.g., gold, silver, bronze) "L1/L2" services if it has a
>> separate account with the NAP. Otherwise, a NAP account by
>> itself is not sufficient get Internet connectivity.
>>=20
>> And, a AAA server that hasn't authorized the requested
>> service must not receive an accounting start message. If ISP
>> auth has succeeded, PaC's IP access is authorized, and ISP's
>> AAA server gets notified. If ISP auth failed, all bets are
>> off. If ISP auth succeeded, and NAP failed, IP access is
>> granted but PaC does not get any differentiated service from
>> the NAP (L1/L2); only ISP's AAA server receives the
>> accounting start message.
>>=20
>> Makes sense?
>>=20
>> Alper
>>=20
>>=20
>>=20
>> _______________________________________________
>> Pana mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pana
>>=20
>=20
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Fri, 18 Mar 2005 00:05:44 +0000
content-class: urn:content-classes:message
Subject: Issue: realm validation in draft-ietf-radext-digest-auth
Date: Thu, 17 Mar 2005 16:08:17 -0800
From: "Salowey, Joe" <[email-masked]>
To: <[email-masked]>

Realm validation
Submitter name: Joe Salowey=09
Submitter email address: [email-masked]=20
Date first submitted: 3/17/2005
Reference:=20
Document: Digest
Comment type: Technical
Priority: '1' Should fix
Section: 3.2 and 8 (security considerations)=20
Rationale/Explanation of issue:

Is it allowed for a RADIUS server to support more than one realm?  If it
is then it seems that the RADIUS server should validate that the RADIUS
client is authorized to act in the realm of the request.  This is
especially true when returning a Digest-HA1 attribute. If it doesn't
then it seems that a compromised RADIUS client may have a route to
compromise other realms or impersonate a realm.  The same may also be
true of the digest URI if it is involved in the server calculations, but
this may not be as meaningful to the server. =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, 15 Mar 2005 22:33:04 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Carroll, Christopher P.'" <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, "'Frank Quick'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Tue, 15 Mar 2005 14:16:38 -0800

Carroll, Christopher P. <mailto:[email-masked]>
supposedly scribbled:

> Hi Glen,
> 
> I find your request somewhat extreme.  

It wasn't really a serious request, more an observation.  The
document misuses RADIUS in the worst way (whether through ignorance
or arrogance is of little consequence) & to state that the document
in question shouldn't be used as a model is the weakest possible
statement.

> However, I would like to
> believe that your opinions are not influenced by Cisco's Mobile IP
> key distribution product entitled " "Mobile IP Dynamic Security
> Association and Key Distribution" which is interestingly similar
in
> title and purpose to the present draft. 

I'm unfamiliar with that product (document? draft? Can you supply a
reference?) but you may rest assured that if it similar in technique
to yours my criticism would be just as vehement.
 
> 
> Regards,
> 
> chris
> 
> 
>> -----Original Message-----
>> From: Glen Zorn (gwz) [mailto:[email-masked]]
>> Sent: Monday, March 14, 2005 2:20 PM
>> To: 'Avi Lior'; 'Nelson, David'; 'Frank Quick'; 'Alan DeKok'; 'W.
>> Mark Townsley' Cc: 'Jari Arkko'; 'Barney Wolff'; 'Thomas Narten';
>> Carroll, Christopher P.; [email-masked];
>> [email-masked] 
>> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
>> 
>> Avi Lior <> supposedly scribbled:
>> 
>> _This document is practically a textbook example of how _not_ to
use
>> RADIUS.  Can the note say that?
>> 
>>> I support David's approach.
>>> 
>>>> -----Original Message-----
>>>> From: Nelson, David [mailto:[email-masked]]
>>>> Sent: Monday, March 14, 2005 1:32 PM
>>>> To: Frank Quick; Alan DeKok; Avi Lior; W. Mark Townsley
>>>> Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll,
Christopher
>>>> P.; [email-masked]; [email-masked]
>>>> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
>>>> 
>>>> 
>>>> Frank Quick writes...
>>>> 
>>>>> This sounds very reasonable, but I think it actually goes
beyond
>>>>> the context of this draft.  I believe there is no clear
statement
>>>>> of this policy that the draft can reference, and it is not a
good
>>>>> idea for a draft of this nature to create new policy.  For
this
>>>>> draft maybe it is enough that we state that RFC 2865 forbids
VSA
>>>>> in Access-Reject, and that future work should consider using
>>>>> Access-Challenge instead.  That would avoid having to discuss
the
>>>>> semantics issue in the draft.
>>>> 
>>>> It is apparent that there is some disagreement within the
RADIUS
>>>> community within IETF about the usage of Access-Reject.  The
areas
>>>> of disagreement cover whether Access-Reject implies link-layer
>>>> disconnect and when Access-Reject or Access-Challenge is
>>>> appropriate (or permissible).  In RADEXT, we have added this
set
>>>> of issues to be considered in our RADIUS Issues and Fixes I-D.

>>>> Given this lack of clear consensus, it might be advisable to
craft
>>>> an IESG note along the lines that Frank describes.  Future RFCs
>>>> may provide more definitive guidance in this area.
Understanding
>>>> that, it is appropriate to discourage new work using *this*
>>>> document as a precedent.
>> 

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Tue, 15 Mar 2005 21:47:17 +0000
content-class: urn:content-classes:message
Subject: Interoperability between RADIUS Digest Auth and SASL Digest Auth
Date: Tue, 15 Mar 2005 13:41:19 -0800
From: "Salowey, Joe" <[email-masked]>
To: "SASL WG" <[email-masked]>, <[email-masked]>

At first glance it appears the RADIUS digest auth
(draft-ietf-radext-digest-auth-01.txt) should interoperate with SASL
Digest auth (draft-ietf-sasl-rfc2831bis-04.txt). =20

Can anyone verify if this is true?

Thanks,

Joe

--
to unsubscribe send 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, 15 Mar 2005 16:28:17 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: remaining issues of draft-ietf-radext-digest-auth
Date: Tue, 15 Mar 2005 17:28:01 +0100

During the meeting, Lionel Morand raised the question what parts
of the SIP URI should be put into a SIP-AOR attribute. We
(Lionel, Miguel Garcia, and I) had a discussion afterwards.
The conclusion was, that it is reasonable to include fetch
the entire SIP URI. To make this more obvious, I propose the
following text:

"The SIP-AOR attribute holds the complete URI, including
parameters and other parts. It is up to the RADIUS server
what components of the URI are regarded in the authorization
decision."

Jari: I think issue 11 is resolved in
http://bgp.potaroo.net/ietf/ids/draft-ietf-radext-digest-auth-01.txt.
Can you check this?

Wolfgang

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

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

Delivery-date: Tue, 15 Mar 2005 15:41:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Date: Tue, 15 Mar 2005 10:40:09 -0500
From: "Nelson, David" <[email-masked]>
To: "Frank Quick" <[email-masked]>, "Alan DeKok" <[email-masked]>, "Avi Lior" <[email-masked]>, "Margaret Wasserman" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>, "Barney Wolff" <[email-masked]>, "Thomas Narten" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, <[email-masked]>, <[email-masked]>

Please include Margaret Wasserman, the current Shepherding AD, on all
future discussion of this 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/>

Envelope-to: [email-masked]
Delivery-date: Mon, 14 Mar 2005 20:01:39 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Cc: "Jari Arkko" <[email-masked]>, "Barney Wolff" <[email-masked]>, "Thomas Narten" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 14 Mar 2005 14:57:17 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Given this lack of clear consensus, it might be advisable to craft
> an IESG note along the lines that Frank describes.

  I agree that would close the issue for this draft.  Frank's
one-sentence summary is good.

  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: Mon, 14 Mar 2005 19:25:47 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, "'Frank Quick'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>
Cc: "'Jari Arkko'" <[email-masked]>, "'Barney Wolff'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>, "'Carroll, Christopher P.'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Mon, 14 Mar 2005 11:19:43 -0800

Avi Lior <> supposedly scribbled:

_This document is practically a textbook example of how _not_ to use
RADIUS.  Can the note say that?

> I support David's approach.
> 
>> -----Original Message-----
>> From: Nelson, David [mailto:[email-masked]]
>> Sent: Monday, March 14, 2005 1:32 PM
>> To: Frank Quick; Alan DeKok; Avi Lior; W. Mark Townsley
>> Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, Christopher
P.;
>> [email-masked]; [email-masked]
>> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
>> 
>> 
>> Frank Quick writes...
>> 
>>> This sounds very reasonable, but I think it actually goes beyond
the
>>> context of this draft.  I believe there is no clear statement of
>>> this policy that the draft can reference, and it is not a good
idea
>>> for a draft of this nature to create new policy.  For this draft
>>> maybe it is enough that we state that RFC 2865 forbids VSA in
>>> Access-Reject, and that future work should consider using
>>> Access-Challenge instead.  That would avoid having to discuss
the
>>> semantics issue in the draft. 
>> 
>> It is apparent that there is some disagreement within the RADIUS
>> community within IETF about the usage of Access-Reject.  The
areas of
>> disagreement cover whether Access-Reject implies link-layer
>> disconnect and when Access-Reject or Access-Challenge is
appropriate
>> (or permissible).  In RADEXT, we have added this set of issues to
be
>> considered in our RADIUS Issues and Fixes I-D.   Given this lack
of
>> clear consensus, it might be advisable to craft an IESG note
along
>> the lines that Frank describes.  Future RFCs may provide more
>> definitive guidance in this area.  Understanding that, it is
>> appropriate to discourage new work using *this* document as a
>> precedent. 

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, 14 Mar 2005 18:48:10 +0000
From: Avi Lior <[email-masked]>
To: "Nelson, David" <[email-masked]>, Frank Quick <[email-masked]>, Alan DeKok <[email-masked]>, Avi Lior <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Cc: Jari Arkko <[email-masked]>, Barney Wolff <[email-masked]>,  Thomas Narten <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Mon, 14 Mar 2005 13:48:00 -0500

I support David's approach.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, March 14, 2005 1:32 PM
> To: Frank Quick; Alan DeKok; Avi Lior; W. Mark Townsley
> Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, 
> Christopher P.; [email-masked]; 
> [email-masked]
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> Frank Quick writes...
> 
> > This sounds very reasonable, but I think it actually goes 
> beyond the 
> > context of this draft.  I believe there is no clear 
> statement of this 
> > policy that the draft can reference, and it is not a good idea for a
> draft
> > of this nature to create new policy.  For this draft maybe it is
> enough
> > that we state that RFC 2865 forbids VSA in Access-Reject, and that
> future
> > work should consider using Access-Challenge instead.  That 
> would avoid 
> > having to discuss the semantics issue in the draft.
> 
> It is apparent that there is some disagreement within the 
> RADIUS community within IETF about the usage of 
> Access-Reject.  The areas of disagreement cover whether 
> Access-Reject implies link-layer disconnect and when 
> Access-Reject or Access-Challenge is appropriate (or 
> permissible).  In RADEXT, we have added this set of issues to be
> considered in our RADIUS Issues and Fixes I-D.   Given this lack of
> clear consensus, it might be advisable to craft an IESG note 
> along the lines that Frank describes.  Future RFCs may 
> provide more definitive guidance in this area.  Understanding 
> that, it is appropriate to discourage new work using *this* 
> document as a precedent.
> 

--
to unsubscribe send 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, 14 Mar 2005 18:33:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Date: Mon, 14 Mar 2005 13:32:00 -0500
From: "Nelson, David" <[email-masked]>
To: "Frank Quick" <[email-masked]>, "Alan DeKok" <[email-masked]>, "Avi Lior" <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>, "Barney Wolff" <[email-masked]>, "Thomas Narten" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, <[email-masked]>, <[email-masked]>

Frank Quick writes...

> This sounds very reasonable, but I think it actually goes beyond the
> context of this draft.  I believe there is no clear statement of this
> policy that the draft can reference, and it is not a good idea for a
draft
> of this nature to create new policy.  For this draft maybe it is
enough
> that we state that RFC 2865 forbids VSA in Access-Reject, and that
future
> work should consider using Access-Challenge instead.  That would avoid
> having to discuss the semantics issue in the draft.

It is apparent that there is some disagreement within the RADIUS
community within IETF about the usage of Access-Reject.  The areas of
disagreement cover whether Access-Reject implies link-layer disconnect
and when Access-Reject or Access-Challenge is appropriate (or
permissible).  In RADEXT, we have added this set of issues to be
considered in our RADIUS Issues and Fixes I-D.   Given this lack of
clear consensus, it might be advisable to craft an IESG note along the
lines that Frank describes.  Future RFCs may provide more definitive
guidance in this area.  Understanding that, it is appropriate to
discourage new work using *this* document as a precedent.

--
to unsubscribe send 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, 10 Mar 2005 04:21:51 +0000
Date: Wed, 9 Mar 2005 20:21:24 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Review of draft-lior-radius-bandwidth-capability-00.txt

Review of draft-lior-radius-bandwidth-capability-00.txt

Overall, my recommendation is that the material from Section 3-6 of this
document be incorporated into the IEEE 802 document in the next revision.
The material from Sections 1-2 is mostly expository and therefore is not
required in an attribute specification.  My recommendation is to incorporate
the material required to describe the attributes into Section 3,  and put
the rest of section 1-2 into a separate document or drop it altogether.

Comments on Section 3-6 follow.

Section 3

The Ingress and Egress Bandwidth attributes are defined as 32 bit
values expressing Bytes per second.  Is this really the right way
to express bandwidth?  This attribute has been implemented in
Metro Ethernet networks where bandwidth of 10+ Gbps is available,
and we are seeing an order of magnitude increase every 3 years.
I'd suggest that we might want to think of alternative scales
such as Kbps, as well as a 64-bit value instead of 32-bits.

Also, the explanations of the attributes in Section 3 are minimal.
The RADIUS tradition is to explain the usage of the attribute here
(see RFC 2865) rather than writing a large "architecture" section.

While I'm fairly clear about the usage of the bw attributes in
Access-Accept, CoA-Request and Accounting-Request packets, I am
not as clear about the meaning in an Access-Request.  In that
situation "bandwidth available" seems unclear to me.  Is this
a measurement of the negotiated rate?  Of the "slot time" available
to a station?  Of the available throughput?  There are highly
transient measurements.  If we are looking for flow data then
there are better ways to get it.

Similarly, in Accounting-Request packets I can see echoing
the bw values from the Access-Accept.  But a dynamic measurement
seems redundant since we already support attributes for octets
in/out.

   Note 1 :  If Ingress-Bandwidth appears alone in an Access-Request
      packet then the NAS is indicating that it only supports symmetric
      bandwidth allocation.  Therefore, Egress bandwidth SHOULD NOT
      appear in the corresponding Access-Accept packet.
   Note 2 :  Bandwidth-Profile-Id MUST NOT appear in a RADIUS packet
      that contains either or both of Ingress-Bandwidth or
      Egress-Bandwidth attributes.

The Note 1 seems to imply that putting bw attributes in an Access-Request
is for capability negotiation.

Section 5

Why does this document require new vlues for Acct-Terminate-Cause?

Section 6

Surely there must be *some* security implications of these attributes, no?

--
to unsubscribe send 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, 10 Mar 2005 03:26:45 +0000
Date: Wed, 9 Mar 2005 19:26:26 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Pre-work item review

As discussed at today's meeting, we are looking to gauge WG interest in
making the following documents WG work items:

RADIUS MIB Revision
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt

RFC 3576 MIBs
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-03.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-03.txt

RADIUS Extensions for IEEE 802
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt

Please send your comments to the RADEXT mailing list.

--
to unsubscribe send 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: Thu, 10 Mar 2005 02:34:27 +0000
From: "Alan DeKok" <[email-masked]>
To: Avi Lior <[email-masked]>, "'Frank Quick'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>
Cc: "'Jari Arkko'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, "'Barney Wolff'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>, "'Carroll, Christopher P.'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Date: Wed, 09 Mar 2005 21:29:20 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> In repsonse to an Access-Request for access to the network, Access-Reject
> repsonse states to the NAS not to give the Session access to the network (or
> however you want to word it).

  I agree.  Issue 68 addresses this use of Access-Reject.

> What the NAS does to the connection between it an the user's device is out
> of scope to RADIUS.  If the NAS wants to maintain the L2 connection to the
> device it can.  

  I agree.  I've submitted an additional issue for Access-Reject
semantics (I presume it will show up after IETF).  I will be adding
additional text to it, based on your recent comments about RFC 3576
and EAP-Message, etc. in Access-Reject.  These issues need to be
clarified.

  In the context of this draft, I believe that the point of contention
here is that the Access-Reject is in the *middle* of the
authentication session.  The authentication is expected to continue
after the Access-Reject, with another Access-Request containing
information based on the Access-Reject.  This is the semantics that
Access-Challenge was designed for.

  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, 09 Mar 2005 22:51:47 +0000
Content-class: urn:content-classes:message
Subject: Issue: missing enumeration for 'sftp' and 'scp' as managed protocols
Date: Wed, 9 Mar 2005 14:50:59 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C524FA.777EA5E6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

	Issue: SFTP and SCP has been left out as explicit managed
administrative protocols.
	Submitter name:  Mauricio Sanchez
	Submitter email address: [email-masked]
	Date first submitted: 5/9/2005
	Reference:=20
	Document: draft-nelson-radius-management-authorization-01.txt
	Comment type: T
	Priority: S
	Section: 8.1, 8.2
	Rationale/Explanation of issue:  see below=20
	Length description of problem=20
	SFTP and SCP should be treated seperately from SSH-based console
access.  SFTP and SCP are SSH-based file transfer services and should
not implicity be lumped with console based access.=20

	Requested change:=20
	Suggest that a new values (4) and (5) be allocated under the
'Framed-Management-Protocol' (section 8.1) or the
'Non-Framed-Managed-Protocol' (section 8.2) attribute for SFTP and SCP
protocols, respectively. It's not clear to me whether SCP and SFTP
should be considered a framed or non-framed protocol.  Moreover, draft
should elaborate on the explicit meaning of SSH being used in only a
console access role for administrative purposes (which is it's nominal
role anyway). =20

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------  =20

------_=_NextPart_001_01C524FA.777EA5E6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.46">
<TITLE>Issue: missing enumeration for 'sftp' and 'scp' as managed =
protocols</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>
<UL>
<P><FONT FACE=3D"Times New Roman">Issue: SFTP and SCP has been left out =
as explicit managed administrative protocols.<BR>
Submitter name:&nbsp; Mauricio Sanchez<BR>
Submitter email address: [email-masked]<BR>
Date first submitted: 5/9/2005<BR>
Reference:<BR>
Document: draft-nelson-radius-management-authorization-01.txt<BR>
Comment type: T<BR>
Priority: S<BR>
Section: 8.1, 8.2<BR>
Rationale/Explanation of issue:&nbsp; see below<BR>
Length description of problem<BR>
SFTP and SCP should be treated seperately from SSH-based console =
access.&nbsp; SFTP and SCP are SSH-based file transfer services and =
should not implicity be lumped with console based access. </FONT></P>
<BR>

<P><FONT FACE=3D"Times New Roman">Requested change:<BR>
Suggest that a new values (4) and (5) be allocated under the =
'Framed-Management-Protocol' (section 8.1) or the =
'Non-Framed-Managed-Protocol' (section 8.2) attribute for SFTP and SCP =
protocols, respectively. It's not clear to me whether SCP and SFTP =
should be considered a framed or non-framed protocol.&nbsp; Moreover, =
draft should elaborate on the explicit meaning of SSH being used in only =
a console access role for administrative purposes (which is it's nominal =
role anyway).&nbsp; </FONT></P>
</UL>
<P><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mauricio Sanchez</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">, CISSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Network Security Architect</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Procurve Networking Business</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Hewlett Packard</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">8000 Foothills Boulevard, ms =
5555</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Roseville CA, 95747-5557</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">916.785.1910 Tel</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">916.785.1815 Fax</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------&nbsp;&nbsp; =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C524FA.777EA5E6--

--
to unsubscribe send 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, 09 Mar 2005 02:58:15 +0000
From: Avi Lior <[email-masked]>
To: 'Frank Quick' <[email-masked]>, Avi Lior <[email-masked]>, Avi Lior <[email-masked]>,  "Nelson, David" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked], "W. Mark Townsley" <[email-masked]>
Cc: Jari Arkko <[email-masked]>, Barney Wolff <[email-masked]>,  Thomas Narten <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Tue, 8 Mar 2005 21:57:30 -0500 

I know its not your decision nor mine. We just put out 2 cents worth in.

So at least lets recommend text that makes us sleep well at night lol.

> -----Original Message-----
> From: Frank Quick [mailto:[email-masked]] 
> Sent: Tuesday, March 08, 2005 1:32 PM
> To: Avi Lior; Avi Lior; Nelson, David; Avi Lior; 
> [email-masked]; W. Mark Townsley
> Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, 
> Christopher P.; [email-masked]; 
> [email-masked]
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> I am ok with including or not including issue (2) - I agree with your 
> argument completely but it is not my decision to make.
> 
> At 01:15 PM 3/8/2005 -0500, Avi Lior wrote:
> >Hi Frank,
> >
> >Comments inline.
> >
> > > -----Original Message-----
> > > From: Frank Quick [mailto:[email-masked]]
> > > Sent: Tuesday, March 08, 2005 12:31 PM
> > > To: Avi Lior; Nelson, David; Avi Lior; [email-masked]; W. Mark 
> > > Townsley
> > > Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll,
> > > Christopher P.; [email-masked];
> > > [email-masked]
> > > Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> > >
> > >
> > > My thinking as of this point is:
> > >
> > > 2865 clearly states (multiple times) that VSAs cannot be in 
> > > Access-Reject.  Personally I think this is an unnecessary 
> > > requirement, but I do not mind including a disclaimer indicating 
> > > that this is a noncompliance in the draft, and recommending that 
> > > future work not repeat
> > > that noncompliance.
> >
> >I agree that disallowing VSAs does seem today to be a tad harsh.  We 
> >need to fix that...
> >
> >
> > > 2865 does _not_ state that an Access-Reject must result 
> in tearing 
> > > down the connection.  I think there is an old saying that "the
> > > faintest writing is
> > > better than the clearest memory."  In this case, no matter
> > > what people
> > > remember, there is no part of 2865 that can be cited as a
> > > basis for the
> > > draft's noncompliance with this non-requirement.  The
> > > disclaimer could
> > > state that the opinion of the IETF is that a client should
> > > disconnect when
> > > receiving an Access-Reject, and recommend that this be
> > > required in future work.
> >
> >I don't agree with the last sentence. To premature.  Its not the 
> >opinion of the IETF that Access-Reject means tear down the 
> PPP session.  
> >I will fight that tooth and nail. So I don't  think we need to set a 
> >precendant here.
> >
> >Access-Reject means don't provide access to the user.  It doesn't 
> >necessarily mean tear down the call.  What happens between 
> the NAS and 
> >the user device is not in scope of AAA.
> >
> >
> > > I no longer think it adds anything to change the 
> paragraph in which 
> > > it is required that the PPP connection be maintained, and I will
> > > not include that
> > > change in a revised draft.
> >
> >You are free to do that.  But its should not be the 
> mandatory behaviour 
> >of RADIUS.
> >
> > > In the current disclaimer, the sentence "Subsequent RFCs 
> allow for 
> > > other attributes to be included in an Access-Reject packet but
> > > these are included
> > > to indicate the reason the authentication/authorization has
> > > failed" is
> > > clearly false, given the usage in 2869, and should be
> > > removed/replaced.
> >
> >I agree. And thankyou for pointing this out to us. At least 
> someone is 
> >reading the documents ;-)
> >
> > > I don't know whether Verizon will be ok with the sentence "As a 
> > > result, the use of this specification in other circumstances than 
> > > those described in
> > > the document is not recommended", but I have left it in for
> > > the moment.
> > >
> > > Possible wording is:
> > >
> > >      This protocol defines how RADIUS (RFC 2865) is used in a
> > >      specific situation with vendor-specific protocol extensions.
> > >      It has been reviewed by the Radius community and the
> > >      following issues have been noted: (1) The document suggests
> > >      returning a vendor-specific attribute in an Access-Reject 
> > > message. According to
> > >      RFC 2865 an Access-Reject packet MAY only include 
> Reply-Message
> > >      and Proxy-State attributes, and the inclusion of 
> vendor-specific
> > > attributes
> > >      is expressly prohibited.  In future work, the use of an
> > > Access-Challenge packet
> > >      to carry the vendor-specific attributes may be more
> > > appropriate. (2)
> > > It is also IETF's
> > >      recommendation that receipt of an Access-Reject at the
> > > NAS terminate the
> > >      session of the attached network host.
> >
> >No again take that out.  There is no consensus on this 
> point.  And it 
> >may break existing implmementations and requires further study.
> >
> >
> > >      As a result, the use of this specification in other 
> > > circumstances than
> > >      those described in the document is not recommended.  
> Any future 
> > > work based on
> > >      this specification should take these issues into 
> consideration.
> > >
> > > At 11:44 AM 3/8/2005 -0500, Avi Lior wrote:
> > > >David,
> > > >
> > > >I agree that not all RFCs are equal.   I wasn't disputing that.
> > > >
> > > >But in practical terms, are you then saying that because 2869 is 
> > > >introducing an attribute into Access-Reject it is violating
> > > 2865 which
> > > >states:
> > > >
> > > >"No other Attributes (except Proxy-State) are permitted in an 
> > > >Access-Reject."
> > > >
> > > >So no EAP-Message, no Message Authenticator introduced in 2869
> > > >
> > > >Which then invalidates RFC 3579....
> > > >
> > > >Which puts RADIUS EAP in the toilet.
> > > >
> > > >If this is all true....why were we thinking when we wrote these 
> > > >documents. Why would we work on documents that are clearly 
> > > >violating RADIUS?  Why would the IESG approve such documents?
> > > >
> > > >I would hope clearly that the above logic is flawed.  And if
> > > it is then
> > > >lets apply it equally and move on.
> > > >
> > > >If the above logic is not flawed then....wow!!!
> > > >
> > > >Avi
> > > >
> > > > > -----Original Message-----
> > > > > From: Nelson, David [mailto:[email-masked]]
> > > > > Sent: Tuesday, March 08, 2005 11:29 AM
> > > > > To: Avi Lior; [email-masked]; Frank Quick; W. Mark Townsley
> > > > > Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, 
> > > > > Christopher P.; [email-masked]; 
> > > > > [email-masked]
> > > > > Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> > > > >
> > > > >
> > > > > Avi Lior writes...
> > > > >
> > > > > > Regarding: not all RFCs are created equal...
> > > > > > We have to be careful here.  This line of thinking is going
> > > > > to create
> > > > > > havoc.
> > > > >
> > > > > Havoc?  That sounds like an overstatement, IMHO.
> > > > >
> > > > > RFCs are issued as Informational for several reasons.
> > > Some of those
> > > > > reasons are (a) the protocol is not considered
> > > sufficiently mature
> > > > > to be considered as a Proposed Standard,
> > > > > (b) the protocol is vendor proprietary or has a 
> limited scope of 
> > > > > applicability, and (c) the internet-draft was not the
> > > product of any
> > > > > IETF working group, a therefore has had more limited review.
> > > > >
> > > > > I suspect that some of the RADIUS RFCs issued after 
> the RADIUS 
> > > > > WG closed fall into the (c) category.  Some of them may also 
> > > > > have fallen into the
> > > > > (a) category, at least at the time of publication.
> > > > >
> > > > > Glen is correct, however, in his statement.
> > > > >
> > >
> > >
> > > Frank Quick
> > > office   +1-858-658-3608 fax +1-858-651-1940
> > > portable +1-619-890-5749
> > > paging   [email-masked]
> > > RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> > > D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D
> > >
> 
> 
> Frank Quick
> office   +1-858-658-3608 fax +1-858-651-1940
> portable +1-619-890-5749
> paging   [email-masked]
> RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D
> 

--
to unsubscribe send 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, 08 Mar 2005 22:15:12 +0000
Date: Tue, 8 Mar 2005 23:14:29 +0100
From: Emile van Bergen <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Isssue on CUI-03
Mail-Followup-To: "Adrangi, Farid" <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Tue, Mar 08, 2005 at 11:38:56AM -0800, Adrangi, Farid wrote:

> 	In discussions on the WG mailing list or in other e-mail threads
> on this draft, I believe we had reached agreement that the content of
> the CUI attribute would be described as an "opaque token", or as an
> authenticated surrogate identity, but that only the Home AAA server was
> in a position to make any other semantic interpretation of the CUI
> content and that all other entities, e.g. proxy servers or NASes, should
> treat the CUI as a "cookie", performing a binary-equality-test operation
> on two CUI instances, but making no other interpretation of the CUI
> content.  That restriction didn't make in into the -03 draft.
> 	 
> 
> 	I would recommend that "The format and the interpretation of the
> string value, and the binding lifetime of the reference to the user is
> determined based on business agreements." (above) be changed to "The
> format and content of the string value is determined by the Home RADIUS
> server.  The binding lifetime of the reference to the user is determined
> based on business agreements.  RADIUS entities other than the Home
> RADIUS server MUST treat the CUI content as an opaque token, and SHOULD
> NOT perform operations on its content other than a binary equality
> comparison test, between two instances of CUI."    

I could not agree more. CUI should be as opaque as Class. 

Let's not define things we don't need to define for the application that
needs CUI. That just needs binary comparison of opaque tokens, so that
should be defined, nothing more. The IETF is about the minimum that
needs to be put on the wire in order to achieve interoperability; future
applications should not be needlessly obstructed. We should not invite
people to make stupid assumptions with respect to attribute content
because of an attribute's semantics in the example application it was
devised for.

As an example if RADIUS had specified that Class may only hold a human
readable service description that should be the same for all users of a
certain service? It would never have acquired its excellent application
as a validator for accounting from untrusted upstream parties.

Kind regards,

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: Tue, 08 Mar 2005 20:56:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Isssue on CUI-03
Date: Tue, 8 Mar 2005 15:55:37 -0500
From: "Nelson, David" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: <[email-masked]>

No entity other than the home AAA can derive a true user identity from =
the CUI, so I would recommend that "require a user identity" (above) be =
changed to "require an authenticated surrogate identity to bind the =
current session".

[FA] I agree but I am not sure about the word "authenticated".=A0=A0 It =
could be misleading because there is no=A0way to detect or prevent =
modification of the CUI by the RADIUS entities outside the home =
network.=A0 Is it okay to remove the word "authenticated" from your =
proposed text?

DBN: OK.  I used that phrase because I found it elsewhere in the draft.  =
:-)

[FA] I am okay with your recommendation -- I think it is a good one!=A0 =
If there are not any objections from others, I will update the document =
based on your comments.

DBN:  Thanks.=A0=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, 08 Mar 2005 19:39:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Isssue on CUI-03
Date: Tue, 8 Mar 2005 11:38:56 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C52416.77705EB7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi David,
Thanks for filing the issue.  Please see my comments inline.
BR,
Farid

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nelson, David
	Sent: Tuesday, March 08, 2005 9:06 AM
	To: [email-masked]
	Subject: Isssue on CUI-03
=09
=09

	Issue with CUI-03 in the definition of CUI content.

	=20

	Submitter name: David B. Nelson

	Submitter email address: [email-masked]

	Date first submitted: 08 March 2005

	Reference:

	Document: CUI-03

	Comment type: T

	Priority: S

	Section: 1.0, 2.2

	Rationale/Explanation of issue: (see below)

	Requested change:

	=20

	In Section 1 Introduction: =20

	=20

	  "While this

	   mechanism is good practice in some circumstances, there are
problems

	   if local and intermediate networks require a user identity."

	=20

	No entity other than the home AAA can derive a true user
identity from the CUI, so I would recommend that "require a user
identity" (above) be changed to "require an authenticated surrogate
identity to bind the current session".

	=20

	[FA] I agree but I am not sure about the word "authenticated".
It could be misleading because there is no way to detect or prevent
modification of the CUI by the RADIUS entities outside the home network.
Is it okay to remove the word "authenticated" from your proposed text?

	=20

	In Section 2.2 CUI Attribute:

	=20

	  "String:

	=20

	      The string identifies the CUI of the end-user and is of
type

	      UTF8String.  This string value is a reference to a
particular

	      user.  The format and the interpretation of the string
value , and

	      the binding lifetime of the reference to the user is
determined

	      based on business agreements.  For example, the lifetime
can be

	      set to one billing period.  In cases where the attribute
is used

	      to indicate the NAS support for the CUI, the string value
contains

	      a nul character."

	=20

	In discussions on the WG mailing list or in other e-mail threads
on this draft, I believe we had reached agreement that the content of
the CUI attribute would be described as an "opaque token", or as an
authenticated surrogate identity, but that only the Home AAA server was
in a position to make any other semantic interpretation of the CUI
content and that all other entities, e.g. proxy servers or NASes, should
treat the CUI as a "cookie", performing a binary-equality-test operation
on two CUI instances, but making no other interpretation of the CUI
content.  That restriction didn't make in into the -03 draft.

	=20

	I would recommend that "The format and the interpretation of the
string value, and the binding lifetime of the reference to the user is
determined based on business agreements." (above) be changed to "The
format and content of the string value is determined by the Home RADIUS
server.  The binding lifetime of the reference to the user is determined
based on business agreements.  RADIUS entities other than the Home
RADIUS server MUST treat the CUI content as an opaque token, and SHOULD
NOT perform operations on its content other than a binary equality
comparison test, between two instances of CUI."   =20

	=20

	[FA] I am okay with your recommendation -- I think it is a good
one!   If there are not any objections from others, I will update the
document based on your comments. =20

------_=_NextPart_001_01C52416.77705EB7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1480" name=3DGENERATOR>
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
LI.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
DIV.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D799063319-08032005>Hi=20
David,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D799063319-08032005>Thanks=20
for filing the issue.&nbsp; Please see my comments =
inline.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D799063319-08032005>BR,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D799063319-08032005>Farid</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Nelson, David<BR><B>Sent:</B> Tuesday, March 08, 2005 =
9:06=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Isssue on=20
  CUI-03<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Issue with CUI-03 in the definition of CUI=20
  content.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Submitter name: David B.=20
  Nelson<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Submitter email address:=20
  [email-masked]<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Date first submitted: 08 March=20
  2005<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Reference:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Document: =
CUI-03<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Comment type: T<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Priority: S<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Section: 1.0, =
2.2<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Rationale/Explanation of issue: (see=20
  below)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Requested =
change:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">In Section 1 Introduction:&nbsp;=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp; &#8220;While =
this<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; mechanism is good practice in =
some=20
  circumstances, there are problems<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; if local and intermediate =
networks=20
  require a user identity.&#8221;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">No entity other than the home AAA can derive =
a true=20
  user identity from the CUI, so I would recommend that &#8220;require a =
user=20
  identity&#8221; (above) be changed to &#8220;require an authenticated =
surrogate identity=20
  to bind the current session&#8221;.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3DArial color=3D#0000ff><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p><SPAN class=3D799063319-08032005>[FA] =
<SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p><SPAN class=3D013261117-08032005>I =
agree&nbsp;but I=20
  am not sure about the word "authenticated".&nbsp;&nbsp; It could be =
misleading=20
  because there is no&nbsp;way to detect or prevent modification of the =
CUI by=20
  the RADIUS entities outside the home network.&nbsp; Is it okay to =
remove the=20
  word "authenticated" from your proposed=20
  text?</SPAN></o:p></SPAN></SPAN></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3DArial color=3D#0000ff><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p><SPAN class=3D799063319-08032005><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p><SPAN=20
  =
class=3D013261117-08032005></SPAN></o:p></SPAN></SPAN></o:p></SPAN></FONT=
>&nbsp;</P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">In Section 2.2 CUI=20
  Attribute:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp; =
&#8220;String:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The string =
identifies=20
  the CUI of the end-user and is of type<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
UTF8String.&nbsp; This=20
  string value is a reference to a =
particular<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; user.&nbsp; =
The format=20
  and the interpretation of the string value , =
and<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the binding =
lifetime of=20
  the reference to the user is determined<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; based on =
business=20
  agreements.&nbsp; For example, the lifetime can=20
be<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set to one =
billing=20
  period.&nbsp; In cases where the attribute is=20
used<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to indicate =
the NAS=20
  support for the CUI, the string value =
contains<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a nul=20
  character.&#8221;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">In discussions on the WG mailing list or in =
other=20
  e-mail threads on this draft, I believe we had reached agreement that =
the=20
  content of the CUI attribute would be described as an &#8220;opaque =
token&#8221;, or as an=20
  authenticated surrogate identity, but that only the Home AAA server =
was in a=20
  position to make any other semantic interpretation of the CUI content =
and that=20
  all other entities, e.g. proxy servers or NASes, should treat the CUI =
as a=20
  &#8220;cookie&#8221;, performing a binary-equality-test operation on =
two CUI instances,=20
  but making no other interpretation of the CUI content.&nbsp; That =
restriction=20
  didn&#8217;t make in into the -03 draft.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I would recommend that &#8220;The format and =
the=20
  interpretation of the string value, and the binding lifetime of the =
reference=20
  to the user is determined based on business agreements.&#8221; (above) =
be changed to=20
  &#8220;The format and content of the string value is determined by the =
Home RADIUS=20
  server. &nbsp;The binding lifetime of the reference to the user is =
determined=20
  based on business agreements.&nbsp; RADIUS entities other than the =
Home RADIUS=20
  server MUST treat the CUI content as an opaque token, and SHOULD NOT =
perform=20
  operations on its content other than a binary equality comparison =
test,=20
  between two instances of CUI.&#8221;&nbsp; =
&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3DArial color=3D#0000ff><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p><SPAN class=3D799063319-08032005>[FA] I =
am okay=20
  with your recommendation -- I think it is a good one!&nbsp;&nbsp; If =
there are=20
  not any objections from others, I will update the document based on =
your=20
  comments.&nbsp; =
</SPAN></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C52416.77705EB7--

--
to unsubscribe send 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, 08 Mar 2005 18:16:17 +0000
From: Avi Lior <[email-masked]>
To: Frank Quick <[email-masked]>, Avi Lior <[email-masked]>, "Nelson, David" <[email-masked]>,  Avi Lior <[email-masked]>, [email-masked], "W. Mark Townsley" <[email-masked]>
Cc: Jari Arkko <[email-masked]>, Barney Wolff <[email-masked]>,  Thomas Narten <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Tue, 8 Mar 2005 13:15:59 -0500 

Hi Frank,

Comments inline.

> -----Original Message-----
> From: Frank Quick [mailto:[email-masked]] 
> Sent: Tuesday, March 08, 2005 12:31 PM
> To: Avi Lior; Nelson, David; Avi Lior; [email-masked]; W. Mark Townsley
> Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, 
> Christopher P.; [email-masked]; 
> [email-masked]
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> My thinking as of this point is:
> 
> 2865 clearly states (multiple times) that VSAs cannot be in 
> Access-Reject.  Personally I think this is an unnecessary 
> requirement, but 
> I do not mind including a disclaimer indicating that this is a 
> noncompliance in the draft, and recommending that future work 
> not repeat 
> that noncompliance.

I agree that disallowing VSAs does seem today to be a tad harsh.  We need to
fix that...

> 2865 does _not_ state that an Access-Reject must result in 
> tearing down the 
> connection.  I think there is an old saying that "the 
> faintest writing is 
> better than the clearest memory."  In this case, no matter 
> what people 
> remember, there is no part of 2865 that can be cited as a 
> basis for the 
> draft's noncompliance with this non-requirement.  The 
> disclaimer could 
> state that the opinion of the IETF is that a client should 
> disconnect when 
> receiving an Access-Reject, and recommend that this be 
> required in future work.

I don't agree with the last sentence. To premature.  Its not the opinion of
the IETF that Access-Reject means tear down the PPP session.  I will fight
that tooth and nail. So I don't  think we need to set a precendant here.

Access-Reject means don't provide access to the user.  It doesn't
necessarily mean tear down the call.  What happens between the NAS and the
user device is not in scope of AAA.

> I no longer think it adds anything to change the paragraph in 
> which it is 
> required that the PPP connection be maintained, and I will 
> not include that 
> change in a revised draft.

You are free to do that.  But its should not be the mandatory behaviour of
RADIUS.
 
> In the current disclaimer, the sentence "Subsequent RFCs 
> allow for other 
> attributes to be included in an Access-Reject packet but 
> these are included 
> to indicate the reason the authentication/authorization has 
> failed" is 
> clearly false, given the usage in 2869, and should be 
> removed/replaced.

I agree. And thankyou for pointing this out to us. At least someone is
reading the documents ;-)
 
> I don't know whether Verizon will be ok with the sentence "As 
> a result, the 
> use of this specification in other circumstances than those 
> described in 
> the document is not recommended", but I have left it in for 
> the moment.
> 
> Possible wording is:
> 
>      This protocol defines how RADIUS (RFC 2865) is used in a
>      specific situation with vendor-specific protocol extensions.
>      It has been reviewed by the Radius community and the
>      following issues have been noted: (1) The document suggests
>      returning a vendor-specific attribute in an 
> Access-Reject message. 
> According to
>      RFC 2865 an Access-Reject packet MAY only include Reply-Message
>      and Proxy-State attributes, and the inclusion of vendor-specific 
> attributes
>      is expressly prohibited.  In future work, the use of an 
> Access-Challenge packet
>      to carry the vendor-specific attributes may be more 
> appropriate. (2) 
> It is also IETF's
>      recommendation that receipt of an Access-Reject at the 
> NAS terminate the
>      session of the attached network host.

No again take that out.  There is no consensus on this point.  And it may
break existing implmementations and requires further study.

>      As a result, the use of this specification in other 
> circumstances than
>      those described in the document is not recommended.  Any 
> future work 
> based on
>      this specification should take these issues into consideration.
> 
> At 11:44 AM 3/8/2005 -0500, Avi Lior wrote:
> >David,
> >
> >I agree that not all RFCs are equal.   I wasn't disputing that.
> >
> >But in practical terms, are you then saying that because 2869 is 
> >introducing an attribute into Access-Reject it is violating 
> 2865 which 
> >states:
> >
> >"No other Attributes (except Proxy-State) are permitted in an 
> >Access-Reject."
> >
> >So no EAP-Message, no Message Authenticator introduced in 2869
> >
> >Which then invalidates RFC 3579....
> >
> >Which puts RADIUS EAP in the toilet.
> >
> >If this is all true....why were we thinking when we wrote these 
> >documents. Why would we work on documents that are clearly violating 
> >RADIUS?  Why would the IESG approve such documents?
> >
> >I would hope clearly that the above logic is flawed.  And if 
> it is then 
> >lets apply it equally and move on.
> >
> >If the above logic is not flawed then....wow!!!
> >
> >Avi
> >
> > > -----Original Message-----
> > > From: Nelson, David [mailto:[email-masked]]
> > > Sent: Tuesday, March 08, 2005 11:29 AM
> > > To: Avi Lior; [email-masked]; Frank Quick; W. Mark Townsley
> > > Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, Christopher 
> > > P.; [email-masked]; [email-masked]
> > > Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> > >
> > >
> > > Avi Lior writes...
> > >
> > > > Regarding: not all RFCs are created equal...
> > > > We have to be careful here.  This line of thinking is going
> > > to create
> > > > havoc.
> > >
> > > Havoc?  That sounds like an overstatement, IMHO.
> > >
> > > RFCs are issued as Informational for several reasons.  
> Some of those 
> > > reasons are (a) the protocol is not considered 
> sufficiently mature 
> > > to be considered as a Proposed Standard,
> > > (b) the protocol is vendor proprietary or has a limited scope of 
> > > applicability, and (c) the internet-draft was not the 
> product of any 
> > > IETF working group, a therefore has had more limited review.
> > >
> > > I suspect that some of the RADIUS RFCs issued after the RADIUS WG 
> > > closed fall into the (c) category.  Some of them may also have 
> > > fallen into the
> > > (a) category, at least at the time of publication.
> > >
> > > Glen is correct, however, in his statement.
> > >
> 
> 
> Frank Quick
> office   +1-858-658-3608 fax +1-858-651-1940
> portable +1-619-890-5749
> paging   [email-masked]
> RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D
> 

--
to unsubscribe send 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, 08 Mar 2005 17:53:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 75: Why Not UTF-8 For Realm, Too?
Date: Tue, 8 Mar 2005 19:51:52 +0200
From: <[email-masked]>
To: <[email-masked]>

This basically proposes changing the realm part from
"IDN-unaware domain name slot" to "IDN-aware domain name slot"
(in RFC 3490 terminology). This might cause problems, since
existing systems don't know that they need to use the ToAscii
operation before e.g. using the realm for DNS lookups.
(But I'm not sure how important those problems would be in
practice...)

However, it seems that the problem described below does not
occur if the client implements 2486bis and RFC 3490 (and
understands the "!" notation).=20

In this case, all the places where realms can occur are "IDN-
unware domain name slots", and thus according to RFC 3490, the=20
client must use ToAscii for them. Thus, when a NAI looking like=20
"<part1>!<part2>@<part3>" reaches a RADIUS proxy, neither part1=20
or part3 contain any non-ASCII characters (since they were run=20
through ToAscii), and the proxy doesn't have to do any conversions=20
when "undecorating" this to "<part2>@<part1>".

Of course, it's probably realistic to assume that many clients
will take shortcuts in implementing support for non-ASCII
characters (such as simply taking whatever the user typed in,
UTF-8 encoding it, and stuffing that to EAP identity response or
something) instead of implementing 2486bis and RFC 3490 to the
letter. Obviously, there's no way to guarantee that these
kind of clients fully comply with everything.

Also, if the client does not understand the "!" notation, then
there's no way to guarantee that part1 will conform to RFC 3490=20
(which is not only about UTF-8 vs. Punycode encoding, but other=20
things as well).

It thus seems that doing things 100% right in the client is very=20
difficult, and IMHO anything we can do won't substantially change
that. We can only give pointers to specs which describe the
right way, and if the implementations ignore that, well, that's
life (but I don't think that, e.g., ignoring some minor details=20
of RFC3490 would cause major interoperability problems... so
perhaps this is not a very serious issue).

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: Monday, March 07, 2005 9:17 AM
> To: [email-masked]
> Subject: Issue 75: Why Not UTF-8 For Realm, Too?
>=20
>=20
> Issue 75: Why Not UTF-8 For Realm, Too?
> Submitter name: Avi Lior
> Submitter email address: [email-masked]
> Date first submitted: March 6, 2005
> Reference:
> Document: RFC2486bis
> Comment type: T
> Priority: S
> Section:  Various
> Rationale/Explanation of issue:
>=20
> When a RADIUS proxy undecorates the NAI, the current document
> may require translation when a realm name moves between the
> userid portion and the realm portion. For example, when
> [email-masked] is redecorated to
> [email-masked].  In the fomer construction, intl_name.com
> is in UTF-8, and in the later, intl_name.com needs to be
> translated to IDNA.
>=20
> Why not just specify the entire NAI in UTF-8? Then, say that
> if a proxy needs to utilize the realm name within DNS, it will
> convert it to an IDN.  Doesn't that make more sense? Existing
> link layers (e.g. EAP Request/Response-Identity messages) can
> carry UTF-8 just fine.

--
to unsubscribe send 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, 08 Mar 2005 17:07:32 +0000
Content-class: urn:content-classes:message
Subject: Isssue on CUI-03
Date: Tue, 8 Mar 2005 12:05:52 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Issue with CUI-03 in the definition of CUI content.

=20

Submitter name: David B. Nelson

Submitter email address: [email-masked]

Date first submitted: 08 March 2005

Reference:

Document: CUI-03

Comment type: T

Priority: S

Section: 1.0, 2.2

Rationale/Explanation of issue: (see below)

Requested change:

=20

In Section 1 Introduction: =20

=20

  "While this

   mechanism is good practice in some circumstances, there are problems

   if local and intermediate networks require a user identity."

=20

No entity other than the home AAA can derive a true user identity from
the CUI, so I would recommend that "require a user identity" (above) be
changed to "require an authenticated surrogate identity to bind the
current session".

=20

In Section 2.2 CUI Attribute:

=20

  "String:

=20

      The string identifies the CUI of the end-user and is of type

      UTF8String.  This string value is a reference to a particular

      user.  The format and the interpretation of the string value , and

      the binding lifetime of the reference to the user is determined

      based on business agreements.  For example, the lifetime can be

      set to one billing period.  In cases where the attribute is used

      to indicate the NAS support for the CUI, the string value contains

      a nul character."

=20

In discussions on the WG mailing list or in other e-mail threads on this
draft, I believe we had reached agreement that the content of the CUI
attribute would be described as an "opaque token", or as an
authenticated surrogate identity, but that only the Home AAA server was
in a position to make any other semantic interpretation of the CUI
content and that all other entities, e.g. proxy servers or NASes, should
treat the CUI as a "cookie", performing a binary-equality-test operation
on two CUI instances, but making no other interpretation of the CUI
content.  That restriction didn't make in into the -03 draft.

=20

I would recommend that "The format and the interpretation of the string
value, and the binding lifetime of the reference to the user is
determined based on business agreements." (above) be changed to "The
format and content of the string value is determined by the Home RADIUS
server.  The binding lifetime of the reference to the user is determined
based on business agreements.  RADIUS entities other than the Home
RADIUS server MUST treat the CUI content as an opaque token, and SHOULD
NOT perform operations on its content other than a binary equality
comparison test, between two instances of CUI."   =20

=20

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

<html 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=3DContent-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'>Issue with CUI-03 in the definition of CUI =
content.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Submitter name: David B. 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: 08 March 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:<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: CUI-03<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: T<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: S<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.0, 2.2<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: (see =
below)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Requested change:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>In Section 1 Introduction:&nbsp; <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &#8220;While this<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; mechanism is good practice in some circumstances, =
there are
problems<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; if local and intermediate networks require a user
identity.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>No entity other than the home AAA can derive a true user =
identity from
the CUI, so I would recommend that &#8220;require a user identity&#8221; =
(above)
be changed to &#8220;require an authenticated surrogate identity to bind =
the current
session&#8221;.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>In Section 2.2 CUI Attribute:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &#8220;String:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The string identifies the CUI of =
the
end-user and is of type<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UTF8String.&nbsp; This string =
value is a
reference to a particular<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; user.&nbsp; The format and the
interpretation of the string value , and<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the binding lifetime of the =
reference to
the user is determined<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; based on business =
agreements.&nbsp; For
example, the lifetime can be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set to one billing period.&nbsp; =
In
cases where the attribute is used<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to indicate the NAS support for =
the CUI,
the string value contains<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a nul =
character.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>In discussions on the WG mailing list or in other e-mail threads =
on
this draft, I believe we had reached agreement that the content of the =
CUI
attribute would be described as an &#8220;opaque token&#8221;, or as an
authenticated surrogate identity, but that only the Home AAA server was =
in a
position to make any other semantic interpretation of the CUI content =
and that
all other entities, e.g. proxy servers or NASes, should treat the CUI as =
a &#8220;cookie&#8221;,
performing a binary-equality-test operation on two CUI instances, but =
making no
other interpretation of the CUI content.&nbsp; That restriction =
didn&#8217;t
make in into the -03 draft.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I would recommend that &#8220;The format and the interpretation =
of the
string value, and the binding lifetime of the reference to the user is
determined based on business agreements.&#8221; (above) be changed to =
&#8220;The
format and content of the string value is determined by the Home RADIUS =
server.
&nbsp;The binding lifetime of the reference to the user is determined =
based on
business agreements.&nbsp; RADIUS entities other than the Home RADIUS =
server
MUST treat the CUI content as an opaque token, and SHOULD NOT perform
operations on its content other than a binary equality comparison test, =
between
two instances of CUI.&#8221;&nbsp; =
&nbsp;&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C52401.15845550--

--
to unsubscribe send 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, 08 Mar 2005 16:44:44 +0000
From: Avi Lior <[email-masked]>
To: "Nelson, David" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked], Frank Quick <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Cc: Jari Arkko <[email-masked]>, Barney Wolff <[email-masked]>,  Thomas Narten <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Tue, 8 Mar 2005 11:44:17 -0500 

David,

I agree that not all RFCs are equal.   I wasn't disputing that.

But in practical terms, are you then saying that because 2869 is introducing
an attribute into Access-Reject it is violating 2865 which states:

"No other Attributes (except Proxy-State) are permitted in an
Access-Reject."

So no EAP-Message, no Message Authenticator introduced in 2869

Which then invalidates RFC 3579....

Which puts RADIUS EAP in the toilet.

If this is all true....why were we thinking when we wrote these documents.
Why would we work on documents that are clearly violating RADIUS?  Why would
the IESG approve such documents?

I would hope clearly that the above logic is flawed.  And if it is then lets
apply it equally and move on.

If the above logic is not flawed then....wow!!!

Avi

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, March 08, 2005 11:29 AM
> To: Avi Lior; [email-masked]; Frank Quick; W. Mark Townsley
> Cc: Jari Arkko; Barney Wolff; Thomas Narten; Carroll, 
> Christopher P.; [email-masked]; 
> [email-masked]
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> Avi Lior writes...
> 
> > Regarding: not all RFCs are created equal...
> > We have to be careful here.  This line of thinking is going 
> to create 
> > havoc.
> 
> Havoc?  That sounds like an overstatement, IMHO.
> 
> RFCs are issued as Informational for several reasons.  Some 
> of those reasons are (a) the protocol is not considered 
> sufficiently mature to be considered as a Proposed Standard, 
> (b) the protocol is vendor proprietary or has a limited scope 
> of applicability, and (c) the internet-draft was not the 
> product of any IETF working group, a therefore has had more 
> limited review.
> 
> I suspect that some of the RADIUS RFCs issued after the 
> RADIUS WG closed fall into the (c) category.  Some of them 
> may also have fallen into the
> (a) category, at least at the time of publication.
> 
> Glen is correct, however, in his statement. 
> 

--
to unsubscribe send 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, 08 Mar 2005 16:29:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Tue, 8 Mar 2005 11:28:55 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>, "Frank Quick" <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>, "Barney Wolff" <[email-masked]>, "Thomas Narten" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Regarding: not all RFCs are created equal...
> We have to be careful here.  This line of thinking is going to create
> havoc.

Havoc?  That sounds like an overstatement, IMHO.

RFCs are issued as Informational for several reasons.  Some of those
reasons are (a) the protocol is not considered sufficiently mature to be
considered as a Proposed Standard, (b) the protocol is vendor
proprietary or has a limited scope of applicability, and (c) the
internet-draft was not the product of any IETF working group, a
therefore has had more limited review.

I suspect that some of the RADIUS RFCs issued after the RADIUS WG closed
fall into the (c) category.  Some of them may also have fallen into the
(a) category, at least at the time of publication.

Glen is correct, however, in his statement.=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, 08 Mar 2005 16:21:01 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>, [email-masked], 'Frank Quick' <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>
Cc: 'Jari Arkko' <[email-masked]>, "'Nelson, David'" <[email-masked]>, 'Barney Wolff' <[email-masked]>, 'Avi Lior' <[email-masked]>, 'Thomas Narten' <[email-masked]>,  "'Carroll, Christopher P.'" <[email-masked]>,  [email-masked], [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Tue, 8 Mar 2005 11:19:55 -0500 

I don't see any problem here...

In repsonse to an Access-Request for access to the network, Access-Reject
repsonse states to the NAS not to give the Session access to the network (or
however you want to word it).

What the NAS does to the connection between it an the user's device is out
of scope to RADIUS.  If the NAS wants to maintain the L2 connection to the
device it can.  

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Monday, March 07, 2005 8:52 PM
> To: [email-masked]; 'Frank Quick'; 'W. Mark Townsley'
> Cc: 'Jari Arkko'; 'Nelson, David'; 'Barney Wolff'; 'Avi 
> Lior'; 'Thomas Narten'; 'Carroll, Christopher P.'; 
> [email-masked]; [email-masked]
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> "Glen Zorn (gwz)" <[email-masked]> wrote:
> > I think that this is an error in 2869, and itself a 
> violation of 2865.
> ...
> > However, you are right that 2865 does not explicitly say that the 
> > connection must be dropped, it merely assumes that that is the only 
> > reasonable course of action.  I agree with that assumption, 
> obviously, 
> > since otherwise the semantics of the Access-Reject message 
> are up for 
> > grabs.
> 
>   I agree.  The use of Access-Reject as a *normal* part of a
> *continuing* authentication conversation violates RFC 2865.  
> The text in RFC 2869 should have used Access-Challenge, and 
> included the Password-Retry attribute there.  RFC 2869 
> Section 2.2 page 8, even
> says:
> 
>    If that authentication fails, the RADIUS server should return an
>    Access-Reject packet to the NAS, with optional Password-Retry and
>    Reply-Messages attributes.  The presence of Password-Retry 
> indicates
>    the ARAP NAS MAY choose to initiate another 
> challenge-response cycle,
> 
>   "challenge-response" should mean the use of the 
> Access-Challenge packet, and only the Access-Challenge attribute.
> 
>   RFC 2865, Section 4.4, page 19 addresses the semantics of 
> Access-Challenge being equivalent to Access-Reject in some cases:
> 
>       If the NAS does not support challenge/response, it MUST treat an
>       Access-Challenge as though it had received an Access-Reject
>       instead.
> 
>   Given the discussion surrounding Access-Reject, and the 
> comments about RFC 2869, I think we should open another issue 
> for the RFC 2869 violation of Access-Reject semantics, 
> independent of this draft.
> 
>   Alan DeKok.
> 

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

Delivery-date: Tue, 08 Mar 2005 16:20:42 +0000
From: Avi Lior <[email-masked]>
To: [email-masked], 'Frank Quick' <[email-masked]>,  "'W. Mark Townsley'" <[email-masked]>
Cc: 'Jari Arkko' <[email-masked]>, "'Nelson, David'" <[email-masked]>, 'Barney Wolff' <[email-masked]>, 'Avi Lior' <[email-masked]>, 'Thomas Narten' <[email-masked]>,  "'Carroll, Christopher P.'" <[email-masked]>,  [email-masked], [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Tue, 8 Mar 2005 11:19:57 -0500 

Regarding: not all RFCs are created equal...
We have to be careful here.  This line of thinking is going to create havoc.
It puts into doubt all of 2869 and documents based on it like 3579 etc....

2865 says: nothing but Reply-Messsage is in Access-Reject period end.

2869 allows for EAP-Message and Message Authenticator.  So does that mean
that EAP RADIUS (3579) which is also informational is dead?

I don't even know why 2869 is informational.

IMO 2869 extends 2865

Lets move on....

Avi

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Monday, March 07, 2005 8:27 PM
> To: 'Frank Quick'; 'W. Mark Townsley'
> Cc: 'Jari Arkko'; 'Nelson, David'; 'Barney Wolff'; 'Avi 
> Lior'; 'Thomas Narten'; 'Carroll, Christopher P.'; 
> [email-masked]; [email-masked]
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> Frank Quick <mailto:[email-masked]> supposedly scribbled:
> 
> > I expect many of the participants in this thread are busy 
> at IETF, but 
> > I will continue it anyway, expecting delays in some responses.
> 
> > 
> > Looking at 2865 and 2869 this weekend:  I could not find any
> explicit
> > statement in 2865 that says the client MUST drop the connection
> when
> > an Access-Reject is received.  Perhaps this is something that was
> > articulated later?   
> 
> IIRC, it was something that was taken as obvious from the 
> name of the message.
> 
> > 
> > In 2869, furthermore, there is a Password-Retry attribute whose 
> > purpose is:
> > 
> >        This attribute MAY be included in an Access-Reject to
> indicate
> >        how many authentication attempts a user may be allowed to
> >        attempt before being disconnected.
> > 
> > I don't see how this is fundamentally different from what we do in 
> > DMU.
> 
> I think that this is an error in 2869, and itself a violation 
> of 2865.  All RFCs are not created equal: 2869 is 
> Informational, while 2865 is a Proposed Standard & as such 
> must take precedence. However, you are right that 2865 does 
> not explicitly say that the connection must be dropped, it 
> merely assumes that that is the only reasonable course of 
> action.  I agree with that assumption, obviously, since 
> otherwise the semantics of the Access-Reject message are up for grabs.
> 
> > 
> > If there is no explicit requirement in 2865, then the proposed 
> > disclaimer language would be in error, since the only 2865 
> > noncompliance would be with the prohibition of VSA in
> Access-Reject.  
> > 
> > 
> > Frank Quick
> > office   +1-858-658-3608 fax +1-858-651-1940
> > portable +1-619-890-5749
> > paging   [email-masked]
> > RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> > D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D
> 
> 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/>

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Mar 2005 02:38:01 +0000
From: "Alan DeKok" <[email-masked]>
To: <[email-masked]>
Cc: 
Subject: ISSUE: Improper use of Access-Reject in RFC 2869
Message-Id: <[email-masked]>
Date: Mon,  7 Mar 2005 21:33:36 -0500 (EST)

Description: Improper use of Access-Reject in RFC 2869
Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: March 7, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00186.html
		http://ops.ietf.org/lists/radiusext/2005/msg00253.html
Document: RFC 2869, and "issues and fixes" draft
Comment type: T
Priority: S
Section: 2.2
Rationale:

RFC 2869 uses Access-Reject packets in a manner where one would
normally use Access-Challenge packets.  As a result, the RFC 2865
definition of Access-Reject is violated, including semantics and contents.

Requested Change: Add proposed text as section to "issues and fixes"
draft

Section 2.2, Page 8 of RFC 2869 says:

<quote>
   If that authentication fails, the RADIUS server should return an
   Access-Reject packet to the NAS, with optional Password-Retry and
   Reply-Messages attributes.  The presence of Password-Retry indicates
   the ARAP NAS MAY choose to initiate another challenge-response cycle,
</quote>

However, this use of Access-Reject violates the RFC 2865 Section 2,
page 6 requirements on Access-Reject:

<quote>
   If any condition is not met, the RADIUS server sends an "Access-
   Reject" response indicating that this user request is invalid.  If
   desired, the server MAY include a text message in the Access-Reject
   which MAY be displayed by the client to the user.  No other
   Attributes (except Proxy-State) are permitted in an Access-Reject.
</quote>

The violation is two-fold.  One, attributes other than Reply-Message
and Proxy-State are being returned in an Access-Reject.  Two, the
Access-Reject packet is being used in the context of a continuing
authentication conversation, where RFC 2865 would require the use of
Access-Challenge.  The text in RFC 2869 uses the text
"challenge-response" to describe its use of Access-Reject, indicating
that the semantics of Access-Challenge are being used.

In addition, we note that RFC 2865, Section 4.4, page 19 addresses the
semantics of Access-Challenge being equivalent to Access-Reject in
some cases:

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

While it is difficult to correct existing deployments of RFC 2869, we
have the following recommendations:

1) New deployments of RADIUS MUST NOT use Access-Reject where the
semantics of Access-Challenge are intended.

2) Access-Reject MUST mean rejection of the users authentication
request, and the NAS MUST NOT send any additional Access-Request
packets for that user session.  The question of what defines a "user
session" is a complex one, and is discussed in ISSUE 68.

3) New deployments of ARAP as described in RFC 2869 SHOULD use
Access-Challenge instead of Access-Reject packets in the conversations
described in Section 2.2.

We also note that the table of attributes in Section 5.19 of RFC 2869
has an error for the Password-Retry attribute.  It says:

<quote>
Request  Accept  Reject  Challenge   #    Attribute
...
0        0       0-1     0           75   Password-Retry
</quote>

  Where the text in Section 2.3.2 says that Password-Rety can be
included within an Access-Challenge packet, for EAP authentication
sessions.  We recommend the following change to the table, based on
RFC 3579 and the discussion here:

Request  Accept  Reject  Challenge   #    Attribute
...
0        0       0       0-1         75   Password-Retry [Note 2]

[Note 2] As per RFC 3579, the use of the Password-Rety in EAP
authentications is deprecated.  The Password-Retry attribute can
be used only for ARAP authentication.

  Alan DeKok.

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

Delivery-date: Tue, 08 Mar 2005 02:08:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Date: Mon, 7 Mar 2005 21:07:34 -0500
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

>   Given the discussion surrounding Access-Reject, and the comments
> about RFC 2869, I think we should open another issue for the RFC 2869
> violation of Access-Reject semantics, independent of this draft.

Yes.  The RADEXT chairs have also reached that conclusion.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Mar 2005 01:55:58 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked], "'Frank Quick'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Cc: "'Jari Arkko'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, "'Barney Wolff'" <[email-masked]>, "'Avi Lior'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>, "'Carroll, Christopher P.'" <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 07 Mar 2005 20:51:38 -0500
Message-Id: <[email-masked]>

"Glen Zorn (gwz)" <[email-masked]> wrote:
> I think that this is an error in 2869, and itself a violation of
> 2865.
...
> However, you are right that 2865 does not explicitly say that the
> connection must be dropped, it merely assumes that that is the only
> reasonable course of action.  I agree with that assumption,
> obviously, since otherwise the semantics of the Access-Reject
> message are up for grabs.

  I agree.  The use of Access-Reject as a *normal* part of a
*continuing* authentication conversation violates RFC 2865.  The text
in RFC 2869 should have used Access-Challenge, and included the
Password-Retry attribute there.  RFC 2869 Section 2.2 page 8, even
says:

   If that authentication fails, the RADIUS server should return an
   Access-Reject packet to the NAS, with optional Password-Retry and
   Reply-Messages attributes.  The presence of Password-Retry indicates
   the ARAP NAS MAY choose to initiate another challenge-response cycle,

  "challenge-response" should mean the use of the Access-Challenge
packet, and only the Access-Challenge attribute.

  RFC 2865, Section 4.4, page 19 addresses the semantics of
Access-Challenge being equivalent to Access-Reject in some cases:

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

  Given the discussion surrounding Access-Reject, and the comments
about RFC 2869, I think we should open another issue for the RFC 2869
violation of Access-Reject semantics, independent of this draft.

  Alan DeKok.

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

Delivery-date: Tue, 08 Mar 2005 01:27:43 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Frank Quick'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>
Cc: "'Jari Arkko'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, "'Barney Wolff'" <[email-masked]>, "'Avi Lior'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>, "'Carroll, Christopher P.'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Mon, 7 Mar 2005 17:26:51 -0800

Frank Quick <mailto:[email-masked]> supposedly scribbled:

> I expect many of the participants in this thread are busy at IETF,
> but I will continue it anyway, expecting delays in some responses.

> 
> Looking at 2865 and 2869 this weekend:  I could not find any
explicit
> statement in 2865 that says the client MUST drop the connection
when
> an Access-Reject is received.  Perhaps this is something that was
> articulated later?   

IIRC, it was something that was taken as obvious from the name of
the message.

> 
> In 2869, furthermore, there is a Password-Retry attribute whose
> purpose is: 
> 
>        This attribute MAY be included in an Access-Reject to
indicate
>        how many authentication attempts a user may be allowed to
>        attempt before being disconnected.
> 
> I don't see how this is fundamentally different from what we do in
> DMU. 

I think that this is an error in 2869, and itself a violation of
2865.  All RFCs are not created equal: 2869 is Informational, while
2865 is a Proposed Standard & as such must take precedence.
However, you are right that 2865 does not explicitly say that the
connection must be dropped, it merely assumes that that is the only
reasonable course of action.  I agree with that assumption,
obviously, since otherwise the semantics of the Access-Reject
message are up for grabs.

> 
> If there is no explicit requirement in 2865, then the proposed
> disclaimer language would be in error, since the only 2865
> noncompliance would be with the prohibition of VSA in
Access-Reject.  
> 
> 
> Frank Quick
> office   +1-858-658-3608 fax +1-858-651-1940
> portable +1-619-890-5749
> paging   [email-masked]
> RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D

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, 07 Mar 2005 20:54:59 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: Issue 69 (was Re: Access-Reject)
Date: Mon, 7 Mar 2005 15:54:45 -0500 

Hi Alan,

See comments inline:

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Monday, March 07, 2005 1:55 PM
> To: [email-masked]
> Subject: Issue 69 (was Re: Access-Reject)
> 
> 
> Avi Lior <[email-masked]> wrote:
> > Here is an simple example.  If an already authenticated 
> user wants to 
> > establish a new call VoIP call etc... The NAS can then 
> Authorize that 
> > call by issueing an Access-Request Authorize-Only.  No need to 
> > autenticate again right?
> 
>   Some comments, which are conceptual and not RADIUS-specific.
> 
>   1) The authorization request MUST be tied to a previous 
> authentication request.  If it is not, then we have the 
> problem of un-authenticated users being authorized to do 
> something.  Users may authenticate multiple sessions, so each 
> authorization request MUST be tied to a particular session, 
> and not to a user.

I agree.

Where is the binding done.  Clearly the entity making the Authorization
request can associate the Authorization request with the session.  So  the
problem you are pointing to is at the Server.

Therefore we could use Accounting-Session-Id. Failing that, AAA application
that use this need to worry about this.  Prepaid I belive does this.

>   2) The authorization request itself MUST be authenticated.  
> This is Bernard's comment in the issues page about using 
> Message-Authenticator.

Yes.

>   3) The context of the authorization request MUST be 
> interpreted as what is being requested, and not any previous 
> authentication or authorization request.  e.g. User X 
> authenticates, is authorized to do X, Y, and Z.  He later 
> requests authorization to do Q.  Any "yes/no" response MUST 
> be interpreted as meaning "yes/no" to do Q.  It MUST NOT 
> apply to the previously granted authorization.

Yes 
> 
>   My reading of the above requirements in the light of RADIUS 
> means that implementing Authorize-Only semantics in 
> Access-Requests may be problematic.

Well, not if it meets the above requirements.

>   RADIUS does not have the concept of "authenticated 
> sessions", so we may use (for example) the "Class" attribute, 
> as it's already used to tie Accounting-Requests to previous 
> Access-Requests.  Using Class to tie Access-Requests together 
> may have deployment issues.

Not sure about that. For example if a session is represented by
Acct-Session-Id then I know that that has been authenticated and authorized
no?
 
>   The Message-Authenticator attribute can address requirement (2).
Sure.
 
>   Requirement (3) means that the RADIUS server MAY have to 
> keep track of not only all user sessions, but all 
> authorization data for all user sessions.  

> Otherwise, if (in 
> the above example) the user did not originally request 
> authorization to do "Q", he could later request it, and 
> possibly gain unintended authorization.  That is, the context 
> of authorization which permits/denies "Q" is the 
> authorization to do "X, Y, and Z", which itself may be time, 
> resource, and location-dependent.

That needs to be managed by the AAA Applications themselves. Nobody said it
was going to be easy.

> 
>   So to answer Bernard's question: Yes, using Authorize-Only 
> in an Access-Request outside of the context of CoA-Request 
> and DisconnectRequest can be valid.  But we should highlight 
> the issues, so that any deployment is designed correctly.

I agree.  We need to make sure that your requirements are met.

>   The Cisco TACACS+ command authorization example I discussed 
> previously is a narrowly scoped problem which can fit within 
> the above requirements.  As for others, I'm not sure.

Thanx Alan, lets work together to make this fly.
 
>   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/>
> 

--
to unsubscribe send 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, 07 Mar 2005 20:02:11 +0000
From: Avi Lior <[email-masked]>
To: Frank Quick <[email-masked]>, "W. Mark Townsley" <[email-masked]>, [email-masked]
Cc: 'Jari Arkko' <[email-masked]>, "'Nelson, David'" <[email-masked]>, 'Barney Wolff' <[email-masked]>, 'Avi Lior' <[email-masked]>, 'Thomas Narten' <[email-masked]>,  "'Carroll, Christopher P.'" <[email-masked]>,  [email-masked], [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Mon, 7 Mar 2005 15:01:42 -0500 

Frank,

Good argument.  And thanx for bringing this out.  Not sure about the first
part that is finding an explicit statement about droping the connection.
However, your second point is pretty solid.

So the text proposed:
       This document specifies
       returning an attribute in an Access-Reject message. According to
       RFC 2865 an Access-Reject packet MAY only include Reply-Message
       and Proxy-State attributes.  Subsequent RFCs allow for other
       attributes to be included in an Access-Reject packet, but these
       are included to indicate the reason the authentication/authorization
       has failed.  It is a normative requirement of RFC 2865 that receipt
       of an Access-Reject at the NAS terminate the session of the attached
       network host.  

Is clearly wrong!!!

The conclusion I draw from that is that Access-Reject means that the NAS is
not authorized to give access to the interenet (the service requested in the
Access-Request).
It does NOT mean that the client cant continue talking with the NAS if the
NAS so chooses.  In other words, if for example there is a PPP session
between the client and the NAS, that PPP session is not dropped etc...

So perhaps rewording the IESG note to only indicate that the document is
including a VSA in an Access-Reject.  

A note to us in the IETF,  we need to allow VSA in an Access-Reject message.
There is no reason not to allow this attribute in an Access-Reject.
 
BTW in re-reading RFC 2869 I found a bug:

Section 2.3.2 states:

" This can be accomplished by inclusion of
   Session-Timeout and Password-Retry attributes within the Access-
   Challenge packet."
Yet in the table of attributes Password-Retry is listed as:

Request  Accept  Reject  Challenge   #    Attribute
0        0       0-1     0           75   Password-Retry 

> -----Original Message-----
> From: Frank Quick [mailto:[email-masked]] 
> Sent: Monday, March 07, 2005 2:20 PM
> To: W. Mark Townsley; [email-masked]
> Cc: 'Jari Arkko'; 'Nelson, David'; 'Barney Wolff'; 'Avi 
> Lior'; 'Thomas Narten'; 'Carroll, Christopher P.'; 
> [email-masked]; [email-masked]
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> I expect many of the participants in this thread are busy at 
> IETF, but I 
> will continue it anyway, expecting delays in some responses.
> 
> Looking at 2865 and 2869 this weekend:  I could not find any explicit 
> statement in 2865 that says the client MUST drop the 
> connection when an 
> Access-Reject is received.  Perhaps this is something that 
> was articulated 
> later?
> 
> In 2869, furthermore, there is a Password-Retry attribute 
> whose purpose is:
> 
>        This attribute MAY be included in an Access-Reject to 
> indicate how
>        many authentication attempts a user may be allowed to attempt
>        before being disconnected.
> 
> I don't see how this is fundamentally different from what we 
> do in DMU.
> 
> If there is no explicit requirement in 2865, then the 
> proposed disclaimer 
> language would be in error, since the only 2865 noncompliance 
> would be with 
> the prohibition of VSA in Access-Reject.
> 
> 
> Frank Quick
> office   +1-858-658-3608 fax +1-858-651-1940
> portable +1-619-890-5749
> paging   [email-masked]
> RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D
> 

--
to unsubscribe send 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: Mon, 07 Mar 2005 19:00:13 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Issue 69 (was Re: Access-Reject)
Date: Mon, 07 Mar 2005 13:54:56 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> Here is an simple example.  If an already authenticated user wants to
> establish a new call VoIP call etc... The NAS can then Authorize that call
> by issueing an Access-Request Authorize-Only.  No need to autenticate again
> right?

  Some comments, which are conceptual and not RADIUS-specific.

  1) The authorization request MUST be tied to a previous
authentication request.  If it is not, then we have the problem of
un-authenticated users being authorized to do something.  Users may
authenticate multiple sessions, so each authorization request MUST be
tied to a particular session, and not to a user.

  2) The authorization request itself MUST be authenticated.  This is
Bernard's comment in the issues page about using Message-Authenticator.

  3) The context of the authorization request MUST be interpreted as
what is being requested, and not any previous authentication or
authorization request.  e.g. User X authenticates, is authorized to do
X, Y, and Z.  He later requests authorization to do Q.  Any "yes/no"
response MUST be interpreted as meaning "yes/no" to do Q.  It MUST NOT
apply to the previously granted authorization.

  My reading of the above requirements in the light of RADIUS means
that implementing Authorize-Only semantics in Access-Requests may be
problematic.

  RADIUS does not have the concept of "authenticated sessions", so we
may use (for example) the "Class" attribute, as it's already used to
tie Accounting-Requests to previous Access-Requests.  Using Class to
tie Access-Requests together may have deployment issues.

  The Message-Authenticator attribute can address requirement (2).

  Requirement (3) means that the RADIUS server MAY have to keep track
of not only all user sessions, but all authorization data for all user
sessions.  Otherwise, if (in the above example) the user did not
originally request authorization to do "Q", he could later request it,
and possibly gain unintended authorization.  That is, the context of
authorization which permits/denies "Q" is the authorization to do "X,
Y, and Z", which itself may be time, resource, and location-dependent.

  So to answer Bernard's question: Yes, using Authorize-Only in an
Access-Request outside of the context of CoA-Request and
DisconnectRequest can be valid.  But we should highlight the issues,
so that any deployment is designed correctly.

  The Cisco TACACS+ command authorization example I discussed
previously is a narrowly scoped problem which can fit within the above
requirements.  As for others, I'm not sure.

  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: Mon, 07 Mar 2005 17:24:42 +0000
From: Avi Lior <[email-masked]>
To: Jari Arkko <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: RE: Issue 75: Why Not UTF-8 For Realm, Too?
Date: Mon, 7 Mar 2005 12:23:42 -0500 

Am I missing something?

We are already encoding the realm in UTF-8 and then moving to IDN encoding.
So I don't understand why not just keep it in UF-8 and let someone else do
the conversion to IDN when they need to do that conversion.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, March 07, 2005 5:16 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: Issue 75: Why Not UTF-8 For Realm, Too?
> 
> 
> I think there's more to it than just the encoding.
> Allowed characters, for instance. So if we use UTF-8
> we'd be saying "everything that is allowed in an IDN
> but represented in UTF-8 format". I'm not sure how
> easy that is.
> 
> --jari
> 
> Bernard Aboba wrote:
> 
> >Issue 75: Why Not UTF-8 For Realm, Too?
> >Submitter name: Avi Lior
> >Submitter email address: [email-masked]
> >Date first submitted: March 6, 2005
> >Reference:
> >Document: RFC2486bis
> >Comment type: T
> >Priority: S
> >Section:  Various
> >Rationale/Explanation of issue:
> >
> >When a RADIUS proxy undecorates the NAI, the current document may 
> >require translation when a realm name moves between the 
> userid portion 
> >and the realm portion. For example, when 
> >[email-masked] is redecorated to 
> [email-masked].  
> >In the fomer construction, intl_name.com is in UTF-8, and in 
> the later, 
> >intl_name.com needs to be translated to IDNA.
> >
> >Why not just specify the entire NAI in UTF-8? Then, say that 
> if a proxy 
> >needs to utilize the realm name within DNS, it will convert it to an 
> >IDN. Doesn't that make more sense? Existing link layers (e.g. EAP 
> >Request/Response-Identity messages) can carry UTF-8 just fine.
> >
> >
> >--
> >to unsubscribe send a message to [email-masked] with 
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
> >
> >
> >  
> >
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Mon, 07 Mar 2005 14:38:33 +0000
Date: Mon, 7 Mar 2005 06:37:59 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: Your audio is live (fwd)

---------- Forwarded message ----------
Date: Sun, 6 Mar 2005 13:11:20 -0800 (PST)
From: Ole Jacobsen <[email-masked]>
To: Working Group Chairs <[email-masked]>, BOF Chairs <[email-masked]>
Cc: Joel Jaeggli <[email-masked]>,
     Lucy E. Lynch <[email-masked]>
Subject: REMINDER: Your audio is live

I have been asked to remind WG and BOF Chairs that all of the meeting
rooms have audio streaming enabled this time.

Anyone at the mics should identify themselves for the listeing audience.

Keep in mind also that the mics are live most of the time, so don't sit
near one and chat atfer the meeting has ended unless you really want
the world to hear :-)

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Academic Research and Technology Initiatives, Cisco Systems
Tel: +1 408-527-8972   GSM: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

--
to unsubscribe send 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, 07 Mar 2005 10:16:43 +0000
Date: Mon, 07 Mar 2005 12:15:49 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 75: Why Not UTF-8 For Realm, Too?

I think there's more to it than just the encoding.
Allowed characters, for instance. So if we use UTF-8
we'd be saying "everything that is allowed in an IDN
but represented in UTF-8 format". I'm not sure how
easy that is.

--jari

Bernard Aboba wrote:

>Issue 75: Why Not UTF-8 For Realm, Too?
>Submitter name: Avi Lior
>Submitter email address: [email-masked]
>Date first submitted: March 6, 2005
>Reference:
>Document: RFC2486bis
>Comment type: T
>Priority: S
>Section:  Various
>Rationale/Explanation of issue:
>
>When a RADIUS proxy undecorates the NAI, the current document may require
>translation when a realm name moves between the userid portion and the
>realm portion. For example, when [email-masked]
>is redecorated to [email-masked].  In the fomer construction,
>intl_name.com is in UTF-8, and in the later, intl_name.com needs to
>be translated to IDNA.
>
>Why not just specify the entire NAI in UTF-8? Then, say that if a proxy
>needs to utilize the realm name within DNS, it will convert it to an IDN.
>Doesn't that make more sense? Existing link layers (e.g. EAP
>Request/Response-Identity messages) can carry UTF-8 just fine.
>
>
>--
>to unsubscribe send 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: Mon, 07 Mar 2005 07:16:49 +0000
Date: Sun, 6 Mar 2005 23:16:36 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 75: Why Not UTF-8 For Realm, Too?

Issue 75: Why Not UTF-8 For Realm, Too?
Submitter name: Avi Lior
Submitter email address: [email-masked]
Date first submitted: March 6, 2005
Reference:
Document: RFC2486bis
Comment type: T
Priority: S
Section:  Various
Rationale/Explanation of issue:

When a RADIUS proxy undecorates the NAI, the current document may require
translation when a realm name moves between the userid portion and the
realm portion. For example, when [email-masked]
is redecorated to [email-masked].  In the fomer construction,
intl_name.com is in UTF-8, and in the later, intl_name.com needs to
be translated to IDNA.

Why not just specify the entire NAI in UTF-8? Then, say that if a proxy
needs to utilize the realm name within DNS, it will convert it to an IDN.
Doesn't that make more sense? Existing link layers (e.g. EAP
Request/Response-Identity messages) can carry UTF-8 just fine.

--
to unsubscribe send 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, 07 Mar 2005 07:05:33 +0000
Date: Sun, 6 Mar 2005 23:04:55 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADIUS location Issues tracking

I've opened issues 70-74 to track the Hannes' recent suggested resolution
postings.  I believe these issues were originally referred to in Issue 26,
so I've separated those issues out in order to allow them to be discussed
separately.

Here is the current issue list:
http://www.drizzle.com/~aboba/RADEXT/

If there is something missing, let me know.

--
to unsubscribe send 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, 06 Mar 2005 19:32:04 +0000
Content-class: urn:content-classes:message
Subject: RE: ISSUE: Use of RADIUS in non-layer-2 sessions.
Date: Sun, 6 Mar 2005 21:16:39 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Alan,

I just gave your text a quick read, and I am basically supportive of
this.  I know it goes against some existing deployments of RADIUS,
but interoperability can be helped, based upon this text.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Alan DeKok
> Sent: 06 March, 2005 19:25
> To: [email-masked]
> Subject: ISSUE: Use of RADIUS in non-layer-2 sessions.
>=20
>=20
> Description: Use of RADIUS on non-layer-2 sessions
> Submitter name: Alan DeKok
> Submitter email address: [email-masked]
> Date first submitted: March 6, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00228.html
> Document: "issues and fixes" draft
> Comment type: T
> Priority: 1
> Section:
> Rationale/Explanation of issue:
>=20
>   RADIUS is being deployed in situations where it is performing
> authentication and authorization for access other than layer 2
> connections.  e.g. web/ftp servers, user login authentication, etc.
> All of these "sessions" have clear start, stop, and authorization
> semantics.  These semantics can often be represented within the
> existing RADIUS packet and attribute encapsulations.  However, these
> deployments are outside of the scope of the RADIUS standard, and any
> interpretation of RADIUS within those contexts is
> implementation-defined.  In order to guide implementors in the design
> and use of RADIUS in novel deployments, we offer the text below.
>=20
> Requested change: use suggested text
>=20
>     The RADIUS specification [rfc's] is defined in reference to dialin
>     authentication, layer 2 connections, and user "sessions" are
>     discussed within that context.  RADIUS has been deployed, however,
>     in the context of other layers and sessions where user
>     authentication, authorization, and accounting is desired.  For
>     example, existing deployments use RADIUS as a "back-end" for
>     authenticating VOIP connections [digest], HTTP sessions [apache],
>     FTP sessions [proftpd], and machine logins for multiple operating
>     systems [bsdi, pam, gina].  In those contexts, the implementation
>     MUST interpret the RADIUS specification as narrowly as possible,
>     within the scope of the client-server model as described in
>     RADIUS [RFC 2865] Section 1:
>=20
>   <quote>
>    Client/Server Model
>=20
>       A Network Access Server (NAS) operates as a client of=20
> RADIUS.  The
>       client is responsible for passing user information to designated
>       RADIUS servers, and then acting on the response which=20
> is returned.
>=20
>       RADIUS servers are responsible for receiving user connection
>       requests, authenticating the user, and then returning all
>       configuration information necessary for the client to deliver
>       service to the user.
>=20
>       A RADIUS server can act as a proxy client to other=20
> RADIUS servers
>       or other kinds of authentication servers.
>    </quote>
>=20
>     Any deployment of RADIUS outside of the scope of dialin
>     authentication MUST therefore interpret RADIUS within the context
>     of the service that the RADIUS client is delivering to the user
>     who is requesting authentication, authorization, and accounting.
>     For example, an Access-Reject sent to the client MUST be
>     interpreted by the client as a rejection of the users request for
>     service, and the client MUST no longer offer that service to the
>     user.
>=20
>     The definition of the "service" being offered is a complex
>     one, and should be interpreted as narrowly as possible within the
>     context of the intended deployment.
>=20
>     For example, when an authentication failure occurs in the context
>     of an FTP session, the normal semantics for rejecting FTP services
>     apply.  The rejection does not necessarily cause the FTP server to
>     terminate the underlying TCP connection, but the FTP server MUST
>     NOT offer any services protected by user authentication.
>=20
>     We note also that users may use RADIUS to request multiple
>     services from the NAS.  Where those services are independent, the
>     deployment MUST treat the RADIUS sessions as being independent.
>=20
>     For example, a NAS may offer multi-link services, where a user may
>     have multiple simultaneous layer 2 connections.  In that case, an
>     Access-Reject for a later multi-link connection request does not
>     necessarily mean that earlier multi-link connections are torn
>     down.  Similarly, if a NAS offers both dialup and VOIP services,
>     the rejection of a VOIP attempt does not mean that the dialup
>     session is torn down.
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Sun, 06 Mar 2005 17:28:57 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: 
Subject: ISSUE: Use of RADIUS in non-layer-2 sessions.
Message-Id: <[email-masked]>
Date: Sun,  6 Mar 2005 12:24:30 -0500 (EST)

Description: Use of RADIUS on non-layer-2 sessions
Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: March 6, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00228.html
Document: "issues and fixes" draft
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

  RADIUS is being deployed in situations where it is performing
authentication and authorization for access other than layer 2
connections.  e.g. web/ftp servers, user login authentication, etc.
All of these "sessions" have clear start, stop, and authorization
semantics.  These semantics can often be represented within the
existing RADIUS packet and attribute encapsulations.  However, these
deployments are outside of the scope of the RADIUS standard, and any
interpretation of RADIUS within those contexts is
implementation-defined.  In order to guide implementors in the design
and use of RADIUS in novel deployments, we offer the text below.

Requested change: use suggested text

    The RADIUS specification [rfc's] is defined in reference to dialin
    authentication, layer 2 connections, and user "sessions" are
    discussed within that context.  RADIUS has been deployed, however,
    in the context of other layers and sessions where user
    authentication, authorization, and accounting is desired.  For
    example, existing deployments use RADIUS as a "back-end" for
    authenticating VOIP connections [digest], HTTP sessions [apache],
    FTP sessions [proftpd], and machine logins for multiple operating
    systems [bsdi, pam, gina].  In those contexts, the implementation
    MUST interpret the RADIUS specification as narrowly as possible,
    within the scope of the client-server model as described in
    RADIUS [RFC 2865] Section 1:

  <quote>
   Client/Server Model

      A Network Access Server (NAS) operates as a client of RADIUS.  The
      client is responsible for passing user information to designated
      RADIUS servers, and then acting on the response which is returned.

      RADIUS servers are responsible for receiving user connection
      requests, authenticating the user, and then returning all
      configuration information necessary for the client to deliver
      service to the user.

      A RADIUS server can act as a proxy client to other RADIUS servers
      or other kinds of authentication servers.
   </quote>

    Any deployment of RADIUS outside of the scope of dialin
    authentication MUST therefore interpret RADIUS within the context
    of the service that the RADIUS client is delivering to the user
    who is requesting authentication, authorization, and accounting.
    For example, an Access-Reject sent to the client MUST be
    interpreted by the client as a rejection of the users request for
    service, and the client MUST no longer offer that service to the
    user.

    The definition of the "service" being offered is a complex
    one, and should be interpreted as narrowly as possible within the
    context of the intended deployment.

    For example, when an authentication failure occurs in the context
    of an FTP session, the normal semantics for rejecting FTP services
    apply.  The rejection does not necessarily cause the FTP server to
    terminate the underlying TCP connection, but the FTP server MUST
    NOT offer any services protected by user authentication.

    We note also that users may use RADIUS to request multiple
    services from the NAS.  Where those services are independent, the
    deployment MUST treat the RADIUS sessions as being independent.

    For example, a NAS may offer multi-link services, where a user may
    have multiple simultaneous layer 2 connections.  In that case, an
    Access-Reject for a later multi-link connection request does not
    necessarily mean that earlier multi-link connections are torn
    down.  Similarly, if a NAS offers both dialup and VOIP services,
    the rejection of a VOIP attempt does not mean that the dialup
    session is torn down.

  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: Sun, 06 Mar 2005 16:54:28 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Access-Reject (was RE: Comments on draft-carroll-dynmobileip- cdma -04.txt) 
Cc: Avi Lior <[email-masked]>, Bernard Aboba <[email-masked]>
Date: Sun, 06 Mar 2005 11:49:29 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> No.  That is the problem we are now facing. Authorize-Only messages maybe
> sent by the NAS without receiving a CoA.
> This makes perfect sense.

  ... outside of the scope of RFC 3576, where meaning is
implementation-defined.

> Here is an simple example.  If an already authenticated user wants to
> establish a new call VoIP call etc... The NAS can then Authorize that call
> by issueing an Access-Request Authorize-Only.  No need to autenticate again
> right?

  I can see that.  But the more I think about it, the more I believe
that "Authorize-Only" is inappropriate in this context.  I'll continue
that discussion elsewhere, though.

  RADIUS is being deployed in situations where it is performing
authentication and authorization for access *other* than layer 2
connections.  e.g. web/ftp servers, user login authentication, etc.
All of these "sessions" have clear start, stop, and authorization
semantics.  These semantics can often be represented within the
existing RADIUS packet and attribute encapsulations.

  My suggestion for the "issues and fixes" document is the following
text:

    The RADIUS specification [rfc's] is defined in reference to dialin
    authentication, layer 2 connections, and user "sessions" are
    discussed within that context.  RADIUS has been deployed, however,
    in the context of other layers and sessions where user
    authentication, authorization, and accounting is desired.  For
    example, existing deployments use RADIUS as a "back-end" for
    authenticating VOIP connections [digest], HTTP sessions [apache],
    FTP sessions [proftpd, and machine logins for multiple operating
    systems [bsdi, pam, gina].  In those contexts, the implementation
    MUST interpret the RADIUS specification as narrowly as possible,
    within the scope of the client-server model as described in
    RADIUS [RFC 2865] Section 1:

  <quote>
   Client/Server Model

      A Network Access Server (NAS) operates as a client of RADIUS.  The
      client is responsible for passing user information to designated
      RADIUS servers, and then acting on the response which is returned.

      RADIUS servers are responsible for receiving user connection
      requests, authenticating the user, and then returning all
      configuration information necessary for the client to deliver
      service to the user.

      A RADIUS server can act as a proxy client to other RADIUS servers
      or other kinds of authentication servers.
   </quote>

    Any deployment of RADIUS outside of the scope of dialin
    authentication MUST therefore interpret RADIUS within the context
    of the service that the RADIUS client is delivering to the user
    who is requesting authentication, authorization, and accounting.
    For example, an Access-Reject sent to the client MUST be
    interpreted by the client as a rejection of the users request for
    service, and the client MUST no longer offer that service to the
    user.  In the deployments listed above, this rejection will mean
    termination of a VOIP call, TCP connection, or user login session.

  I'll resubmit this using the ISSUES format.

  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: Sun, 06 Mar 2005 02:30:41 +0000
From: Avi Lior <[email-masked]>
To: Bernard Aboba <[email-masked]>, Avi Lior <[email-masked]>
Cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: Access-Reject (was RE: Comments on draft-carroll-dynmobileip- cdma -04.txt)
Date: Sat, 5 Mar 2005 21:30:14 -0500 

Hi Bernard,

See inline please.  I have comments throughout.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Saturday, March 05, 2005 5:27 PM
> To: Avi Lior
> Cc: Alan DeKok; [email-masked]
> Subject: Re: Access-Reject (was RE: Comments on 
> draft-carroll-dynmobileip-cdma -04.txt)
> 
> 
> > But if the server which just received an Authorize-Only 
> packet didn't
> want
> > to do the re-authorization requested?
> 
> "Authorize Only" Access-Requests are only generated as the 
> result of a CoA-Request or Disconnect-Request, right?  So 
> presumably the server that initiated the request had an idea 
> that it wanted a re-authorization, no?

No.  That is the problem we are now facing. Authorize-Only messages maybe
sent by the NAS without receiving a CoA.
This makes perfect sense.

Here is an simple example.  If an already authenticated user wants to
establish a new call VoIP call etc... The NAS can then Authorize that call
by issueing an Access-Request Authorize-Only.  No need to autenticate again
right?

Prepaid does that as well.  Send an Access-Request Authorize-Only to get
more quota. No need to Authenticate again right?

So in the context of these example it would be reasonable to allow for an
Access-Reject to mean that the AAA rejects to Authorize right?

Note in prepaid we return an Access-Accept with a quota which indicates no
more resources (so I don't use Access-Reject).  So likewise we can use the
same for the first example. But Access-Reject ought to work just as well.
In fact, philosophically returning something in Access-Accept to indicate
that "you can't do what you asked for" is like returning EAP-Failure in an
Access-Accept -not a good idea(see good discussion on this later).

> > It could send an Access-Reject if we allow the 
> Access-Reject to mean I 
> > don't want to re-authorize.  Full stop.
> >
> > Failing that, it will have to send an Access-Accept with _all_ the 
> > previously sent authorization attributes.
> 
> Isn't it likely that an RFC 3576 implementation would have 
> stored those attributes anyway?  Or are there circumstances 
> where it might not do that?

3576 requires a very small set of attribute to be stored.  If I have to
store everything that would be harder.   I sort of eluded to this many time
before.  

> > I can live with the traditional meaning of Access-Reject, but I do 
> > have issues with how we make it easier and more realistic 
> to develop 
> > RADIUS extensions.
> 
> I think that's more of a RADEXT charter issue, no?  Or are 
> you saying we need to build more extensibility into the 
> protocol itself?

I think we need to address what is coming up on us.  SO mulitple
Authorization per session for different reasons:
-authorization for new flows (voip);
-prepaid quota management;
-authorization for services such as one-time-events introduce by Diameter
prepaid and RADIUS prepaid;
-etc...

> > Also related to this discussion - I ran into this in Pana : 
> > pana-pana-07
> >
> >    "Within separate NAP and ISP authentication, the NAP 
> authentication
> >    and the ISP authentication are considered completely independent.
> >    Presence or success of one should not effect the other.  Making a
> >    network access authorization decision based on the 
> success or failure
> >    of each authentication is a network policy issue."
> >
> > If EAP-failure can only be carried in an Access-Reject then 
> if one of 
> > these enetities rejects the authentication, and the other 
> accepts the 
> > authentication we can get into a situation where: NAS receives an 
> > Access-Accept NAS receives an Access-Reject
> > And the session is allowed to go on.
> 
> RFC 3579 states that the RADIUS command determines the 
> outcome, not the embedded EAP packet (Success/Failure).  So 
> an Access-Reject always results in denying access, even 
> though the RADIUS server might succeed in confusing the EAP 
> peer by sending an Access-Reject/EAP-Success.
> 
> Here's what RFC 3579, Section 2.6.3 says:

Yes I re-read that just before I sent the last message.
It is a problem. We need to address it.  
If I send the EAP failure in an Access-Reject, then the session is dead.
If I send the EAP failure in an Access-Accept, then I am also stuck.
Although this is not strictly prohibited in 3579!!!

So either PANA folks are missing something or we AAA folks (RADIUS and
DIAMETER) have to re-think our view of reality.
I would like to chat about this further with you and any interested people.
I raised this as an issue in my RADIUS-PANA draft.
 
> 2.6.3.  Conflicting Messages
> 
>    The NAS MUST make its access control decision based solely on the
>    RADIUS Packet Type (Access-Accept/Access-Reject).  The 
> access control
>    decision MUST NOT be based on the contents of the EAP packet
>    encapsulated in one or more EAP-Message attributes, if present.
> 
>    Access-Accept packets SHOULD have only one EAP-Message attribute in
>    them, containing EAP Success; similarly, Access-Reject 
> packets SHOULD
>    have only one EAP-Message attribute in them, containing 
> EAP Failure.
> 
>    Where the encapsulated EAP packet does not match the result implied
>    by the RADIUS Packet Type, the combination is likely to cause
>    confusion, because the NAS and peer will arrive at different
>    conclusions as to the outcome of the authentication.
> 
>    For example, if the NAS receives an Access-Reject with an
>    encapsulated EAP Success, it will not grant access to the peer.
>    However, on receiving the EAP Success, the peer will be lead to
>    believe that it authenticated successfully.
> 
>    If the NAS receives an Access-Accept with an encapsulated EAP
>    Failure, it will grant access to the peer.  However, on 
> receiving an
>    EAP Failure, the peer will be lead to believe that it failed
>    authentication.  If no EAP-Message attribute is included within an
>    Access-Accept or Access-Reject, then the peer may not be 
> informed as
>    to the outcome of the authentication, while the NAS will 
> take action
>    to allow or deny access.
> 
>    As described in [RFC2284], the EAP Success and Failure packets are
>    not acknowledged, and these packets terminate the EAP conversation.
>    As a result, if these packets are encapsulated within an
>    Access-Challenge, no response will be received, and 
> therefore the NAS
>    will send no further Access-Requests to the RADIUS server for the
>    session.  As a result, the RADIUS server will not indicate 
> to the NAS
>    whether to allow or deny access, while the peer will be informed as
>    to the outcome of the authentication.
> 
>    To avoid these conflicts, the following combinations SHOULD NOT be
>    sent by a RADIUS server:
> 
>       Access-Accept/EAP-Message/EAP Failure
>       Access-Accept/no EAP-Message attribute
>       Access-Accept/EAP-Start
>       Access-Reject/EAP-Message/EAP Success
>       Access-Reject/no EAP-Message attribute
>       Access-Reject/EAP-Start
>       Access-Challenge/EAP-Message/EAP Success
>       Access-Challenge/EAP-Message/EAP Failure
>       Access-Challenge/no EAP-Message attribute
>       Access-Challenge/EAP-Start
> 
>    Since the responsibility for avoiding conflicts lies with 
> the RADIUS
>    server, the NAS MUST NOT "manufacture" EAP packets in order to
>    correct contradictory messages that it receives.  This behavior,
>    originally mandated within [IEEE8021X], will be deprecated in the
>    future.
> 

--
to unsubscribe send 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, 05 Mar 2005 23:27:56 +0000
Date: Sat, 5 Mar 2005 15:27:32 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Slides, please. 

If you're going to be presenting at the RADEXT WG meeting at IETF 62,
please send your slides to myself and Dave ASAP.

thanks!

--
to unsubscribe send 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, 05 Mar 2005 22:27:23 +0000
Date: Sat, 5 Mar 2005 14:27:04 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: Re: Access-Reject (was RE: Comments on draft-carroll-dynmobileip-cdma -04.txt)

> But if the server which just received an Authorize-Only packet didn't
want
> to do the re-authorization requested?

"Authorize Only" Access-Requests are only generated as the result of a
CoA-Request or Disconnect-Request, right?  So presumably the server that
initiated the request had an idea that it wanted a re-authorization, no?

> It could send an Access-Reject if we allow the Access-Reject to mean I
> don't want to re-authorize.  Full stop.
>
> Failing that, it will have to send an Access-Accept with _all_ the
> previously sent authorization attributes.

Isn't it likely that an RFC 3576 implementation would have stored those
attributes anyway?  Or are there circumstances where it might not do
that?

> I can live with the traditional meaning of Access-Reject, but I do have
> issues with how we make it easier and more realistic to develop RADIUS
> extensions.

I think that's more of a RADEXT charter issue, no?  Or are you saying we
need to build more extensibility into the protocol itself?

> Also related to this discussion - I ran into this in Pana : pana-pana-07
>
>    "Within separate NAP and ISP authentication, the NAP authentication
>    and the ISP authentication are considered completely independent.
>    Presence or success of one should not effect the other.  Making a
>    network access authorization decision based on the success or failure
>    of each authentication is a network policy issue."
>
> If EAP-failure can only be carried in an Access-Reject then if one of
> these enetities rejects the authentication, and the other accepts the
> authentication we can get into a situation where:
> NAS receives an Access-Accept
> NAS receives an Access-Reject
> And the session is allowed to go on.

RFC 3579 states that the RADIUS command determines the outcome, not the
embedded EAP packet (Success/Failure).  So an Access-Reject always results
in denying access, even though the RADIUS server might succeed in
confusing the EAP peer by sending an Access-Reject/EAP-Success.

Here's what RFC 3579, Section 2.6.3 says:

2.6.3.  Conflicting Messages

   The NAS MUST make its access control decision based solely on the
   RADIUS Packet Type (Access-Accept/Access-Reject).  The access control
   decision MUST NOT be based on the contents of the EAP packet
   encapsulated in one or more EAP-Message attributes, if present.

   Access-Accept packets SHOULD have only one EAP-Message attribute in
   them, containing EAP Success; similarly, Access-Reject packets SHOULD
   have only one EAP-Message attribute in them, containing EAP Failure.

   Where the encapsulated EAP packet does not match the result implied
   by the RADIUS Packet Type, the combination is likely to cause
   confusion, because the NAS and peer will arrive at different
   conclusions as to the outcome of the authentication.

   For example, if the NAS receives an Access-Reject with an
   encapsulated EAP Success, it will not grant access to the peer.
   However, on receiving the EAP Success, the peer will be lead to
   believe that it authenticated successfully.

   If the NAS receives an Access-Accept with an encapsulated EAP
   Failure, it will grant access to the peer.  However, on receiving an
   EAP Failure, the peer will be lead to believe that it failed
   authentication.  If no EAP-Message attribute is included within an
   Access-Accept or Access-Reject, then the peer may not be informed as
   to the outcome of the authentication, while the NAS will take action
   to allow or deny access.

   As described in [RFC2284], the EAP Success and Failure packets are
   not acknowledged, and these packets terminate the EAP conversation.
   As a result, if these packets are encapsulated within an
   Access-Challenge, no response will be received, and therefore the NAS
   will send no further Access-Requests to the RADIUS server for the
   session.  As a result, the RADIUS server will not indicate to the NAS
   whether to allow or deny access, while the peer will be informed as
   to the outcome of the authentication.

   To avoid these conflicts, the following combinations SHOULD NOT be
   sent by a RADIUS server:

      Access-Accept/EAP-Message/EAP Failure
      Access-Accept/no EAP-Message attribute
      Access-Accept/EAP-Start
      Access-Reject/EAP-Message/EAP Success
      Access-Reject/no EAP-Message attribute
      Access-Reject/EAP-Start
      Access-Challenge/EAP-Message/EAP Success
      Access-Challenge/EAP-Message/EAP Failure
      Access-Challenge/no EAP-Message attribute
      Access-Challenge/EAP-Start

   Since the responsibility for avoiding conflicts lies with the RADIUS
   server, the NAS MUST NOT "manufacture" EAP packets in order to
   correct contradictory messages that it receives.  This behavior,
   originally mandated within [IEEE8021X], will be deprecated in the
   future.

--
to unsubscribe send 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, 05 Mar 2005 21:37:52 +0000
From: Avi Lior <[email-masked]>
To: Bernard Aboba <[email-masked]>, Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Access-Reject (was RE: Comments on draft-carroll-dynmobileip-cdma -04.txt)
Date: Sat, 5 Mar 2005 16:37:17 -0500 

Hi Bernard,

> After all, if the server just wanted to modify the 
> authorizations, it could respond with an Access-Accept and 
> the new authorizations.  So sending an Access-Reject is an 
> explicit choice.

But if the server which just received an Authorize-Only packet didn't want
to do the re-authorization requested?

It could send an Access-Reject if we allow the Access-Reject to mean I don't
want to re-authorize.  Full stop.

Failing that, it will have to send an Access-Accept with _all_ the
previously sent authorization attributes.

My concern is that this behaviour while was good enough for simple
deployments, makes it difficult to build new extensions to RADIUS.

I can live with the traditional meaning of Access-Reject, but I do have
issues with how we make it easier and more realistic to develop RADIUS
extnesions.

Also related to this discussion - I ran into this in Pana : pana-pana-07

   "Within separate NAP and ISP authentication, the NAP authentication
   and the ISP authentication are considered completely independent.
   Presence or success of one should not effect the other.  Making a
   network access authorization decision based on the success or failure
   of each authentication is a network policy issue."

If EAP-failure can only be carried in an Access-Reject then if one of 
these enetities rejects the authentication, and the other accepts the 
authentication we can get into a situation where:
NAS receives an Access-Accept
NAS receives an Access-Reject
And the session is allowed to go on.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, March 04, 2005 6:00 PM
> To: Alan DeKok
> Cc: [email-masked]
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> 
> 
> On Fri, 4 Mar 2005, Alan DeKok wrote:
> 
> > Avi Lior <[email-masked]> wrote:
> > > Access-Reject may not always result in the termination of 
> a session 
> > > etc...
> > >
> > > For example, when I am doing authorize only, (Access-Accept with 
> > > Service-Type = Authorize-Only) the Access-Reject is a 
> rejection of 
> > > that authorization and not necessarily the rejection of 
> the entire 
> > > session or service.  Or is it?
> 
> I believe it represents a request to terminate the session.  
> RFC 3576, Section 1.1 states:
> 
> "   To simplify translation between RADIUS and Diameter, a 
> Service-Type
>    Attribute with value "Authorize Only" can (optionally) be included
>    within a Disconnect-Request or CoA-Request.  Such a 
> Request contains
>    only identification attributes.  A NAS supporting the "Authorize
>    Only" Service-Type within a Disconnect-Request or CoA-Request
>    responds with a NAK containing a Service-Type Attribute with value
>    "Authorize Only" and an Error-Cause Attribute with value "Request
>    Initiated".  The NAS will then send an Access-Request containing a
>    Service-Type Attribute with a value of "Authorize Only".  
> This usage
>    sequence is akin to what occurs in Diameter and so is more easily
>    translated by a Diameter/RADIUS gateway."
> 
> Note that while a CoA-NAK or Disconnect-NAK indicates no 
> change in state on the client, once an Access-Request is sent 
> with "Authorize Only" the semantics of conventional responses 
> applies -- Access-Challenge, Access-Accept and Access-Reject.
> 
> That is, I believe that the NAS interprets an Access-Reject 
> as terminating the session, regardless of whether the 
> Service-Type=Authorize Only in the Request.
> 
> After all, if the server just wanted to modify the 
> authorizations, it could respond with an Access-Accept and 
> the new authorizations.  So sending an Access-Reject is an 
> explicit choice.
> 
> >   It's at least a rejection of what they asked for.  For 
> > Authorize-Only, the semantics of the Access-Reject should 
> clearly be 
> > that the authorization failed.
> 
> It implies that the session is no longer authorized -- 
> therefore it is to be terminated.
> 
> >   e.g. Cisco TACACS-style command authorization.  A request for 
> > authorization of a command may be "rejected", but the 
> admins session 
> > will remain active, because no session information was sent in the 
> > request.
> 
> In RADIUS, the way to accomplish this is to send an 
> Access-Accept with the same authorizations as was sent before.
> 
> 
> --
> to unsubscribe send 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: Sat, 05 Mar 2005 12:58:39 +0000
Date: Sat, 05 Mar 2005 14:57:45 +0200
From: Jari Arkko <[email-masked]>
To: "W. Mark Townsley" <[email-masked]>
Cc: [email-masked], 'Frank Quick' <[email-masked]>, "'Nelson, David'" <[email-masked]>, 'Barney Wolff' <[email-masked]>, 'Avi Lior' <[email-masked]>, 'Thomas Narten' <[email-masked]>, "'Carroll, Christopher P.'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt

Hi Mark,

I think that adding some history or context to the note, as you suggest 
below,
would be useful in any case.

--Jari

W. Mark Townsley wrote:

>
> Perhaps including text that the document was not adequately reviewed 
> in a timely manner by the IETF before deployment would help displace 
> the author blame/punishment that Jari is concerned about? Then, could 
> we use the harsher language?
>
> I'm afraid that if we stick to the more light/diplomatic speak the 
> message we are trying to convey will be lost in the numbers and 
> indirection. That is, the uninformed reader (which is the one we are 
> targeting with this note) might not realize that something along the 
> lines of "is not consistent with RFC XXXX" is anything they should be 
> worried about or not. Such a statement really only speaks in any 
> obvious way to those who (1) know what RFC XXXX is, and (2) that being 
> inconsistent with it is something that the IETF is concerned about.
>

--
to unsubscribe send 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, 05 Mar 2005 04:20:56 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Jari Arkko'" <[email-masked]>, "'Frank Quick'" <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, "'Barney Wolff'" <[email-masked]>, "'Avi Lior'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, "'Carroll, Christopher P.'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Fri, 4 Mar 2005 20:19:46 -0800

Jari Arkko <mailto:[email-masked]> supposedly scribbled:

> Frank Quick wrote:
>=20
>> And I think "is not consistent with" is entirely accurate, if
perhaps
>> less blunt.  If the purpose is to inform the reader, rather than
to
>> punish the authors, then the less blunt wording should be
sufficient.
>> I'd also accept "not compliant with" if you prefer.
>=20
> I have some sympathy for this. Its excellent if we agree about the
> technical part of the note (or will come to an agreement at
least).=20
> But the note should not "punish the authors". Lets use less
> emotionally charged words, "violate" may not be very good. But "is
> not consistent" doesn't quite do the job for me either. Perhaps
"not
> compliant with RFC XXXX" is the right, objective expression here.

I'm a little confused here: we have Dave trying to give the benefit
of the doubt, assigning this to ignorance, Avi saying "no, it was
deliberate", and Jari wishing to avoid "punishing the authors".
What's so "emotionally charged" and/or punitive about the word
"violate"?  Three definitions:

violate

v 1: fail to agree with; be in violation of; as of rules or
patterns; "This sentence violates the rules of syntax" [syn: go
against, break] [ant: conform to]=20

Main Entry: vi=B7o=B7late
Pronunciation: 'vI-&-"lAt
Function: transitive verb
Inflected Forms: -lat=B7ed; -lat=B7ing
: to go against (as a prohibition or principle) : fail to observe or
respect <violate a law> <civil rights were violated> <violate due
process>=20

Violate

To break or disregard (a law or promise, for example).=20

All of these definitions seem to state rather precisely what has
happened here (intentionally, if Avi is correct).  Perhaps the
authors expect to be praised for disregarding IETF standards?

>=20
> --Jari

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message to [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, 05 Mar 2005 00:34:32 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Date: Fri, 04 Mar 2005 19:29:09 -0500
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> Note that while a CoA-NAK or Disconnect-NAK indicates no change in state
> on the client, once an Access-Request is sent with "Authorize Only" the
> semantics of conventional responses applies -- Access-Challenge,
> Access-Accept and Access-Reject.

  I agree.  However, once an extension like Authorize-Only is added to
a protocol, it will be (ab)used in ways the designers never intended.

> That is, I believe that the NAS interprets an Access-Reject as terminating
> the session, regardless of whether the Service-Type=Authorize Only in the
> Request.

  According to RFC 3576, yes.  Implementations which are not using RFC
3576 CoA requests may still choose to use Authorize-Only.  In that
case, any meaning is implementation-defined.

> >   e.g. Cisco TACACS-style command authorization.  A request for
> > authorization of a command may be "rejected", but the admins session
> > will remain active, because no session information was sent in the request.
> 
> In RADIUS, the way to accomplish this is to send an Access-Accept with the
> same authorizations as was sent before.

  i.e. You're saying that the NAS re-sends an Access-Request for the
"session", when the administrator types a new command, and obtains an
Access-Accept with authorization for that "session".  I'm not sure why
this would be useful.  If an Access-Accept contains full authorization
for all administrator activities, there would be no need to any later
Access-Request to obtain additional authorization for that session.
The NAS would already have the complete list.

  However, a complete list of commands the admin is authorized to run
may be large.  That was the reason the individual commands were
dynamically authorized in TACACS+.  Such a list could also not fit
into one RADIUS packet, making it more useful to dynamically authorize
each command.

  In that case, the following two questions are disjoint:

  1) Is this administrator permitted to log in to this box?
  2) Is this administrator permitted to run this command?

  While (1) is a pre-requisite for (2) to be asked, I don't see why a
"no" answer to (2) would mean that the administrator is logged off.  I
can run "rm /etc/passwd" as a normal user without the system logging
me off.

  In this context, question (2) can be thought of as requesting a new
session, with new authorization parameters.  The two sessions are
logically separate, and can be treated that way by the NAS.
e.g. Using RADIUS authentiction for Unix logins.  I can log in as
myself, "su" to root, and get an Access-Reject for that "su" login
request.  But my personal session isn't logged off.  This is the exact
model used for Cisco TACACS+ command authentication.

  The concept of one user requesting two independent sessions from a
RADIUS client is not one which is widely used in RADIUS.  But I don't
see how the protocol forbids 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, 04 Mar 2005 23:00:44 +0000
Date: Fri, 4 Mar 2005 15:00:28 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt 

On Fri, 4 Mar 2005, Alan DeKok wrote:

> Avi Lior <[email-masked]> wrote:
> > Access-Reject may not always result in the termination of a session etc...
> >
> > For example, when I am doing authorize only, (Access-Accept with
> > Service-Type = Authorize-Only) the Access-Reject is a rejection of that
> > authorization and not necessarily the rejection of the entire session or
> > service.  Or is it?

I believe it represents a request to terminate the session.  RFC 3576,
Section 1.1 states:

"   To simplify translation between RADIUS and Diameter, a Service-Type
   Attribute with value "Authorize Only" can (optionally) be included
   within a Disconnect-Request or CoA-Request.  Such a Request contains
   only identification attributes.  A NAS supporting the "Authorize
   Only" Service-Type within a Disconnect-Request or CoA-Request
   responds with a NAK containing a Service-Type Attribute with value
   "Authorize Only" and an Error-Cause Attribute with value "Request
   Initiated".  The NAS will then send an Access-Request containing a
   Service-Type Attribute with a value of "Authorize Only".  This usage
   sequence is akin to what occurs in Diameter and so is more easily
   translated by a Diameter/RADIUS gateway."

Note that while a CoA-NAK or Disconnect-NAK indicates no change in state
on the client, once an Access-Request is sent with "Authorize Only" the
semantics of conventional responses applies -- Access-Challenge,
Access-Accept and Access-Reject.

That is, I believe that the NAS interprets an Access-Reject as terminating
the session, regardless of whether the Service-Type=Authorize Only in the
Request.

After all, if the server just wanted to modify the authorizations, it
could respond with an Access-Accept and the new authorizations.  So
sending an Access-Reject is an explicit choice.

>   It's at least a rejection of what they asked for.  For
> Authorize-Only, the semantics of the Access-Reject should clearly be
> that the authorization failed.

It implies that the session is no longer authorized -- therefore it is to
be terminated.

>   e.g. Cisco TACACS-style command authorization.  A request for
> authorization of a command may be "rejected", but the admins session
> will remain active, because no session information was sent in the request.

In RADIUS, the way to accomplish this is to send an Access-Accept with the
same authorizations as was sent before.

--
to unsubscribe send 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, 04 Mar 2005 22:50:00 +0000
Date: Fri, 4 Mar 2005 14:48:58 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Meaning of Acess-Reject (was RE: Comments on draft-carroll-dynmobileip-cdma-04.txt)

> We could have this discussion, and raise an issue relating to any
> existing deployments, as part of the RADIUS Issues and Fixes draft.  I
> think it would be a very bad idea indeed to change something as
> fundamental as the semantics of a RADIUS Access-Reject to *ever* mean
> anything other than a termination of NAS service and a termination of
> the session (e.g. layer 2 connection) for the attached network host.

Since there appears to be some confusion on this point, it seems like fair
game for "issues and fixes".

--
to unsubscribe send 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, 04 Mar 2005 20:14:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Fri, 4 Mar 2005 15:13:31 -0500
From: "Nelson, David" <[email-masked]>
To: "Frank Quick" <[email-masked]>, "Jari Arkko" <[email-masked]>
Cc: "Barney Wolff" <[email-masked]>, <[email-masked]>, "Avi Lior" <[email-masked]>, "Thomas Narten" <[email-masked]>, "W. Mark Townsley" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, <[email-masked]>, <[email-masked]>

> It's also been suggested that Access-Request must be integrity
protected
> and authenticated per RFC 2865.  The draft doesn't explicitly require
it,
> but it doesn't preclude it, either; it just says the topic is outside
the
> scope of the document.  I wouldn't have a problem with adding
something to
> 7.9 referencing the requirements of RFC 2865, but I'm having trouble
> finding the right part to reference.  The word "integrity" doesn't
seem to
> appear in the RFC.

RFC 2865 describes the usage of Request-Authenticator and
Response-Authenticator fields to provide some level of message (protocol
payload) integrity protection for messages that contain the User-Name
and User-Password attributes and uses the Message-Authenticator
attribute for messages that contain EAP-Messages or
CHAP-Challenge/CHAP-Password.

The relevant section of RFC 2865 is:

Authenticator

      The Authenticator field is sixteen (16) octets.  The most
      significant octet is transmitted first.  This value is used to
      authenticate the reply from the RADIUS server, and is used in the
      password hiding algorithm.

      Request Authenticator

         In Access-Request Packets, the Authenticator value is a 16
         octet random number, called the Request Authenticator.  The
         value SHOULD be unpredictable and unique over the lifetime of a
         secret (the password shared between the client and the RADIUS
         server), since repetition of a request value in conjunction
         with the same secret would permit an attacker to reply with a
         previously intercepted response.  Since it is expected that the
         same secret MAY be used to authenticate with servers in
         disparate geographic regions, the Request Authenticator field
         SHOULD exhibit global and temporal uniqueness.

         The Request Authenticator value in an Access-Request packet
         SHOULD also be unpredictable, lest an attacker trick a server
         into responding to a predicted future request, and then use the
         response to masquerade as that server to a future Access-
         Request.

         Although protocols such as RADIUS are incapable of protecting
         against theft of an authenticated session via realtime active
         wiretapping attacks, generation of unique unpredictable
         requests can protect against a wide range of active attacks
         against authentication.

         The NAS and RADIUS server share a secret.  That shared secret
         followed by the Request Authenticator is put through a one-way
         MD5 hash to create a 16 octet digest value which is xored with
         the password entered by the user, and the xored result placed
         in the User-Password attribute in the Access-Request packet.
         See the entry for User-Password in the section on Attributes
         for a more detailed description.

      Response Authenticator

         The value of the Authenticator field in Access-Accept, Access-
         Reject, and Access-Challenge packets is called the Response
         Authenticator, and contains a one-way MD5 hash calculated over
         a stream of octets consisting of: the RADIUS packet, beginning
         with the Code field, including the Identifier, the Length, the
         Request Authenticator field from the Access-Request packet, and
         the response Attributes, followed by the shared secret.  That
         is, ResponseAuth =3D
         MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
         denotes concatenation.

See the following section of RFC 2869 for additional clarification:=20

7.1.  Message-Authenticator Security

   Access-Request packets with a User-Password establish the identity of
   both the user and the NAS sending the Access-Request, because of the
   way the shared secret between NAS and RADIUS server is used.
   Access-Request packets with CHAP-Password or EAP-Message do not have
   a User-Password attribute, so the Message-Authenticator attribute
   should be used in access-request packets that do not have a User-
   Password, in order to establish the identity of the NAS sending the
   request.

--
to unsubscribe send 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, 04 Mar 2005 19:48:16 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: Frank Quick <[email-masked]>, Jari Arkko <[email-masked]>, [email-masked], Thomas Narten <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Date: Fri, 04 Mar 2005 14:43:42 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> Access-Reject may not always result in the termination of a session etc...
> 
> For example, when I am doing authorize only, (Access-Accept with
> Service-Type = Authorize-Only) the Access-Reject is a rejection of that
> authorization and not necessarily the rejection of the entire session or
> service.  Or is it? 

  It's at least a rejection of what they asked for.  For
Authorize-Only, the semantics of the Access-Reject should clearly be
that the authorization failed.

  e.g. Cisco TACACS-style command authorization.  A request for
authorization of a command may be "rejected", but the admins session
will remain active, because no session information was sent in the request.

  For this draft, Figure 4. shows that the protocol flow is:

	11. Access-Request
	13. Access-Reject
	16. Access-Request
	17. Access-Accept

  As noted earlier, an Access-Challenge packet would normally be used
in the second step.  A more telling item I noted is that the
Access-Reject implicitly has multiple meanings.  e.g. For step 12, the
draft says:

	12. ... The RADIUS AAA Server verifies
        the MN-AAA Authentication Extension Authenticator using the
        decrypted MN_AAA key.  If successful, ...

  There's no description of what happens if the verification fails.

  My question to the draft authors is then: What happens when
verification fails?  Is the server supposed to send an Access-Reject
*without* the AA_Authenticator RADIUS VSA?  Will the client terminate
the session because of this reject?

  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, 04 Mar 2005 19:33:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Fri, 4 Mar 2005 14:32:42 -0500
From: "Nelson, David" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "Frank Quick" <[email-masked]>
Cc: "Barney Wolff" <[email-masked]>, <[email-masked]>, "Avi Lior" <[email-masked]>, "Thomas Narten" <[email-masked]>, "W. Mark Townsley" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, <[email-masked]>, <[email-masked]>

Jari Arkko writes...

> But the note should not "punish the authors". Lets use less
> emotionally charged words, "violate" may not be very good. But
> "is not consistent" doesn't quite do the job for me either. Perhaps
> "not compliant with RFC XXXX" is the right, objective expression
> here.

I've certainly no desire, nor authority, to "punish" the draft authors.
Any reasonable language, that clearly and unambiguously indicates that
the disputed RADIUS usages are non-compliant with the base RADIUS RFC
and considered deprecated for any new work, would be fine with me.
Jari's suggested text works for me.

--
to unsubscribe send 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, 04 Mar 2005 19:20:38 +0000
Date: Fri, 04 Mar 2005 21:20:37 +0200
From: Jari Arkko <[email-masked]>
To: Frank Quick <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, Barney Wolff <[email-masked]>, [email-masked], Avi Lior <[email-masked]>, Thomas Narten <[email-masked]>, "W. Mark Townsley" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt

Frank Quick wrote:

> And I think "is not consistent with" is entirely accurate, if perhaps 
> less blunt.  If the purpose is to inform the reader, rather than to 
> punish the authors, then the less blunt wording should be sufficient.  
> I'd also accept "not compliant with" if you prefer.

I have some sympathy for this. Its excellent if we agree about the
technical part of the note (or will come to an agreement at least).
But the note should not "punish the authors". Lets use less
emotionally charged words, "violate" may not be very good. But
"is not consistent" doesn't quite do the job for me either. Perhaps
"not compliant with RFC XXXX" is the right, objective expression
here.

--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: Fri, 04 Mar 2005 19:18:11 +0000
Content-class: urn:content-classes:message
Subject: Meaning of Acess-Reject (was RE: Comments on draft-carroll-dynmobileip-cdma-04.txt)
Date: Fri, 4 Mar 2005 14:18:04 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Cc: <[email-masked]>

Avi Lior writes...

> Access-Reject may not always result in the termination of a session
etc...
>=20
> For example, when I am doing authorize only, (Access-Accept with
> Service-Type =3D Authorize-Only) the Access-Reject is a rejection of
that
> authorization and not necessarily the rejection of the entire session
or
> service.  Or is it?

We could have this discussion, and raise an issue relating to any
existing deployments, as part of the RADIUS Issues and Fixes draft.  I
think it would be a very bad idea indeed to change something as
fundamental as the semantics of a RADIUS Access-Reject to *ever* mean
anything other than a termination of NAS service and a termination of
the session (e.g. layer 2 connection) for the attached network host.

--
to unsubscribe send 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, 04 Mar 2005 19:13:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Fri, 4 Mar 2005 14:12:45 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Frank Quick" <[email-masked]>, "Barney Wolff" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>, <[email-masked]>, "Thomas Narten" <[email-masked]>, "W. Mark Townsley" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Actually this is not true. It was a calculated decision to use
> Access-Reject. Perhaps Frank or someone closer to it would tell you
why
> they did that.

Hmmm... OK. I was giving the authors the "benefit of the doubt" here.  I
still assume that the authors did not intentionally (knowingly)
contradict (violate, be out of compliance with, what-have-you) a
normative MUST requirement of the base RADIUS RFC.  Let's write this off
an as unintentional error, that exists in existing deployments, but is
deprecated for any new work, and move on.

--
to unsubscribe send 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, 04 Mar 2005 19:11:17 +0000
Date: Fri, 4 Mar 2005 11:11:07 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: Thomas Narten <[email-masked]>, "W. Mark Townsley" <[email-masked]>, Frank Quick <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt

>        RFC 2865 an Access-Reject packet MAY only include Reply-Message
>        and Proxy-State attributes.  Subsequent RFCs allow for other
>        attributes to be included in an Access-Reject packet, but these
>        are included to indicate the reason the
>        authentication/authorization has failed.  It is a normative
>        requirement of RFC 2865 that receipt of an Access-Reject at the
>        NAS terminate the session of the attached
>        network host.  This document violates that normative requirement.
>        Instead, the use of an Access-Challenge packet would have been
>        appropriate according to RFC 2865. (2) The security
>        considerations
>        of this specification rely, in part, on the specific cellular
>        telephony infrastructure used in this application, and the
> protocol
>        extensions as described herein potentially exhibit inadequate
>        security properties when used outside of the specific deployment
>        environment.  As a result, the use of this specification in other
>        circumstances than those described in this document or as a basis
>        for new work is strongly discouraged.

I would add that the document fundamentally changes the semantics of the
RADIUS Access-Reject, so as not to cause termination of the user
connection.  It also does not intgrity protect and authenticate RADIUS
Access-Request, another normative violation of RFC 2865.

--
to unsubscribe send 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, 04 Mar 2005 19:07:15 +0000
From: Avi Lior <[email-masked]>
To: "Nelson, David" <[email-masked]>, Frank Quick <[email-masked]>, Barney Wolff <[email-masked]>
Cc: Jari Arkko <[email-masked]>, [email-masked], Avi Lior <[email-masked]>, Thomas Narten <[email-masked]>,  "W. Mark Townsley" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Fri, 4 Mar 2005 14:06:53 -0500 

David,

> 
> I'm not looking to unreasonably bash this work, given that 
> the errors were very likely based on a lack of detailed 
> understanding of RADIUS and a lack of timely review by 
> subject matter experts.  Still, I think in the interests of 
> "truth in advertising", we need to consider the disputed 
> RADIUS usages as being deprecated.

Actually this is not true. It was a calculated decision to use
Access-Reject. Perhaps Frank or someone closer to it would tell you why they
did that.

--
to unsubscribe send 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, 04 Mar 2005 19:07:07 +0000
From: Avi Lior <[email-masked]>
To: Barney Wolff <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: Jari Arkko <[email-masked]>, [email-masked], Avi Lior <[email-masked]>, Thomas Narten <[email-masked]>,  "W. Mark Townsley" <[email-masked]>, Frank Quick <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Fri, 4 Mar 2005 14:06:54 -0500 

So I am okay about this -- but only for now.

Going forward we have an issue and we need to think about this.

Access-Reject may not always result in the termination of a session etc...

For example, when I am doing authorize only, (Access-Accept with
Service-Type = Authorize-Only) the Access-Reject is a rejection of that
authorization and not necessarily the rejection of the entire session or
service.  Or is it? 

Avi

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Friday, March 04, 2005 11:44 AM
> To: Nelson, David
> Cc: Jari Arkko; [email-masked]; Avi Lior; Thomas Narten; W. 
> Mark Townsley; Frank Quick; [email-masked]; 
> [email-masked]
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> On Fri, Mar 04, 2005 at 10:13:47AM -0500, Nelson, David wrote:
> > 
> >        This protocol defines how RADIUS (RFC 2865) is used in a
> >        specific application using vendor-specific protocol 
> extensions.
> >        It has been reviewed by the RADIUS community within 
> the IETF and
> >        the following issues have been noted: (1) This 
> document specifies
> >        returning an attribute in an Access-Reject message. 
> According to
> >        RFC 2865 an Access-Reject packet MAY only include 
> Reply-Message
> >        and Proxy-State attributes.  Subsequent RFCs allow for other
> >        attributes to be included in an Access-Reject 
> packet, but these
> >        are included to indicate the reason the 
> > authentication/authorization
> >        has failed.  It is a normative requirement of RFC 2865 that 
> > receipt
> >        of an Access-Reject at the NAS terminate the session of the 
> > attached
> >        network host.  This document violates that normative 
> requirement.
> >        Instead, the use of an Access-Challenge packet would 
> have been
> >        appropriate according to RFC 2865. (2) The security 
> > considerations
> >        of this specification rely, in part, on the specific cellular
> >        telephony infrastructure used in this application, and the 
> > protocol
> >        extensions as described herein potentially exhibit 
> inadequate 
> >        security properties when used outside of the 
> specific deployment
> >        environment.  As a result, the use of this 
> specification in other
> >        circumstances than those described in this document or as a 
> > basis
> > 
> >        for new work is strongly discouraged.
> 
> I endorse this.  To me, the prime problem is the 
> non-termination on -reject. Inclusion on attributes in the 
> -reject, while a clear violation of 2865, is the lesser issue.
> 
> Barney
> 
> -- 
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I never met a computer I didn't like.
> 

--
to unsubscribe send 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, 04 Mar 2005 18:08:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Fri, 4 Mar 2005 13:07:57 -0500
From: "Nelson, David" <[email-masked]>
To: "Frank Quick" <[email-masked]>, "Barney Wolff" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>, <[email-masked]>, "Avi Lior" <[email-masked]>, "Thomas Narten" <[email-masked]>, "W. Mark Townsley" <[email-masked]>, "Carroll, Christopher P." <[email-masked]>, <[email-masked]>, <[email-masked]>

Frank Quick writes...

> My last mail didn't address Nelson's modifications.  Perhaps:

<snip>

> (2) It is a normative requirement of RFC 2865 that receipt=20
> of an Access-Reject at the NAS terminate the session of the
> attached network host.  This document is not consistent with=20
> that requirement.

Hmmm... "violates" vs. "is not consistent with" sounds like spin to me.
I'd prefer my original wording.  I think it's entirely accurate, if
perhaps more blunt.

> As a result, the use of this specification in other circumstances
> than those described in the document is not recommended.  Any future
> work based on this specification should take these issues into
> consideration.

So are you suggesting that future work ought to be based on this
document?

I'm not looking to unreasonably bash this work, given that the errors
were very likely based on a lack of detailed understanding of RADIUS and
a lack of timely review by subject matter experts.  Still, I think in
the interests of "truth in advertising", we need to consider the
disputed RADIUS usages as being deprecated.
=20
> The security comments address security concerns that are general, not
> associated with any identified normative requirement.  I think the
draft
> makes it clear enough that DMU in its present form is applicable only
to
> the cellular environment.  However, I might suggest adding something
in
> the security section, perhaps a new section following the current 7.7:
>=20
> 7.8 Other False MN
>=20
>      The security considerations of this specification rely,=20
>      in part, on cellular MN authentication and other security=20
>      features, and the protocol extensions as described herein=20
>      potentially exhibit inadequate security properties when used
>      outside of the cellular environment.  As a result, the use of
>      this specification in other circumstances than those described
>      in this document may require modification of the protocol to=20
>      provide a similar level of security.

If the authors would like to submit a revised draft including this text,
I think it would sufficiently address the security considerations issue.
I had not suggested a draft revision, because at this point in the
review cycle we were being asked to craft an IESG "disclaimer note", and
I had assumed that draft revisions were out of scope.

--
to unsubscribe send 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, 04 Mar 2005 16:45:40 +0000
Date: Fri, 4 Mar 2005 11:44:17 -0500
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: Jari Arkko <[email-masked]>, [email-masked], Avi Lior <[email-masked]>, Thomas Narten <[email-masked]>, "W. Mark Townsley" <[email-masked]>, Frank Quick <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt

On Fri, Mar 04, 2005 at 10:13:47AM -0500, Nelson, David wrote:
> 
>        This protocol defines how RADIUS (RFC 2865) is used in a
>        specific application using vendor-specific protocol extensions.
>        It has been reviewed by the RADIUS community within the IETF and
>        the following issues have been noted: (1) This document specifies
>        returning an attribute in an Access-Reject message. According to
>        RFC 2865 an Access-Reject packet MAY only include Reply-Message
>        and Proxy-State attributes.  Subsequent RFCs allow for other
>        attributes to be included in an Access-Reject packet, but these
>        are included to indicate the reason the
> authentication/authorization
>        has failed.  It is a normative requirement of RFC 2865 that
> receipt
>        of an Access-Reject at the NAS terminate the session of the
> attached
>        network host.  This document violates that normative requirement.
>        Instead, the use of an Access-Challenge packet would have been
>        appropriate according to RFC 2865. (2) The security
> considerations
>        of this specification rely, in part, on the specific cellular
>        telephony infrastructure used in this application, and the
> protocol
>        extensions as described herein potentially exhibit inadequate 
>        security properties when used outside of the specific deployment
>        environment.  As a result, the use of this specification in other
>        circumstances than those described in this document or as a basis
> 
>        for new work is strongly discouraged.

I endorse this.  To me, the prime problem is the non-termination on -reject.
Inclusion on attributes in the -reject, while a clear violation of 2865,
is the lesser issue.

Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I never met a computer I didn't like.

--
to unsubscribe send 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, 04 Mar 2005 16:23:29 +0000
Date: Fri, 04 Mar 2005 18:23:10 +0200
From: Jari Arkko <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], Avi Lior <[email-masked]>, Thomas Narten <[email-masked]>, "W. Mark Townsley" <[email-masked]>, Frank Quick <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt

Nelson, David wrote:

>This looks pretty good to me.  I'd suggest a few changes, as shown
>below:
>
>       This protocol defines how RADIUS (RFC 2865) is used in a
>       specific application using vendor-specific protocol extensions.
>       It has been reviewed by the RADIUS community within the IETF and
>       the following issues have been noted: (1) This document specifies
>       returning an attribute in an Access-Reject message. According to
>       RFC 2865 an Access-Reject packet MAY only include Reply-Message
>       and Proxy-State attributes.  Subsequent RFCs allow for other
>       attributes to be included in an Access-Reject packet, but these
>       are included to indicate the reason the
>authentication/authorization
>       has failed.  It is a normative requirement of RFC 2865 that
>receipt
>       of an Access-Reject at the NAS terminate the session of the
>attached
>       network host.  This document violates that normative requirement.
>       Instead, the use of an Access-Challenge packet would have been
>       appropriate according to RFC 2865. (2) The security
>considerations
>       of this specification rely, in part, on the specific cellular
>       telephony infrastructure used in this application, and the
>protocol
>       extensions as described herein potentially exhibit inadequate 
>       security properties when used outside of the specific deployment
>       environment.  As a result, the use of this specification in other
>       circumstances than those described in this document or as a basis
>
>       for new work is strongly discouraged.
>  
>
I like your text. (But I haven't looked at the security considerations
to verify that problem 2 exists, presumably someone has...)

--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: Fri, 04 Mar 2005 15:14:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Fri, 4 Mar 2005 10:13:47 -0500
From: "Nelson, David" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, <[email-masked]>, "Avi Lior" <[email-masked]>, "Thomas Narten" <[email-masked]>
Cc: "W. Mark Townsley" <[email-masked]>, "Frank Quick" <[email-masked]>, <[email-masked]>, <[email-masked]>

Jari Arkko writes...

> Ok otherwise but lets be careful with the word "extends".
> There are different types of extensions, lets be more
> specific. How about
>=20
>      This protocol defines how RADIUS (RFC 2865) is used in a
>      specific situation and vendor-specific protocol extensions.
>      It has been reviewed by the Radius community and the
>      following issues have been noted: (1) The document suggests
>      returning an attribute in an Access-Reject message. According to
>      RFC 2865 an Access-Reject packet MAY only include Reply-Message
>      and Proxy-State attributes.  Subsequent RFCs allow for other
>      attributes to be included in an Access-Reject packet but these
>      are included to indicate the reason the
authentication/authorization
>      has failed. Instead, the use of an Access-Challenge packet=20
>      would have been appropriate according to RFC 2865. (2) ...=20
>      maybe more issues ...  As a result, the use of this specification
>      in other circumstances than those described in the document or=20
>      as a basis for new work is not recommended.

This looks pretty good to me.  I'd suggest a few changes, as shown
below:

       This protocol defines how RADIUS (RFC 2865) is used in a
       specific application using vendor-specific protocol extensions.
       It has been reviewed by the RADIUS community within the IETF and
       the following issues have been noted: (1) This document specifies
       returning an attribute in an Access-Reject message. According to
       RFC 2865 an Access-Reject packet MAY only include Reply-Message
       and Proxy-State attributes.  Subsequent RFCs allow for other
       attributes to be included in an Access-Reject packet, but these
       are included to indicate the reason the
authentication/authorization
       has failed.  It is a normative requirement of RFC 2865 that
receipt
       of an Access-Reject at the NAS terminate the session of the
attached
       network host.  This document violates that normative requirement.
       Instead, the use of an Access-Challenge packet would have been
       appropriate according to RFC 2865. (2) The security
considerations
       of this specification rely, in part, on the specific cellular
       telephony infrastructure used in this application, and the
protocol
       extensions as described herein potentially exhibit inadequate=20
       security properties when used outside of the specific deployment
       environment.  As a result, the use of this specification in other
       circumstances than those described in this document or as a basis

       for new work is strongly discouraged.

--
to unsubscribe send 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, 04 Mar 2005 13:08:07 +0000
Date: Fri, 04 Mar 2005 15:00:40 +0200
From: Jari Arkko <[email-masked]>
To: Tschofenig Hannes <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: Who adds location information

Tschofenig Hannes wrote:

>hi all, 
>
>bernard and lionel have sent this question to the mailing list: 
>
>[Lionel]
>
>  
>
>>==> Is it so sure that NAS is always the source of location information?
>>Couldn't we have scenarios where the location information is added by 
>>the RADIUS proxy in the visited network, because the NAS is not able 
>>to retrieve the user's location for instance?
>>    
>>
>
>[Bernard]
>
>This seems quite likely, in fact.
>
>
>[hannes] we might not have mentioned this explicitly but we made no
>restrictions with regard to the endity that may add location information
>(e.g., the nas or a proxy). 
>  
>
Yes. Do we have a text proposal that explicitly mentions this?

--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: Fri, 04 Mar 2005 13:07:59 +0000
Date: Fri, 04 Mar 2005 14:56:39 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Tschofenig Hannes <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: When to send location info?

Bernard Aboba wrote:

>I'd suggest that language be included in the document to say that "by
>default, a NAS that is set up to provide user location information to the
>RADIUS server MUST provide this information in every Access-Request."
>  
>
Or even skip "by default" and agree that where user location
information (a) can be delivered and (b) is policy-wise desired to be
sent at all, it is always sent.

For NAS location you could send it only if it has changed (e.g.
mobile router).

--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: Fri, 04 Mar 2005 13:07:54 +0000
Date: Fri, 04 Mar 2005 14:48:09 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Tschofenig Hannes <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: Precision

Bernard Aboba wrote:

>I think the document needs to clearly differentiate NAS location from user
>location.
>
>Today shipping 802.11 APs can estimate the user location to a significant
>  
>
(snip)

>If NAS location and user location are clearly delineated, then it will not
>be necessary to take that into account within a precision attribute.
>  
>
I agree. Here are some text suggestions. Change

     Precision (8 bits):
       Describes which location this attribute refers to:
       (0) describes the location of the NAS
       (1) describes the location of the AAA server
       (2) describes the location of the end host (user)
       (3) describes the location of the network

to

     Entity (4 bits):
        Describes whose location this attribute carries:
        (0) Describes the location of the user's client device,
             as estimated by the network.
        (1) Describes the location of the NAS

Justification: I could not think of any case where the location
of AAA server would have to figured out. Also, "NAS" and
"network" are too imprecise to be useful. What about a
distributed NAS, a concentrator/dummy AP combination?
I would just give a the user's location or no location at all
if we get into that kind of things. But if you really need the
network's location, you might consider adding a subfield
for "cell size", that shows how large area this "NAS" covers.
But I don't think its essential functionality.

--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: Fri, 04 Mar 2005 13:07:43 +0000
Date: Fri, 04 Mar 2005 15:02:05 +0200
From: Jari Arkko <[email-masked]>
To: Tschofenig Hannes <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: CDMA operator-name prefix / registry

Hi Hannes,

I think your text is good. Just one nit about the REALM-case,
I think it would more sense to tie this to DNS in the same way
as is done NAIs.

>   The REALM operator type can be used to indicate operator names based
>   on any registered domain name.  The Internet Assigned Numbers
>   Authority (IANA) or registered delegate is the authority responsible
>   for issuing unique Operator-Name values for operators of this type.
>  
>
Suggested text: replace last sentence with "Such names are
required to be unique and the rights to use a given realm name
are obtained coincident with acquiring the rights to use a
particular Fully Qualified Domain Name (FQDN). "

--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: Fri, 04 Mar 2005 10:53:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 287
Date: Fri, 4 Mar 2005 02:51:27 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Geln, all
Thanks for your time.  Please see my comments inline.
-Farid

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]]=20
> Sent: Thursday, March 03, 2005 7:50 PM
> To: Adrangi, Farid
> Cc: [email-masked]; [email-masked]
> Subject: Issue 287
>=20
>=20
> There still seems to me to be a problem here.  The thinking
> portrayed in the revised document seems awfully fuzzy to me.  This
> is exemplified by the following: "If the identity hint is not sent
> initially (such as when the authenticator does not support this
> specification), then if the local AAA proxy/server implementing this
> specification receives an EAP-Response/Identity with an unknown
> realm, it SHOULD reply with an EAP-Request/Identity containing an
> identity hint."  Of course, the AAA proxy _cannot_ receive an
> EAP-Response, nor send an EAP-Request, since it is a _AAA_ proxy,
> not an EAP entity of any variety.

Well, it is my understanding that the EAP-aware AAA proxy/server
[RFC3579] in the access network can send EAP-Request/Identity within an
Access-Challenge.  Here is a quote from RFC3579:
"
   Rather than sending an initial EAP-Request packet to the
   authenticating peer, on detecting the presence of the peer, the NAS
   MAY send an Access-Request packet to the RADIUS server containing an
   EAP-Message attribute signifying EAP-Start.  The RADIUS server will
   typically respond with an Access-Challenge containing EAP-Message
   attribute(s) encapsulating an EAP-Request/Identity (Type 1).
"

Maybe we can make the paragraph more clear by revising to something like
this:

"
The EAP authenticator MAY send an identity hint to the peer in the
initial EAP-Request/Identity.  If the identity hint is not sent
initially (such as when the authenticator does not support this
specification), then if the local EAP-aware AAA proxy/server
implementing this specification receives an AAA Request packet with an
unknown realm, it SHOULD reply with an EAP-Request/Identity containing
an identity hint.  For example, in case of RADIUS, if the EAP-aware
RADIUS proxy/server [RFC 3579] receives an Access-Request packet with an
unknown realm in the UserName(1) attribute, then it can reply with an
EAP-Request/Identity containing an identity hint within an
Access-Challenge packet. Please see "option 3" in the appendix for the
message flow diagram.
"

What do you think?=20

>  This is the same thing that I
> wrote about earlier, when I said that this draft is interfering with
> the EAP protocol: it seems clear that whatever is sending these
> "hints" is an EAP entity of some sort (because it is engaged in at
> least a subset of the EAP protocol), but it's not a peer (since it's
> not being authenticated), it's not an authenticator (since it's not
> doing the authenticating) and it's not a server (since it doesn't
> terminate the authentication method. So what is it? =20
>=20

> ~gwz
>=20

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

Delivery-date: Fri, 04 Mar 2005 09:21:38 +0000
Date: Fri, 04 Mar 2005 11:21:32 +0200
From: Jari Arkko <[email-masked]>
To: [email-masked], 'Avi Lior' <[email-masked]>, 'Thomas Narten' <[email-masked]>
Cc: "'W. Mark Townsley'" <[email-masked]>, 'Frank Quick' <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt

Hi Glen, Thomas, Avi,

Glen, you wrote:

>OK, but I haven't heard either Frank or Chris _ask_ for any help...
>  
>
I don't think they need to ask help in this case. This being treated
in the process in the manner that Thomas explained in his e-mail.
I don't think we should edit the document content itself, but
an IESG note is required to the document before it can proceed,
and I think the contents of that note should be formulated carefully.
I think we are discussing the contents of that note, not
fixing the protocol as such. The note is IESG's problem but my
understanding is that the ADs would welcome the help of the
RADIUS community in defining what issues should be highlighted.

Thomas, you wrote:

>   This protocol makes use of and extends the IETF Radius protocol
>   (RFC XXX). It has been reviewed by the Radius community and the
>   following issues have been noted ....
>
>and then list the violations and perhaps provide some explanation as
>to why those violations are considered inappropriate or how serious
>they are. Not a lot of text, but maybe one or two paragraphs total
>would be best.
>
>Given that the protocol is deployed, and most folks seem to think it's
>better to document something (that is widely deployed) than not,
>adding such a note as outlined above seems like a reasonable way out
>(to me).
>
I think this makes sense under the circumstances. Note,
however, the difference between "we have not reviewed it
and it does not directly concern us" and "we think there are
some problems and it affects our protocols". Lets hope that most
future individual submissions fall on the former category...

Avi, you wrote:

>This document extends RADIUS in the following way:
>
>The document returns an attribute in an Access-Reject message. According to
>RFC-2865 an Access-Reject packet MAY only include Reply-Message and
>Proxy-State.
>
>Subsequent RFCs allow for other attributes to be included in an
>Access-Reject packet but these are included to indicate the reason the
>authentication/authorization has failed.  Given the use in this document an
>Access-Challenge packet would have been more appropriate.
>  
>
Ok otherwise but lets be careful with the word "extends".
There are different types of extensions, lets be more
specific. How about

     This protocol defines how RADIUS (RFC 2865) is used in a
     specific situation and vendor-specific protocol extensions.
     It has been reviewed by the Radius community and the
     following issues have been noted: (1) The document suggests
     returning an attribute in an Access-Reject message. According to
     RFC 2865 an Access-Reject packet MAY only include Reply-Message
     and Proxy-State attributes.  Subsequent RFCs allow for other
     attributes to be included in an Access-Reject packet but these
     are included to indicate the reason the authentication/authorization
     has failed. Instead, the use of an Access-Challenge packet would have
     been appropriate according to RFC 2865. (2) ... maybe more issues ...
     As a result, the use of this specification in other circumstances than
     those described in the document or as a basis for new work is not
     recommended.

--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: Fri, 04 Mar 2005 08:29:19 +0000
Date: Fri, 04 Mar 2005 10:28:54 +0200
From: Jari Arkko <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, [email-masked], [email-masked], Tschofenig Hannes <[email-masked]>
Subject: Re: [Geopriv] Re: Radius-Geopriv: When to send location info?

Avi Lior wrote:

>Hi folks,
>
>The problem is this,  assuming that you have a Location Capable NAS that
>sends location only on request, then in a scenario where the AAA always
>requires it, then you will be introducing another exchange FOR every
>REQUEST.  So that is clearly bad.  However, if EAP is being used then this
>is not an issue since we already have a challenge happening.
>  
>
I realize that but I wonder how likely that is. In fact, are there
any cases where you'd not be doing challenges anyway? Seems
like WLAN, PPP CHAP, and SIP all need that... the only case that
does not need it is PPP PAP, but we deprecated that, didn't we?

Or maybe there is some mode of RADIUS or Diameter SIP that doesn't
need a request -- its too late in the night for me to go and re-read
the documents to find out, but maybe you remember it directly.

In any case, I would like to avoid a very complicated mechanism
that works differently for different apps. All I wanted is a privacy
knob to the system where (a) if the client and NAS have a protocol
that can negotiate location policies, then the NAS MUST obey the
results of the negotiation, and (b) if the home network has a "do not
disclose" policy about location information it MUST prevent the
information from being sent in the first place. But I see the problems
that you bring up.

>So perhaps we can do the following (just thinking out loud).
>
>1) The NAS (based on local policies) may be configured to send location info
>to the home network. So in some deployments that is what it will do because
>that is how they will want it to be used.
>  
>
I'm pretty sure we have this in any case. Just because you installed
a newer firmware version to the NAS with location attribute support
doesn't mean that it should necessarily be turned on.

>2) The NAS does not send the location information. But the home network may
>challenge for it. Hence forth for that session it will continue to send that
>information.
>
>In step 2) how does the home network know that the NAS support location
>information capability.  Well the NAS simply advertizes this using
>Capability Exchange see our draft for that in RADEXT.
>
>Note that in step 2 the home AAA needs to request location information.  We
>can invent an attribute for that but this is yet another example where the
>AAA can also include the Capability attribute to indicate that it MUST have
>location, or that location information SHOULD be provided.
>
>Note we had a debate whether or not the capability exchange should also come
>from the home network. This is a clear case of such example.  SO the NAS
>says "Hey I can deliver Location Information" the HOME Server says "Hey I
>MUST have location information, or I it would be nice if you could deliver
>location information" -- you get the drift.
>
>But Capability Exchange is still drafty.
>  
>
Yes. But the indication we are talking about here is more about
policy "do I want you to send the info even if you have it?" than
capability "can you send it?". But I agree it could be encoded in
a general e2e capability exchange feature.

--Jari

>  
>
>>-----Original Message-----
>>From: Jari Arkko [mailto:[email-masked]] 
>>Sent: Thursday, March 03, 2005 3:09 PM
>>To: Bernard Aboba
>>Cc: [email-masked]; [email-masked]; Tschofenig Hannes
>>Subject: [Geopriv] Re: Radius-Geopriv: When to send location info?
>>
>>
>>Bernard Aboba wrote:
>>
>>    
>>
>>>>[hannes] to me it seems reasonable not to include location 
>>>>        
>>>>
>>information 
>>    
>>
>>>>with every request. a  visited network which knows that it 
>>>>        
>>>>
>>has to send 
>>    
>>
>>>>location information to a particular home network  might do 
>>>>        
>>>>
>>so. i also 
>>    
>>
>>>>think that it would be good to have an error attribute to indicate 
>>>>that it was  not possible to authorize the user properly 
>>>>        
>>>>
>>based on the 
>>    
>>
>>>>missing location information.
>>>>
>>>>we have added the usage of the error-cause attribute. 
>>>>        
>>>>
>>within the iana 
>>    
>>
>>>>section we need to register  a new type:
>>>>   
>>>>
>>>>        
>>>>
>>>I am confused by the model that is described here.  I could 
>>>      
>>>
>>understand 
>>    
>>
>>>why the NAS might not send the NAS location with every 
>>>      
>>>
>>Access-Request.  
>>    
>>
>>>But user location is another matter.  If the NAS is set up 
>>>      
>>>
>>to send user 
>>    
>>
>>>location data, why would it not send it on each request?
>>>
>>>My reading of RFC 2865 is that service provisioning attributes 
>>>(including
>>>VSAs) are forbidden in a RADIUS Access-Reject.  However, 
>>>      
>>>
>>information on
>>    
>>
>>>why the request failed is ok (e.g. Reply-Message, 
>>>      
>>>
>>EAP-Message/EAP-Failure,
>>    
>>
>>>etc.).  So I think that Error-Cause can be included.
>>>
>>>However, Error-Cause will not solve the problem that is 
>>>      
>>>
>>described.  If 
>>    
>>
>>>the NAS is not sending User location on every Access-Request and the 
>>>server requires this, then every Access-Request that is sent without 
>>>the user location will be denied.
>>>
>>>I'd suggest that language be included in the document to say 
>>>      
>>>
>>that "by 
>>    
>>
>>>default, a NAS that is set up to provide user location 
>>>      
>>>
>>information to 
>>    
>>
>>>the RADIUS server MUST provide this information in every 
>>>Access-Request."
>>> 
>>>
>>>      
>>>
>>Yes. I would in fact extend this by having the NAS send this 
>>information in the first place if and only if the home AAA 
>>earlier instructed the NAS to do so for this specific 
>>session. The cost would be very small, no additional 
>>roundtrips for instance.
>>
>>--Jari
>>
>>
>>_______________________________________________
>>Geopriv mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/geopriv
>>
>>    
>>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>
>
>  
>

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

Delivery-date: Fri, 04 Mar 2005 03:50:28 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Issue 287
Date: Thu, 3 Mar 2005 19:49:54 -0800

There still seems to me to be a problem here.  The thinking
portrayed in the revised document seems awfully fuzzy to me.  This
is exemplified by the following: "If the identity hint is not sent
initially (such as when the authenticator does not support this
specification), then if the local AAA proxy/server implementing this
specification receives an EAP-Response/Identity with an unknown
realm, it SHOULD reply with an EAP-Request/Identity containing an
identity hint."  Of course, the AAA proxy _cannot_ receive an
EAP-Response, nor send an EAP-Request, since it is a _AAA_ proxy,
not an EAP entity of any variety.  This is the same thing that I
wrote about earlier, when I said that this draft is interfering with
the EAP protocol: it seems clear that whatever is sending these
"hints" is an EAP entity of some sort (because it is engaged in at
least a subset of the EAP protocol), but it's not a peer (since it's
not being authenticated), it's not an authenticator (since it's not
doing the authenticating) and it's not a server (since it doesn't
terminate the authentication method. So what is it?  

~gwz

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

Delivery-date: Fri, 04 Mar 2005 01:00:53 +0000
Date: Thu, 03 Mar 2005 17:00:20 -0800
To: Avi Lior <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Cc: "[email-masked]'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>, Avi Lior <[email-masked]>, "'Frank Quick'" <[email-masked]>, [email-masked], [email-masked]

At 06:48 PM 3/3/2005 -0500, Avi Lior wrote:

> > Since this is an individual submission & not a WG document, I
> > wouldn't feel at all comfortable dictating text to the
> > authors.  My guess is that this is between them and the IESG (sorry!).
>
>But we can help.  And actually - although I wasn't around at the start - I
>think we should have done something about this earlier. Since we all
>indicated that we knew about the Access-Reject problem.
>
>I know that Thomas asked 3GPP2 and 3GPP2 did review the document from their
>prespective.

AFAIK we did a quick review of the document in 3GPP2 and didn't have any
objections to IETF publishing it as an informational RFC. So, there seems to be
a protocol violation that we missed since we didn't review it very 
carefully. VZN
chose not to standardize it in 3GPP2 so it remains a proprietary protocol
even though it's published by IETF. It's an "informational" not a standard RFC.
Doesn't "informational" mean that "this is my way of doing things and if 
you want
to inter-operate with my network you can do it this way but you don't have to"?

-Parviz

> > >
> > > - Mark
> >
> > 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/>

--
to unsubscribe send 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, 04 Mar 2005 00:32:13 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>
Cc: "'Frank Quick'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 16:31:27 -0800

Avi Lior <mailto:[email-masked]> supposedly scribbled:

>> Since this is an individual submission & not a WG document, I
>> wouldn't feel at all comfortable dictating text to the authors.
My
>> guess is that this is between them and the IESG (sorry!).
> 
> But we can help.  

OK, but I haven't heard either Frank or Chris _ask_ for any help...

> And actually - although I wasn't around at the
> start - I think we should have done something about this earlier.
> Since we all indicated that we knew about the Access-Reject
problem. 

Who are "we"?
 
> 
> I know that Thomas asked 3GPP2 and 3GPP2 did review the document
from
> their prespective. 

LOL

> 
>>> 
>>> - Mark
>> 
>> 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

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Fri, 04 Mar 2005 00:26:27 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>
Cc: "'Frank Quick'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 16:26:09 -0800

Avi Lior <> supposedly scribbled:

> Note that we currently have a draft in MIPv4 WG to define a
similar
> procedure. 
> 
> Okay....
> 
> Here is some proposed text....What do people think.
> 
> 
> This document extends RADIUS in the following way:
> 
> The document returns an attribute in an Access-Reject message.
> According to 
> RFC-2865 an Access-Reject packet MAY only include Reply-Message
and
> Proxy-State. 
> 
> Subsequent RFCs allow for other attributes to be included in an
> Access-Reject packet but these are included to indicate the reason
> the authentication/authorization has failed.  Given the use in
this
> document an Access-Challenge packet would have been more
appropriate.

Leaving out the change in semantics for the Access-Reject message?
& the fact that it is a VSA, not even a standard attribute?

> 
> 
> Regarding Bernards comment:
> 
> 7.9 Network Message Security
> 
>    The security of the MN-HA keys delivered from the RADIUS AAA
server
>    to the MIP home agent requires confidentiality for network
messages
>    containing such keys.  The specification of security
requirements
>    for network messages is the responsibility of the operator, and
is
>    outside the scope of this document. (Note that similar
>    considerations apply to the distribution of Shared Secret Data,
>    which is already transmitted between nodes in the ANSI-41
network.)
> 
> 
> As I understand the actual implementation, the MN-HA key (and
others)
> are protected using the technique in 2868.  If that is true then,
the
> authors should state that in the document.  
> 
> Regarding Bernard's comment on Message-Authenticator.  Not 100%
sure,
> but our opinion is that Message-Authenticator is not required. The
> procedure is end-to-end and does have a MITM vunerability (see
their
> comment) and we are not sure whether the use of message
authenticator
> will improve security.  We would have preffered to see
> Message-Authenticator.     
> 
> Avi
> 
>> -----Original Message-----
>> From: Glen Zorn (gwz) [mailto:[email-masked]]
>> Sent: Thursday, March 03, 2005 6:30 PM
>> To: 'Thomas Narten'; 'Avi Lior'
>> Cc: 'Frank Quick'; [email-masked];
>> [email-masked]; 'W. Mark Townsley'
>> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
>> 
>> 
>> Thomas Narten <mailto:[email-masked]> supposedly scribbled:
>> 
>> ...
>> 
>>> 
>>> Given that the protocol is deployed, and most folks seem to
think
>>> it's better to document something (that is widely deployed) than
>>> not, 
>> 
>> It's not clear to me that this protocol is widely deployed, but
>> possibly my understanding of the term is deficient.  My
understanding
>> is that this is a proprietary protocol, deployed in a single 3G
>> cellular network (Verizon); furthermore it appears that this
protocol
>> will only be useful with so-called "captive" mobile devices, and
not
>> in a roaming environment.  If I'm correct on those points, then I
>> wouldn't consider it to be "widely deployed".
>> 
>>> adding such a note as outlined above seems like a reasonable way
>>> out (to me). 
>>> 
>>> What do others think? Which particual radius extensions would
need
>>> to be called out for attention?
>> 
>> The only actual violations that I can see are 1) the inclusion of
>> vendor-specific attributes in the Access-Reject message and 2)
the
>> redefinition of the semantics of the Access-Reject message to
_not_
>> terminate the PPP connection. Given your explanation (not
>> reproduced), I suppose we must ignore the security
issues/questions
>> raised by Bernard & myself. 
>> 
>>> 
>>> Thomas
>> 
>> 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

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Thu, 03 Mar 2005 23:48:32 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, 'Thomas Narten' <[email-masked]>
Cc: Avi Lior <[email-masked]>, 'Frank Quick' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 18:48:19 -0500 

> Since this is an individual submission & not a WG document, I 
> wouldn't feel at all comfortable dictating text to the 
> authors.  My guess is that this is between them and the IESG (sorry!).

But we can help.  And actually - although I wasn't around at the start - I
think we should have done something about this earlier. Since we all
indicated that we knew about the Access-Reject problem.

I know that Thomas asked 3GPP2 and 3GPP2 did review the document from their
prespective.

> > 
> > - Mark
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 

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

Delivery-date: Thu, 03 Mar 2005 23:43:41 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, 'Thomas Narten' <[email-masked]>,  Avi Lior <[email-masked]>
Cc: 'Frank Quick' <[email-masked]>, [email-masked],  [email-masked], "'W. Mark Townsley'" <[email-masked]>,  "Nelson, David" <[email-masked]>, Bernard Aboba <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 18:43:09 -0500 

Note that we currently have a draft in MIPv4 WG to define a similar
procedure.

Okay....

Here is some proposed text....What do people think.

This document extends RADIUS in the following way:

The document returns an attribute in an Access-Reject message. According to
RFC-2865 an Access-Reject packet MAY only include Reply-Message and
Proxy-State.

Subsequent RFCs allow for other attributes to be included in an
Access-Reject packet but these are included to indicate the reason the
authentication/authorization has failed.  Given the use in this document an
Access-Challenge packet would have been more appropriate.

Regarding Bernards comment:

7.9 Network Message Security

   The security of the MN-HA keys delivered from the RADIUS AAA server
   to the MIP home agent requires confidentiality for network messages
   containing such keys.  The specification of security requirements for
   network messages is the responsibility of the operator, and is
   outside the scope of this document. (Note that similar considerations
   apply to the distribution of Shared Secret Data, which is already
   transmitted between nodes in the ANSI-41 network.)

As I understand the actual implementation, the MN-HA key (and others) are
protected using the technique in 2868.  If that is true then, the authors
should state that in the document. 

Regarding Bernard's comment on Message-Authenticator.  Not 100% sure, but
our opinion is that Message-Authenticator is not required. The procedure is
end-to-end and does have a MITM vunerability (see their comment) and we are
not sure whether the use of message authenticator will improve security.  We
would have preffered to see Message-Authenticator.

Avi

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Thursday, March 03, 2005 6:30 PM
> To: 'Thomas Narten'; 'Avi Lior'
> Cc: 'Frank Quick'; [email-masked]; 
> [email-masked]; 'W. Mark Townsley'
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> Thomas Narten <mailto:[email-masked]> supposedly scribbled:
> 
> ...
> 
> > 
> > Given that the protocol is deployed, and most folks seem to 
> think it's 
> > better to document something (that is widely deployed) than
> not,
> 
> It's not clear to me that this protocol is widely deployed, 
> but possibly my understanding of the term is deficient.  My 
> understanding is that this is a proprietary protocol, 
> deployed in a single 3G cellular network (Verizon); 
> furthermore it appears that this protocol will only be useful 
> with so-called "captive" mobile devices, and not in a roaming 
> environment.  If I'm correct on those points, then I wouldn't 
> consider it to be "widely deployed".
> 
> > adding such a note as outlined above seems like a reasonable way
> out
> > (to me).   
> > 
> > What do others think? Which particual radius extensions would need
> to
> > be called out for attention?
> 
> The only actual violations that I can see are 1) the 
> inclusion of vendor-specific attributes in the Access-Reject 
> message and 2) the redefinition of the semantics of the 
> Access-Reject message to _not_ terminate the PPP connection.  
> Given your explanation (not reproduced), I suppose we must 
> ignore the security issues/questions raised by Bernard & myself.
> 
> > 
> > Thomas
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 

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

Delivery-date: Thu, 03 Mar 2005 23:30:08 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'W. Mark Townsley'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>
Cc: "'Avi Lior'" <[email-masked]>, "'Frank Quick'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 15:29:44 -0800

W. Mark Townsley <mailto:[email-masked]> supposedly scribbled:

> Thomas Narten wrote:
> 
>> What do others think? Which particual radius extensions would
need to
>> be called out for attention?
> 
> I think it would be prudent to document the specific ways in which
> radius was extended in an offensive manner. Hopefully, that would
> limit this document becoming any sort of precedent for further
abuse.

I think that that is a great goal, but...

> Can someone sign up to include this in the document? Glen? Avi?
> Others?   

Since this is an individual submission & not a WG document, I
wouldn't feel at all comfortable dictating text to the authors.  My
guess is that this is between them and the IESG (sorry!).

> 
> - Mark

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Thu, 03 Mar 2005 23:30:00 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Thomas Narten'" <[email-masked]>, "'Avi Lior'" <[email-masked]>
Cc: "'Frank Quick'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Date: Thu, 3 Mar 2005 15:29:44 -0800

Thomas Narten <mailto:[email-masked]> supposedly scribbled:

...

> 
> Given that the protocol is deployed, and most folks seem to think
> it's better to document something (that is widely deployed) than
not,

It's not clear to me that this protocol is widely deployed, but
possibly my understanding of the term is deficient.  My
understanding is that this is a proprietary protocol, deployed in a
single 3G cellular network (Verizon); furthermore it appears that
this protocol will only be useful with so-called "captive" mobile
devices, and not in a roaming environment.  If I'm correct on those
points, then I wouldn't consider it to be "widely deployed".

> adding such a note as outlined above seems like a reasonable way
out
> (to me).   
> 
> What do others think? Which particual radius extensions would need
to
> be called out for attention? 

The only actual violations that I can see are 1) the inclusion of
vendor-specific attributes in the Access-Reject message and 2) the
redefinition of the semantics of the Access-Reject message to _not_
terminate the PPP connection.  Given your explanation (not
reproduced), I suppose we must ignore the security issues/questions
raised by Bernard & myself.

> 
> Thomas

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Thu, 03 Mar 2005 23:07:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 18:07:24 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Cc: "Thomas Narten" <[email-masked]>, <[email-masked]>, "Frank Quick" <[email-masked]>, <[email-masked]>, <[email-masked]>

> Hopefully, this is not going to require a huge debate.

The major issue is that the draft specifies the inclusion of an
attribute in an Access-Reject message, that has the effect of causing
some key [re]generation, and then a follow-up Access-Request message.

It was pointed out that the traditional way RADIUS accomplishes this
sort of interaction is with an Access-Request, Access-Challenge,
Access-Request message sequence, NOT an Access-Request, Access-Reject,
Access-Request message sequence, in which the NAS does not drop the
session to the client upon receiving the Access-Reject.

It was also pointed out that expecting (or allowing) a NAS to do
anything other than drop the session to the attached client upon
receiving an Access-Reject (with the possible exception of passing a
reject reason code or message to the client first) is a major departure
for RADIUS and a serious security concern.  Access-Reject has always
meant that no access is granted and that the client session is ended.
One of those "no means no" things.

Other issues have been raised, as well.=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, 03 Mar 2005 22:54:13 +0000
From: Avi Lior <[email-masked]>
To: "'W. Mark Townsley'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: Thomas Narten <[email-masked]>, "[email-masked]'" <[email-masked]>,  'Frank Quick' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 17:53:59 -0500 

I like Mr. Nelson's comment.

So we just need to specify the issues and IESG will take care of rest.

Hopefully, this is not going to require a huge debate.

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]] 
> Sent: Thursday, March 03, 2005 5:50 PM
> To: Avi Lior
> Cc: Thomas Narten; [email-masked]'; 'Frank Quick'; 
> [email-masked]; [email-masked]
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> 
> 
> Avi Lior wrote:
> 
> > Mark,
> > 
> > Well we can make further comments but are you asking us to edit the 
> > document?
> 
> Personally, I would like to see it as part of the permanent 
> record in the 
> easiest place to find. So, yes, in the document.
> 
> - Mark
> 
> > 
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: W. Mark Townsley [mailto:[email-masked]]
> >>Sent: Thursday, March 03, 2005 5:26 PM
> >>To: Thomas Narten
> >>Cc: Avi Lior; [email-masked]'; 'Frank Quick'; 
> >>[email-masked]; [email-masked]
> >>Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> >>
> >>
> >>
> >>
> >>Thomas Narten wrote:
> >>
> >>
> >>>What do others think? Which particual radius extensions
> >>
> >>would need to
> >>
> >>>be called out for attention?
> >>
> >>I think it would be prudent to document the specific ways in
> >>which radius was 
> >>extended in an offensive manner. Hopefully, that would limit 
> >>this document 
> >>becoming any sort of precedent for further abuse. Can someone 
> >>sign up to include 
> >>this in the document? Glen? Avi? Others?
> >>
> >>- Mark
> >>
> > 
> > 
> 

--
to unsubscribe send 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, 03 Mar 2005 22:44:59 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 17:44:25 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "W. Mark Townsley" <[email-masked]>, "Thomas Narten" <[email-masked]>
Cc: <[email-masked]>, "Frank Quick" <[email-masked]>, <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Well we can make further comments but are you asking us to edit the
> document?

No.  The added notations, as suggested by Thomas Narten, would be added
by the IESG in a memo to the RFC Editor regarding publication of this
draft.  We simply need to get an agreement on the short (one or two
paragraph) description of the issues.  My understanding is that the IESG
will take it from there.

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

Delivery-date: Thu, 03 Mar 2005 22:38:53 +0000
From: Avi Lior <[email-masked]>
To: "'W. Mark Townsley'" <[email-masked]>, Thomas Narten <[email-masked]>
Cc: Avi Lior <[email-masked]>, "[email-masked]'" <[email-masked]>, 'Frank Quick' <[email-masked]>,  [email-masked], [email-masked]
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 17:37:36 -0500 

Mark,

Well we can make further comments but are you asking us to edit the
document?

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]] 
> Sent: Thursday, March 03, 2005 5:26 PM
> To: Thomas Narten
> Cc: Avi Lior; [email-masked]'; 'Frank Quick'; 
> [email-masked]; [email-masked]
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> 
> 
> Thomas Narten wrote:
> 
> > What do others think? Which particual radius extensions 
> would need to 
> > be called out for attention?
> 
> I think it would be prudent to document the specific ways in 
> which radius was 
> extended in an offensive manner. Hopefully, that would limit 
> this document 
> becoming any sort of precedent for further abuse. Can someone 
> sign up to include 
> this in the document? Glen? Avi? Others?
> 
> - Mark
> 

--
to unsubscribe send 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: Thu, 03 Mar 2005 21:14:11 +0000
Message-Id: <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'Frank Quick'" <[email-masked]>, [email-masked], [email-masked], "'W. Mark Townsley'" <[email-masked]>
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt 
Date: Thu, 03 Mar 2005 16:13:43 -0500
From: Thomas Narten <[email-masked]>

> Perhaps the way forward is to make a note of the "error(s)" in the
> Informational RFC?

Some background, so we're all on the same page. If this document were
submitted to the RFC editor today, it would be reviewed by the IESG
under the rules outlined in RFC 3932. In this case, the document would
fall under the following consideration (from Section 3):

   5. The IESG thinks that this document extends an IETF protocol in a
      way that requires IETF review and should therefore not be
      published without IETF review and IESG approval.

As is being discussed, the document does extend radius.

All RFC Editor submissions (i.e., those not approved by the IETF) now
get published with a standard disclaimer (See Section 4 of RFC
3932). In this case, the standard note would have been:

   2. For documents that specify a protocol or similar technology and
      are independent of the IETF process:

      This RFC is not a candidate for any level of Internet Standard.
      The IETF disclaims any knowledge of the fitness of this RFC for
      any purpose and in particular notes that the decision to publish
      is not based on IETF review for such things as security,
      congestion control, or inappropriate interaction with deployed
      protocols.  The RFC Editor has chosen to publish this document at
      its discretion.  Readers of this document should exercise caution
      in evaluating its value for implementation and deployment.  See
      RFC 3932 for more information.

But, since this document does extend radius in ways that the IETF
apparently is not comfortable with, the above disclaimer may not be
enough.  The IESG is quite willing to take the above disclaimer and
extend/modify it to describe what sort of IETF review it received and
what the IETF concerns are (w.r.t. to its extensions of our
protocols.) Thus, one possibility would be to add to the document an
IESG note that includes the above disclaimer plus adds to it based on
the concerns w.r.t. radius.

For example, So I think a disclaimer could also say something like:

   This protocol makes use of and extends the IETF Radius protocol
   (RFC XXX). It has been reviewed by the Radius community and the
   following issues have been noted ....

and then list the violations and perhaps provide some explanation as
to why those violations are considered inappropriate or how serious
they are. Not a lot of text, but maybe one or two paragraphs total
would be best.

Given that the protocol is deployed, and most folks seem to think it's
better to document something (that is widely deployed) than not,
adding such a note as outlined above seems like a reasonable way out
(to me).

What do others think? Which particual radius extensions would need to
be called out for attention?

Thomas    

--
to unsubscribe send 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, 03 Mar 2005 20:37:47 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, 'Frank Quick' <[email-masked]>,  [email-masked]
Cc: [email-masked], "'W. Mark Townsley'" <[email-masked]>,  Thomas Narten <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 15:37:34 -0500 

Well Glen is right we all noticed it.

But originally DMU was for Verizon only and instead of making waves we just
let it slide - since it was already being deployed.

So maybe that was the wrong thing to do.

Perhaps the way forward is to make a note of the "error(s)" in the
Informational RFC?

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Thursday, March 03, 2005 2:08 PM
> To: 'Frank Quick'; [email-masked]
> Cc: [email-masked]; 'W. Mark Townsley'; Thomas Narten
> Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> Frank Quick <mailto:[email-masked]> supposedly scribbled:
> 
> > You're not the first to raise these issues.
> 
> Actually I think that I might have been the first, several 
> years ago, I certainly must not be the only one since I would 
> expect anyone with a cursory knowledge of RFC 2865 and more 
> than 3 firing neurons (I think I still have 4 or 5 ;-) to 
> make the same observations. 
> 
> > Had the protocol not
> > already been deployed in millions of EV-DO devices, we might be
> able
> > to make such changes.
> 
> Does Verizon really have millions of PDSNs deployed?  
> 
> > But since it is deployed, and working, changes
> > aren't feasible.   
> > 
> > I suppose that if IETF had an interest in creating a new, 
> > standards-track version of DMU, that version could include changes
> to
> > address the issues that have been identified.
> > 
> > Regarding the "violation" of 2865, this is not the only use of 
> > vendor-specific attributes in access reject messages; other RFCs
> also
> > do this.
> 
> I am apparently ignorant of these RFCs; would you mind 
> providing references to them?
> 
> > IMHO, the restriction on VSA in 2865 is unnecessary; and 
> since we seem 
> > to be able to do it without negative consequences,
> the
> > restriction is also impractical to enforce.
> 
> Indeed; in fact, standards have little use in a closed 
> system.  I actually see the inclusion of VSAs as a relatively 
> minor offense; in my mind the modification of the 
> Access-Reject semantics is much more serious.
> 
> > As I pointed out to
> > others, IETF may be able to block the publication of this draft as
> an
> > RFC, but they are powerless to prevent DMU from being used as is.
> I
> > don't see the harm in making the protocol publicly 
> available as an RFC 
> > for those who may want to make interoperable devices.
> 
> If the RADIUS portion of the protocol had been designed 
> correctly, it would have automatically been interoperable and 
> we wouldn't be having this conversation.  As for harm & 
> benefit, the harm lies in the IETF laying its imprimatur 
> (even as informational) upon a document which rather brazenly 
> violates an IETF standard; it's difficult to see the benefit 
> in publishing what amounts to an advertisement for 
> Verizon/Qualcomm IPR.  It's a shame, because portions of the 
> draft are really quite clever.
>   
> > 
> > The security of the protocol in general is somewhat minimal, but 
> > conforms to the customer requirements.  A saving grace is that the 
> > terminal cannot initiate DMU unless it is enabled by the 
> network. That 
> > limits the window for any type of attack to the brief period
> > when DMU is enabled.    
> > 
> > At 10:44 PM 3/2/2005 -0800, Glen Zorn \(gwz\) wrote:
> >> Hi.  I was recently asked to review this document and during the 
> >> review I noticed a couple of problems.  In particular, the
> document
> >> appears to unnecessarily violate RFC 2865.  For example: "The
> RADIUS
> >> AAA Server MUST support a subscriber specific MIP Update 
> State Field.  
> >> When the MIP Update State Field set to UPDATE KEYS (1),
> the
> >> RADIUS AAA Server MUST initiate the DMU procedure by including
> the
> >> MIP_Key_Request attribute in an Access Reject message sent to the 
> >> PDSN...Note that the inclusion of a vendor-specific attribute in
> the
> >> Access Reject message is not consistent with section 5.44 of [4].
> A
> >> RADIUS AAA server that supports DMU SHOULD NOT include a 
> >> vendor-specific attribute if the corresponding Access 
> Request message 
> >> was not received from a DMU-compliant PDSN."  However,
> the
> >> PPP connection is not closed, even though an Access-Reject was 
> >> received (thus modifying the semantics of the 
> Access-Reject message).  
> >> Looking at section 4.11, however, it appears that
> these
> >> violations could easily be avoided through the use of 
> >> Access-Challenge instead of Access-Reject.  Is there some reason
> why
> >> you feel that Access-Challenge is inappropriate in this
> situation? 
> >> 
> >> 
> >> In addition, I couldn't find any reference to message integrity 
> >> protection.  Did I just miss it?
> >> 
> >> ~gwz
> > 
> > 
> > Frank Quick
> > office   +1-858-658-3608 fax +1-858-651-1940
> > portable +1-619-890-5749
> > paging   [email-masked]
> > RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> > D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D
> 
> 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/>
> 

--
to unsubscribe send 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, 03 Mar 2005 20:30:07 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Frank Quick'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, "'Thomas Narten'" <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 12:29:37 -0800

Frank Quick <mailto:[email-masked]> supposedly scribbled:

...

>> Does Verizon really have millions of PDSNs deployed?
> 
> I was thinking of the terminals.  

Yeah, but the RADIUS changes only effect the PDSN <-> AAA interface,
right?

> Maybe the numbers are not as
> impressive for PDSNs, but the infrastructure is still installed
and
> operating.  Whether Verizon would be interested in changing the
> infrastructure is up to them.   
> 
>>> But since it is deployed, and working, changes aren't feasible.
>>> 
>>> I suppose that if IETF had an interest in creating a new,
>>> standards-track version of DMU, that version could include
changes
>>> to address the issues that have been identified.
>>> 
>>> Regarding the "violation" of 2865, this is not the only use of
>>> vendor-specific attributes in access reject messages; other RFCs
>>> also do this.
>> 
>> I am apparently ignorant of these RFCs; would you mind providing
>> references to them?
> 
> Possible memory failure on my part.  RFC 2869 and RFC 3579 have
> attributes in Access Reject, but probably not VSA.  On the other
> hand, the principle is this: if these RFCs can create new
attributes
> and add them to the Access Reject, then vendors should have the
> freedom to do the same with VSAs.    
> 
>>> IMHO, the restriction on VSA in 2865 is unnecessary; and since
we
>>> seem to be able to do it without negative consequences, the
>>> restriction is also impractical to enforce.
>> 
>> Indeed; in fact, standards have little use in a closed system.  I
>> actually see the inclusion of VSAs as a relatively minor offense;
in
>> my mind the modification of the Access-Reject semantics is much
more
>> serious.
> 
> I still don't understand why it's so serious.

If a standard RADIUS client receives an Access-Reject, it closes the
relevant connection.  So, outside Verizon's walled garden, this
protocol would always fail, irrespective of whether the client was
generous enough to accept a VSA in an Access-Reject.

> 
>>> As I pointed out to
>>> others, IETF may be able to block the publication of this draft
as
>>> an RFC, but they are powerless to prevent DMU from being used as
>>> is. I don't see the harm in making the protocol publicly
available
>>> as an RFC for those who may want to make interoperable devices.
>> 
>> If the RADIUS portion of the protocol had been designed
correctly, it
>> would have automatically been interoperable and we wouldn't be
having
>> this conversation.  As for harm & benefit, the harm lies in the
IETF
>> laying its imprimatur (even as informational) upon a document
which
>> rather brazenly violates an IETF standard; it's difficult to see
the
>> benefit in publishing what amounts to an advertisement for
>> Verizon/Qualcomm IPR.  It's a shame, because portions of the
draft
>> are really quite clever. 
>> 
> 
> Thanks for the flames.

My original intent was not to flame you, and I assure you that I
mean no personal affront.  

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Thu, 03 Mar 2005 20:21:15 +0000
From: Avi Lior <[email-masked]>
To: 'Jari Arkko' <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked], Tschofenig Hannes <[email-masked]>
Subject: RE: [Geopriv] Re: Radius-Geopriv: When to send location info?
Date: Thu, 3 Mar 2005 15:20:30 -0500 

Hi folks,

The problem is this,  assuming that you have a Location Capable NAS that
sends location only on request, then in a scenario where the AAA always
requires it, then you will be introducing another exchange FOR every
REQUEST.  So that is clearly bad.  However, if EAP is being used then this
is not an issue since we already have a challenge happening.

So perhaps we can do the following (just thinking out loud).

1) The NAS (based on local policies) may be configured to send location info
to the home network. So in some deployments that is what it will do because
that is how they will want it to be used.

2) The NAS does not send the location information. But the home network may
challenge for it. Hence forth for that session it will continue to send that
information.

In step 2) how does the home network know that the NAS support location
information capability.  Well the NAS simply advertizes this using
Capability Exchange see our draft for that in RADEXT.

Note that in step 2 the home AAA needs to request location information.  We
can invent an attribute for that but this is yet another example where the
AAA can also include the Capability attribute to indicate that it MUST have
location, or that location information SHOULD be provided.

Note we had a debate whether or not the capability exchange should also come
from the home network. This is a clear case of such example.  SO the NAS
says "Hey I can deliver Location Information" the HOME Server says "Hey I
MUST have location information, or I it would be nice if you could deliver
location information" -- you get the drift.

But Capability Exchange is still drafty.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, March 03, 2005 3:09 PM
> To: Bernard Aboba
> Cc: [email-masked]; [email-masked]; Tschofenig Hannes
> Subject: [Geopriv] Re: Radius-Geopriv: When to send location info?
> 
> 
> Bernard Aboba wrote:
> 
> >>[hannes] to me it seems reasonable not to include location 
> information 
> >>with every request. a  visited network which knows that it 
> has to send 
> >>location information to a particular home network  might do 
> so. i also 
> >>think that it would be good to have an error attribute to indicate 
> >>that it was  not possible to authorize the user properly 
> based on the 
> >>missing location information.
> >>
> >>we have added the usage of the error-cause attribute. 
> within the iana 
> >>section we need to register  a new type:
> >>    
> >>
> >
> >I am confused by the model that is described here.  I could 
> understand 
> >why the NAS might not send the NAS location with every 
> Access-Request.  
> >But user location is another matter.  If the NAS is set up 
> to send user 
> >location data, why would it not send it on each request?
> >
> >My reading of RFC 2865 is that service provisioning attributes 
> >(including
> >VSAs) are forbidden in a RADIUS Access-Reject.  However, 
> information on
> >why the request failed is ok (e.g. Reply-Message, 
> EAP-Message/EAP-Failure,
> >etc.).  So I think that Error-Cause can be included.
> >
> >However, Error-Cause will not solve the problem that is 
> described.  If 
> >the NAS is not sending User location on every Access-Request and the 
> >server requires this, then every Access-Request that is sent without 
> >the user location will be denied.
> >
> >I'd suggest that language be included in the document to say 
> that "by 
> >default, a NAS that is set up to provide user location 
> information to 
> >the RADIUS server MUST provide this information in every 
> >Access-Request."
> >  
> >
> 
> Yes. I would in fact extend this by having the NAS send this 
> information in the first place if and only if the home AAA 
> earlier instructed the NAS to do so for this specific 
> session. The cost would be very small, no additional 
> roundtrips for instance.
> 
> --Jari
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

--
to unsubscribe send 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, 03 Mar 2005 20:10:11 +0000
Date: Thu, 03 Mar 2005 22:09:24 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Tschofenig Hannes <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: When to send location info?

Bernard Aboba wrote:

>>[hannes] to me it seems reasonable not to include location information with
>>every request. a  visited network which knows that it has to send location
>>information to a particular home network  might do so. i also think that it
>>would be good to have an error attribute to indicate that it was  not
>>possible to authorize the user properly based on the missing location
>>information.
>>
>>we have added the usage of the error-cause attribute. within the iana
>>section we need to register  a new type:
>>    
>>
>
>I am confused by the model that is described here.  I could understand why
>the NAS might not send the NAS location with every Access-Request.  But
>user location is another matter.  If the NAS is set up to send user
>location data, why would it not send it on each request?
>
>My reading of RFC 2865 is that service provisioning attributes (including
>VSAs) are forbidden in a RADIUS Access-Reject.  However, information on
>why the request failed is ok (e.g. Reply-Message, EAP-Message/EAP-Failure,
>etc.).  So I think that Error-Cause can be included.
>
>However, Error-Cause will not solve the problem that is described.  If the
>NAS is not sending User location on every Access-Request and the server
>requires this, then every Access-Request that is sent without the user
>location will be denied.
>
>I'd suggest that language be included in the document to say that "by
>default, a NAS that is set up to provide user location information to the
>RADIUS server MUST provide this information in every Access-Request."
>  
>

Yes. I would in fact extend this by having the NAS send this
information in the first place if and only if the home AAA
earlier instructed the NAS to do so for this specific session.
The cost would be very small, no additional roundtrips for
instance.

--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, 03 Mar 2005 19:08:01 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Frank Quick'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, "Thomas Narten" <[email-masked]>
Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 11:07:39 -0800

Frank Quick <mailto:[email-masked]> supposedly scribbled:

> You're not the first to raise these issues.  

Actually I think that I might have been the first, several years
ago, I certainly must not be the only one since I would expect
anyone with a cursory knowledge of RFC 2865 and more than 3 firing
neurons (I think I still have 4 or 5 ;-) to make the same
observations. 

> Had the protocol not
> already been deployed in millions of EV-DO devices, we might be
able
> to make such changes.  

Does Verizon really have millions of PDSNs deployed?  

> But since it is deployed, and working, changes
> aren't feasible.   
> 
> I suppose that if IETF had an interest in creating a new,
> standards-track version of DMU, that version could include changes
to
> address the issues that have been identified.  
> 
> Regarding the "violation" of 2865, this is not the only use of
> vendor-specific attributes in access reject messages; other RFCs
also
> do this.  

I am apparently ignorant of these RFCs; would you mind providing
references to them?

> IMHO, the restriction on VSA in 2865 is unnecessary; and
> since we seem to be able to do it without negative consequences,
the
> restriction is also impractical to enforce.  

Indeed; in fact, standards have little use in a closed system.  I
actually see the inclusion of VSAs as a relatively minor offense; in
my mind the modification of the Access-Reject semantics is much more
serious.

> As I pointed out to
> others, IETF may be able to block the publication of this draft as
an
> RFC, but they are powerless to prevent DMU from being used as is.
I
> don't see the harm in making the protocol publicly available as an
> RFC for those who may want to make interoperable devices.  

If the RADIUS portion of the protocol had been designed correctly,
it would have automatically been interoperable and we wouldn't be
having this conversation.  As for harm & benefit, the harm lies in
the IETF laying its imprimatur (even as informational) upon a
document which rather brazenly violates an IETF standard; it's
difficult to see the benefit in publishing what amounts to an
advertisement for Verizon/Qualcomm IPR.  It's a shame, because
portions of the draft are really quite clever.
  
> 
> The security of the protocol in general is somewhat minimal, but
> conforms to the customer requirements.  A saving grace is that the
> terminal cannot initiate DMU unless it is enabled by the network. 
> That limits the window for any type of attack to the brief period
> when DMU is enabled.    
> 
> At 10:44 PM 3/2/2005 -0800, Glen Zorn \(gwz\) wrote:
>> Hi.  I was recently asked to review this document and during the
>> review I noticed a couple of problems.  In particular, the
document
>> appears to unnecessarily violate RFC 2865.  For example: "The
RADIUS
>> AAA Server MUST support a subscriber specific MIP Update State
>> Field.  When the MIP Update State Field set to UPDATE KEYS (1),
the
>> RADIUS AAA Server MUST initiate the DMU procedure by including
the
>> MIP_Key_Request attribute in an Access Reject message sent to the
>> PDSN...Note that the inclusion of a vendor-specific attribute in
the
>> Access Reject message is not consistent with section 5.44 of [4].
A
>> RADIUS AAA server that supports DMU SHOULD NOT include a
>> vendor-specific attribute if the corresponding Access Request
>> message was not received from a DMU-compliant PDSN."  However,
the
>> PPP connection is not closed, even though an Access-Reject was
>> received (thus modifying the semantics of the Access-Reject
>> message).  Looking at section 4.11, however, it appears that
these
>> violations could easily be avoided through the use of
>> Access-Challenge instead of Access-Reject.  Is there some reason
why
>> you feel that Access-Challenge is inappropriate in this
situation? 
>> 
>> 
>> In addition, I couldn't find any reference to message integrity
>> protection.  Did I just miss it?
>> 
>> ~gwz
> 
> 
> Frank Quick
> office   +1-858-658-3608 fax +1-858-651-1940
> portable +1-619-890-5749
> paging   [email-masked]
> RSA: 29EA D619 31F2 B4D3  8815 3D59 4340 FA43
> D-H: 2A24 131C D38F 12E6 4D6A  46EE 8BBF B50A 754E F63D

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Thu, 03 Mar 2005 18:17:37 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "'W. Mark Townsley'" <[email-masked]>, "Thomas Narten" <[email-masked]>
Subject: FW: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Thu, 3 Mar 2005 10:16:52 -0800

Adding the authors and other interested parties...

>> In addition, I couldn't find any reference to message integrity
>> protection.  Did I just miss it?
> 
> The document does not contain an attribute table listing what
> attributes are sent in which messages, so it's hard to tell what
> attributes are required/permitted/disallowed in which messages.
But
> "Message-Authenticator" is not mentioned anywhere in the document,
> which seems to imply that Message-Authenticator it is not required
to
> be present in Access-Request messages.     
> 
> Also, Section 7.9 seems to specify that RADIUS messages are
> encrypted, but not  how: 
> 
> 7.9 Network Message Security
> 
>    The security of the MN-HA keys delivered from the RADIUS AAA
server
>    to the MIP home agent requires confidentiality for network
messages
>    containing such keys.  The specification of security
requirements
>    for network messages is the responsibility of the operator, and
is
>    outside the scope of this document. (Note that similar
>    considerations apply to the distribution of Shared Secret Data,
>    which is already transmitted between nodes in the ANSI-41
network.)

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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

Delivery-date: Thu, 03 Mar 2005 16:32:00 +0000
From: Mark Jones <[email-masked]>
To: "'Joel M. Halpern'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [Geopriv] Re: Radius-Geopriv: CDMA operator-name prefix / reg istry
Date: Thu, 3 Mar 2005 11:31:41 -0500 

> It also states that the REALM operator identification type 
> contains values 
> registered within IANA.  And it says nothing more about it 
> other than that 
> IANA shall maintain the registry.
> Realm (DNS domain) is entirely reasonable to use as an 
> operator identification.
> However, what I was objecting to is creating another registry for it.
> 

Sorry, Joel, the text is unclear. It was not my intention to have IANA
maintain another registry for domains. To my understanding, IANA was already
the registry for the TLDs and delegated management to other registry owners.
However, I understand that responsibility for domain name functions passed
from IANA to ICANN so I will update the draft accordingly and clarify that
this is not a new domain registry.

Thanks
Mark

--
to unsubscribe send 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, 03 Mar 2005 15:44:20 +0000
Date: Thu, 03 Mar 2005 10:43:57 -0500
To: <[email-masked]>,<[email-masked]>, <[email-masked]>,<[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: [Geopriv] Re: Radius-Geopriv: CDMA operator-name prefix / registry

The IANA considerations created two things.
It created the type registry.  That is quite understandable.  (And given 
the stated goal of allowing folks to keep doing what they are already 
doing, probably necessary.)

It also states that the REALM operator identification type contains values 
registered within IANA.  And it says nothing more about it other than that 
IANA shall maintain the registry.
Realm (DNS domain) is entirely reasonable to use as an operator identification.
However, what I was objecting to is creating another registry for it.

Yours,
Joel

At 08:38 AM 3/3/2005, [email-masked] wrote:
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> > Sent: 2. maaliskuuta 2005 15:46
> > To: Tschofenig Hannes; [email-masked]; [email-masked]
> > Subject: [Geopriv] Re: Radius-Geopriv: CDMA operator-name
> > prefix / registry
> >
> > This creates the requirement that IANA maintain a registry of
> > operators.
>
>Isn't that just a list of "operator types", which is relatively
>small amount of information? Actual management of operators is
>delegated to appropriate organizations identified by the operator
>type.
>
> > Why not declare that any entity that owns a domain name by proper
> > delegation (reference DNS documents) may use that string as a realm?
> > That avoids creating yet another registry.
> >
> > It would also seem sensible, given such a strategy, to at
> > least comment on
> > why the other two values are necessary.

--
to unsubscribe send 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, 03 Mar 2005 15:24:46 +0000
Date: Thu, 3 Mar 2005 07:24:15 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: [email-masked]
Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt

> In addition, I couldn't find any reference to message integrity
> protection.  Did I just miss it?

The document does not contain an attribute table listing what attributes
are sent in which messages, so it's hard to tell what attributes are
required/permitted/disallowed in which messages.  But
"Message-Authenticator" is not mentioned anywhere in the document,
which seems to imply that Message-Authenticator it is not required to be
present in Access-Request messages.

Also, Section 7.9 seems to specify that RADIUS messages are encrypted, but
not  how:

7.9 Network Message Security

   The security of the MN-HA keys delivered from the RADIUS AAA server
   to the MIP home agent requires confidentiality for network messages
   containing such keys.  The specification of security requirements for
   network messages is the responsibility of the operator, and is
   outside the scope of this document. (Note that similar considerations
   apply to the distribution of Shared Secret Data, which is already
   transmitted between nodes in the ANSI-41 network.)

--
to unsubscribe send 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, 03 Mar 2005 13:39:48 +0000
content-class: urn:content-classes:message
Subject: RE: [Geopriv] Re: Radius-Geopriv: CDMA operator-name prefix / registry
Date: Thu, 3 Mar 2005 15:38:53 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Joel,

Few comments inline..

Cheers,
	Jouni

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 2. maaliskuuta 2005 15:46
> To: Tschofenig Hannes; [email-masked]; [email-masked]
> Subject: [Geopriv] Re: Radius-Geopriv: CDMA operator-name=20
> prefix / registry
>=20
> This creates the requirement that IANA maintain a registry of=20
> operators.

Isn't that just a list of "operator types", which is relatively
small amount of information? Actual management of operators is
delegated to appropriate organizations identified by the operator=20
type.

> Why not declare that any entity that owns a domain name by proper=20
> delegation (reference DNS documents) may use that string as a realm?
> That avoids creating yet another registry.
>=20
> It would also seem sensible, given such a strategy, to at=20
> least comment on=20
> why the other two values are necessary.  After all, any=20

The Operator-name attribute requirement originates from
the GSM operators WLAN roaming community. They have great interest
to reuse existing GSM/GPRS roaming model & systems, where TADIG
codes (to what the draft refers to) are used to identify operators
and roaming partners.

I don't really know the position of CDMA operators.

> operator in the=20
> other two spaces also has a domain name.
> If we are going to allow the other two name spaces, then can=20
> we have a=20
> reference to a public document containing the binding of=20
> identifier to=20
> entity, so that one may build interoperable implementations?

The TADIG code (for GSM operator-type) procedures are described in:

"TADIG Code Naming Conventions", Permanent Reference Document TD.13,
 Version 3.12.14, GSM Association, 20 May 2004.

IOC procedures for HNI stuff are described in:

"International Mobile Subscriber Identity (IMSI) Assignment and=20
 Management Guidelines and Procedures", Version 6.0,=20
 IMSI Oversight Council (IOC), June 2004.

> Thank you,
> Joel M. Halpern
>=20
> At 05:22 AM 3/2/2005, Tschofenig Hannes wrote:
> >hi all,
> >
> >the operator-name lead to a long discussion on the mailing list. the
> >discussion is far too long to copy-and-paste it into this=20
> mail. hence, we
> >only show the proposed resolution of the issue:
> >
> >The previously used attribute is split into two attributes.=20
> Below you find
> >the new text  including the relevant parts of the IANA section:
> >
> >"
> >5.1  Operator-Type Attribute
> >
> >    This attribute contains an operator type which combined with the
> >    Operator-Name attribute serves to uniquely identify the=20
> ownership of
> >    an access network.  The attribute value is a four octet integer.
> >    This document defines three values for this attribute: 1 (GSM), 2
> >    (CDMA), and 3 (REALM).  Additional values require an IANA
> >    registration and MUST be associated with an organization=20
> responsible
> >    for assigning/managing the operator names.
> >
> >    The GSM operator type can be used to indicate operator=20
> names based on
> >    GSMA TADIG codes.  The TADIG Working Group within the=20
> GSM Association
> >    is the authority responsible for issuing unique=20
> Operator-Name values
> >    for operators of this type.
> >
> >    The CDMA operator type can be used to indicate operator=20
> names based
> >    on the Home Network Identifier (HNI).  The HNI is the=20
> concatenation
> >    of the 3-digit Mobile Country Code (MCC) and 3-digit=20
> Mobile Network
> >    Code (MNC).  The IMSI Oversight Council (IOC) is the authority
> >    responsible for issuing unique Operator-Name values for=20
> operators of
> >    this type.
> >
> >    The REALM operator type can be used to indicate operator=20
> names based
> >    on any registered domain name.  The Internet Assigned Numbers
> >    Authority (IANA) or registered delegate is the authority=20
> responsible
> >    for issuing unique Operator-Name values for operators of=20
> this type.
> >
> >5.2  Operator-Name Attribute
> >
> >    This attribute contains an operator name which combined with the
> >    Operator-Type attribute serves to uniquely identifies=20
> the ownership
> >    of an access network.  The attribute value is a non-NULL=20
> terminated
> >    string whose Length MUST NOT exceed 253 bytes.  The=20
> attribute value
> >    uniquely identifies the operator name within the scope of the
> >    operator type.
> >
> >
> >
> >"
> >
> >15.  IANA Considerations
> >
> >    The authors request that the Attribute Types, and=20
> Attribute Values
> >    defined in this document be registered by the Internet Assigned
> >    Numbers Authority (IANA) from the RADIUS name spaces as=20
> described in
> >    the "IANA Considerations" section of RFC 2865 [1], in=20
> accordance with
> >    BCP 26 [9].
> >
> >15.1  Operator Type
> >
> >    This document also defines a new registry for the Operator-Type
> >    attribute.  Initially, IANA is requested to register the=20
> following
> >    values and associated registry owners for the operator namespace:
> >
> >         +-----+-----------+----------------------------+
> >         |  #  | Namespace | Registry Owner             |
> >         +-----+-----------+----------------------------+
> >         |  1  | GSM       | GSM Association: TADIG WG  |
> >         |  2  | CDMA      | IMSI Oversight Council     |
> >         |  3  | REALM     | IANA or delegate           |
> >         +-----------------+----------------------------+
> >
> >    Following the policies outlined in [9] new Operator-Types will be
> >    assigned after Expert Review by the Geopriv working group or its
> >    designated successor.
> >"
> >
> >
> >does this meet your expectations?
> >
> >
> >ciao
> >hannes
> >
> >--
> >to unsubscribe send a message to [email-masked] with
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
>=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: Thu, 03 Mar 2005 10:16:29 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'Joel M. Halpern'" <[email-masked]>, [email-masked], [email-masked]
Subject: AW: Radius-Geopriv: Whose location?
Date: Thu, 3 Mar 2005 11:14:31 +0100 

hi joel,=20

based on your comment i have added that aims to clarify this issue.=20
i am, however, not sure whether i phrased it good enough.

ciao
hannes

> -----Urspr=FCngliche Nachricht-----
> Von: Joel M. Halpern [mailto:[email-masked]]=20
> Gesendet: Mittwoch, 2. M=E4rz 2005 15:27
> An: [email-masked]; [email-masked]
> Betreff: Re: Radius-Geopriv: Whose location?
>=20
>=20
> The main point is that the document should indicate explicitly what=20
> location it provides.  It could provide both user and NAS location as =

> separate information.  It could provide just one of those two and be=20
> explicit about which one.
> But, as written, even with the proposed change, the document=20
> provides a=20
> single attribute and says that it may be either meaning,=20
> without explicit=20
> differentiation.
>=20
> Yours,
> Joel
>=20
> At 09:18 AM 3/2/2005, Bernard Aboba wrote:
> > > Requested change:
> > >      Decide whether this document is intended to provide=20
> subscriber=20
> > location
> > > (which is rarely  directly useful for AAA), or access=20
> device / network
> > > location information.
> >
> >It is ok with me if this document solely handles NAS=20
> location, so that we
> >can (quickly) create another document to handle user=20
> location.  However,
> >it is not accurate to say that user location is rarely=20
> useful for AAA.
> >There are now shipping products that support location-based access
> >control:
> >http://www.nwfusion.com/techinsider/2004/0315techinsiderrev.html
> >
> >Some scenarios in which this is used:
> >
> >a. High security installations, where access is only permitted =
within
> >restricted areas.
> >
> >b. Manufacturing, where it is important to track the=20
> location of people
> >and parts.
> >
> >c. Medical, where it is important to know the location of medical
> >personnel.
> >
> >d. E911, where the location of an emergency call is=20
> determined by the AP,
> >and provided to the RADIUS server.
> >
> >
> >--
> >to unsubscribe send a message to [email-masked] with
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 03 Mar 2005 10:16:01 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: AW: Radius-Geopriv: Whose location?
Date: Thu, 3 Mar 2005 11:13:45 +0100 

hi bernard, 

i suspect that this mail was in response to joel's comment.

the radius-geopriv document covers user locations. i also agree with you
that it is important that the aaa server makes authorization decisions based
on the users location information. 

ciao
hannes

> > Requested change:
> >      Decide whether this document is intended to provide 
> subscriber location
> > (which is rarely  directly useful for AAA), or access 
> device / network
> > location information.
> 
> It is ok with me if this document solely handles NAS 
> location, so that we
> can (quickly) create another document to handle user 
> location.
>  However,
> it is not accurate to say that user location is rarely useful for AAA.
> There are now shipping products that support location-based access
> control:
> http://www.nwfusion.com/techinsider/2004/0315techinsiderrev.html
> 
> Some scenarios in which this is used:
> 
> a. High security installations, where access is only permitted within
> restricted areas.
> 
> b. Manufacturing, where it is important to track the location 
> of people
> and parts.
> 
> c. Medical, where it is important to know the location of medical
> personnel.
> 
> d. E911, where the location of an emergency call is 
> determined by the AP,
> and provided to the RADIUS server.
> 

--
to unsubscribe send 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, 03 Mar 2005 09:26:26 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'Brian Rosen'" <[email-masked]>, [email-masked], [email-masked]
Subject: AW: [Geopriv] Radius-Geopriv: Precision
Date: Thu, 3 Mar 2005 10:24:06 +0100 

hi brian,=20

location-reference, sounds good.=20
this will certainly help to resolve some problems.=20

ciao
hannes

> -----Urspr=FCngliche Nachricht-----
> Von: Brian Rosen [mailto:[email-masked]]=20
> Gesendet: Mittwoch, 2. M=E4rz 2005 14:29
> An: Tschofenig Hannes; [email-masked]; [email-masked]
> Betreff: RE: [Geopriv] Radius-Geopriv: Precision
>=20
>=20
> I think you need a new term.
> Precision usually implies something related to accuracy, that=20
> is, what is
> the range of error of the reported position.  That idea is=20
> useful, although
> complicated.  Here, you aren't dealing with accuracy but with what,
> precisely, is being located.  For example, you may have the=20
> location of the
> NAS within .02 meters.  That's high accuracy, but may not be=20
> near the user.
> So, I would use a term like: location-reference, and change the text
> accordingly.
>=20
> Brian
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> [mailto:[email-masked]] On Behalf
> > Of Tschofenig Hannes
> > Sent: Wednesday, March 02, 2005 5:22 AM
> > To: [email-masked]; [email-masked]
> > Subject: [Geopriv] Radius-Geopriv: Precision
> >=20
> > hi all,
> >=20
> > the text paragraph about precision raised some discussions,=20
> see below:
> >=20
> > [lionel]
> >    Additionally, the Precision field provides further=20
> information about
> >    the location information provided via Radius.  For large =
networks
> >    information about the location of the user can be provided in
> >    different degrees of accuracy.  This field gives a hint.=20
>  Ideally the
> >    location of the user is returned to the home network but in some
> >    cases it might not be available.  It has to be noted=20
> that the user
> >    does not provide the location information itself.
> >=20
> > =3D=3D> (1) I don't understand the end of this paragraph! What=20
> kind of user
> > location are you referring  to here? Whatever the precision=20
> and the nature
> > of the location information, the location of the  user=20
> could always be
> > returned to the home network. Maybe you are talking about=20
> the location of
> > the  user's end point (which could be far away from the NAS)?
> >=20
> > =3D=3D> (2) only two formats of location information are defined at =
this
> > stage: civil and geospatial. What about some "location ID"=20
> that could be
> > sent to the AAA server to  retrieve location info? I mean that the
> > location
> > info attribute may convey either explicit =20
> ("self-explicit") location
> > information or any identifier if there is a mean for the receiver =
to
> > extract explicit information from this ID, such as the=20
> CellID in GSM.
> >=20
> > [bernard]
> > I was confused about this as well.
> >=20
> > [Hannes] regarding bullet (2): we do not provide some=20
> location id tokens
> > (such as cellids) with  our proposal.
> >=20
> >=20
> > [lionel]
> >=20
> >      Precision (8 bits):
> >        Describes which location this attribute refers to:
> >        (0) describes the location of the NAS
> >        (1) describes the location of the AAA server
> >        (2) describes the location of the end host (user)
> >        (3) describes the location of the network
> >=20
> > =3D=3D> What is the meaning of the fourth value? How could it=20
> be possible to
> > have less than the NAS or  the visited RADIUS location information?
> >=20
> > [hannes] the current format allows to specify location=20
> information very
> > precisely. if you have a  larger network you might want to=20
> indicate only
> > the
> > location of the network rather than the  location of each=20
> access point
> > (particularly if we configure the loc-info of the access points
> > manually).
> > indicating the precise information of the aaa server might=20
> not always what
> > you want. in  this case you might indicate, for example, a=20
> city destrict
> > as
> > a whole rather than indicating the  floor where the aaa=20
> server can be
> > found.
> >=20
> >=20
> > maybe the aspect of precision needs some more text. maybe=20
> the terminology
> > needs to be changed.
> >=20
> > ciao
> > hannes
> >=20
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >=20
>=20
>=20
>=20

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

Delivery-date: Thu, 03 Mar 2005 06:45:22 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Comments on draft-carroll-dynmobileip-cdma-04.txt
Date: Wed, 2 Mar 2005 22:44:40 -0800

Hi.  I was recently asked to review this document and during the
review I noticed a couple of problems.  In particular, the document
appears to unnecessarily violate RFC 2865.  For example: "The RADIUS
AAA Server MUST support a subscriber specific MIP Update State
Field.  When the MIP Update State Field set to UPDATE KEYS (1), the
RADIUS AAA Server MUST initiate the DMU procedure by including the
MIP_Key_Request attribute in an Access Reject message sent to the
PDSN...Note that the inclusion of a vendor-specific attribute in the
Access Reject message is not consistent with section 5.44 of [4].  A
RADIUS AAA server that supports DMU SHOULD NOT include a
vendor-specific attribute if the corresponding Access Request
message was not received from a DMU-compliant PDSN."  However, the
PPP connection is not closed, even though an Access-Reject was
received (thus modifying the semantics of the Access-Reject
message).  Looking at section 4.11, however, it appears that these
violations could easily be avoided through the use of
Access-Challenge instead of Access-Reject.  Is there some reason why
you feel that Access-Challenge is inappropriate in this situation? 

In addition, I couldn't find any reference to message integrity
protection.  Did I just miss it?

~gwz

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

Delivery-date: Wed, 02 Mar 2005 18:39:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Revised Agenda for IETF 62
Date: Wed, 2 Mar 2005 13:37:48 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I have heard the "final" word from the Secretariat on RADEXT scheduling.
Because Bert Wijnen is still convalescing, David Kessens is the only OPS
Area AD at IETF 62.  For this reason, the Secretariat rearranged the
agenda to minimize the number of OPS session conflicts.  Our meeting
slot will be Wednesday, March 9 from 15:30 to 17:30, however I've been
told by the Secretariat that our meeting room is not required for the
Plenary, so we can continue meeting until 18:00, if we choose, allowing
us to retain a 2.5 hour meeting slot.

My apologies to those WG members who had made their travel plans based
on the draft agenda, who are now inconvenienced.

WEDNESDAY, March 9, 2005

1530-1730 Afternoon Sessions II
Salon G    APP  geopriv   Geographic Location/Privacy WG
Salon D    INT  nemo      Network Mobility WG
Salon A    INT  pwe3      Pseudo Wire Emulation Edge to Edge WG
Salon E    IRTF dtnrg     Delay Tolerant Networking Research Group
Rochester  OPS  radext    Radius Extensions WG
Salon F    RTG  pim       Protocol Independent Multicast WG
Duluth     SEC  inch      Extended Incident Handling WG

1730-1930 Break
1930-2200 Plenary - IESG Plenary - Salon DEFG

--
to unsubscribe send 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, 02 Mar 2005 15:10:54 +0000
Date: Wed, 02 Mar 2005 17:10:36 +0200
From: Jari Arkko <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: Whose location?

I would be happiest if the document provided both the
user and the access device location, as available. In
addition, it would be great if the document addressed
privacy concerns* for user location. For instance, the
AAA server could provide an attribute in an Access-Challenge
indicating that sending location information is appropriate
and agreed by the user; the subsequent Access-Request would
then contain the user location AVP. This would enable a privacy
sensitive home network to disable the sending of the location
data across a proxy chain, even if the NAS supports this draft.

*) I do realize that we carry some policies in the AAA
exchanges about disclosing location. We also have
some identity privacy protection. Nevertheless, if
possible, I'd like to avoid sending the data at all
if the parties don't want that, rather than rely solely
on a policy. (But I confess that I'm don't know much about
Geopriv policies.) Also, I am not 100% convinced that we
can in the long term have full identity privacy, given
things like CUI.

--Jari

Joel M. Halpern wrote:

> The main point is that the document should indicate explicitly what 
> location it provides. It could provide both user and NAS location as 
> separate information. It could provide just one of those two and be 
> explicit about which one.
> But, as written, even with the proposed change, the document provides 
> a single attribute and says that it may be either meaning, without 
> explicit differentiation.
>
> Yours,
> Joel
>
> At 09:18 AM 3/2/2005, Bernard Aboba wrote:
>
>> > Requested change:
>> > Decide whether this document is intended to provide subscriber 
>> location
>> > (which is rarely directly useful for AAA), or access device / network
>> > location information.
>>
>> It is ok with me if this document solely handles NAS location, so 
>> that we
>> can (quickly) create another document to handle user location. However,
>> it is not accurate to say that user location is rarely useful for AAA.
>> There are now shipping products that support location-based access
>> control:
>> http://www.nwfusion.com/techinsider/2004/0315techinsiderrev.html
>>
>> Some scenarios in which this is used:
>>
>> a. High security installations, where access is only permitted within
>> restricted areas.
>>
>> b. Manufacturing, where it is important to track the location of people
>> and parts.
>>
>> c. Medical, where it is important to know the location of medical
>> personnel.
>>
>> d. E911, where the location of an emergency call is determined by the 
>> AP,
>> and provided to the RADIUS server.
>>
>>
>> -- 
>> to unsubscribe send a message to [email-masked] with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>
>
>
>
> -- 
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>
>

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

Delivery-date: Wed, 02 Mar 2005 14:28:00 +0000
Date: Wed, 02 Mar 2005 09:27:14 -0500
To: [email-masked], [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: Radius-Geopriv: Whose location?

The main point is that the document should indicate explicitly what 
location it provides.  It could provide both user and NAS location as 
separate information.  It could provide just one of those two and be 
explicit about which one.
But, as written, even with the proposed change, the document provides a 
single attribute and says that it may be either meaning, without explicit 
differentiation.

Yours,
Joel

At 09:18 AM 3/2/2005, Bernard Aboba wrote:
> > Requested change:
> >      Decide whether this document is intended to provide subscriber 
> location
> > (which is rarely  directly useful for AAA), or access device / network
> > location information.
>
>It is ok with me if this document solely handles NAS location, so that we
>can (quickly) create another document to handle user location.  However,
>it is not accurate to say that user location is rarely useful for AAA.
>There are now shipping products that support location-based access
>control:
>http://www.nwfusion.com/techinsider/2004/0315techinsiderrev.html
>
>Some scenarios in which this is used:
>
>a. High security installations, where access is only permitted within
>restricted areas.
>
>b. Manufacturing, where it is important to track the location of people
>and parts.
>
>c. Medical, where it is important to know the location of medical
>personnel.
>
>d. E911, where the location of an emergency call is determined by the AP,
>and provided to the RADIUS server.
>
>
>--
>to unsubscribe send 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: Wed, 02 Mar 2005 14:18:32 +0000
Date: Wed, 2 Mar 2005 06:18:21 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Tschofenig Hannes <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: Whose location?

> Requested change:
>      Decide whether this document is intended to provide subscriber location
> (which is rarely  directly useful for AAA), or access device / network
> location information.

It is ok with me if this document solely handles NAS location, so that we
can (quickly) create another document to handle user location.  However,
it is not accurate to say that user location is rarely useful for AAA.
There are now shipping products that support location-based access
control:
http://www.nwfusion.com/techinsider/2004/0315techinsiderrev.html

Some scenarios in which this is used:

a. High security installations, where access is only permitted within
restricted areas.

b. Manufacturing, where it is important to track the location of people
and parts.

c. Medical, where it is important to know the location of medical
personnel.

d. E911, where the location of an emergency call is determined by the AP,
and provided to the RADIUS server.

--
to unsubscribe send 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, 02 Mar 2005 14:02:57 +0000
Date: Wed, 2 Mar 2005 06:02:52 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Tschofenig Hannes <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: Who adds location information

> [Lionel]
>
> > ==> Is it so sure that NAS is always the source of location information?
> > Couldn't we have scenarios where the location information is added by
> > the RADIUS proxy in the visited network, because the NAS is not able
> > to retrieve the user's location for instance?
>
> [Bernard]
>
> This seems quite likely, in fact.
>
>
> [hannes] we might not have mentioned this explicitly but we made no
> restrictions with regard to the endity that may add location information
> (e.g., the nas or a proxy).

To be clear, we are talking about a AAA proxy adding the location of the
NAS.  I'm not sure why a NAS would even send user location information if
it had no way of estimating this better than knowing that the user had
authenticated to it.  Since a AAA proxy will not know the user location,
only the NAS location, I don't see how it could add 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: Wed, 02 Mar 2005 13:59:54 +0000
Date: Wed, 2 Mar 2005 05:59:42 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Tschofenig Hannes <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: Precision

> [hannes] the current format allows to specify location information very
> precisely. if you have a  larger network you might want to indicate only the
> location of the network rather than the  location of each access point
> (particularly if we configure the loc-info of the access points  manually).
> indicating the precise information of the aaa server might not always what
> you want. in  this case you might indicate, for example, a city destrict as
> a whole rather than indicating the  floor where the aaa server can be found.
> maybe the aspect of precision needs some more text. maybe the terminology
> needs to be changed.

I think the document needs to clearly differentiate NAS location from user
location.

Today shipping 802.11 APs can estimate the user location to a significant
degree of precision, and AAA server products are making
authentication/authorization decisions based on that information.

For example, in a secure 802.11 environment, it may be forbidden for
users to access the network outside of authorized areas.  Therefore the
RADIUS server may require the user's geospatial location in order to
determine if an Access-Request can be granted.

I'd note that in these situations it is even possible for the user's civil
location to be different from that of the NAS device.  For example, if
directional antennas are being used, the user could be a substantial
distance away from the AP.

If NAS location and user location are clearly delineated, then it will not
be necessary to take that into account within a precision 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, 02 Mar 2005 13:52:26 +0000
Date: Wed, 2 Mar 2005 05:52:17 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Tschofenig Hannes <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: When to send location info?

> [hannes] to me it seems reasonable not to include location information with
> every request. a  visited network which knows that it has to send location
> information to a particular home network  might do so. i also think that it
> would be good to have an error attribute to indicate that it was  not
> possible to authorize the user properly based on the missing location
> information.
>
> we have added the usage of the error-cause attribute. within the iana
> section we need to register  a new type:

I am confused by the model that is described here.  I could understand why
the NAS might not send the NAS location with every Access-Request.  But
user location is another matter.  If the NAS is set up to send user
location data, why would it not send it on each request?

My reading of RFC 2865 is that service provisioning attributes (including
VSAs) are forbidden in a RADIUS Access-Reject.  However, information on
why the request failed is ok (e.g. Reply-Message, EAP-Message/EAP-Failure,
etc.).  So I think that Error-Cause can be included.

However, Error-Cause will not solve the problem that is described.  If the
NAS is not sending User location on every Access-Request and the server
requires this, then every Access-Request that is sent without the user
location will be denied.

I'd suggest that language be included in the document to say that "by
default, a NAS that is set up to provide user location information to the
RADIUS server MUST provide this information in every Access-Request."

--
to unsubscribe send 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, 02 Mar 2005 13:48:53 +0000
Date: Wed, 02 Mar 2005 08:46:27 -0500
To: Tschofenig Hannes <[email-masked]>, [email-masked], [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: Radius-Geopriv: CDMA operator-name prefix / registry

This creates the requirement that IANA maintain a registry of operators.
Why not declare that any entity that owns a domain name by proper 
delegation (reference DNS documents) may use that string as a realm?
That avoids creating yet another registry.

It would also seem sensible, given such a strategy, to at least comment on 
why the other two values are necessary.  After all, any operator in the 
other two spaces also has a domain name.

If we are going to allow the other two name spaces, then can we have a 
reference to a public document containing the binding of identifier to 
entity, so that one may build interoperable implementations?

Thank you,
Joel M. Halpern

At 05:22 AM 3/2/2005, Tschofenig Hannes wrote:
>hi all,
>
>the operator-name lead to a long discussion on the mailing list. the
>discussion is far too long to copy-and-paste it into this mail. hence, we
>only show the proposed resolution of the issue:
>
>The previously used attribute is split into two attributes. Below you find
>the new text  including the relevant parts of the IANA section:
>
>"
>5.1  Operator-Type Attribute
>
>    This attribute contains an operator type which combined with the
>    Operator-Name attribute serves to uniquely identify the ownership of
>    an access network.  The attribute value is a four octet integer.
>    This document defines three values for this attribute: 1 (GSM), 2
>    (CDMA), and 3 (REALM).  Additional values require an IANA
>    registration and MUST be associated with an organization responsible
>    for assigning/managing the operator names.
>
>    The GSM operator type can be used to indicate operator names based on
>    GSMA TADIG codes.  The TADIG Working Group within the GSM Association
>    is the authority responsible for issuing unique Operator-Name values
>    for operators of this type.
>
>    The CDMA operator type can be used to indicate operator names based
>    on the Home Network Identifier (HNI).  The HNI is the concatenation
>    of the 3-digit Mobile Country Code (MCC) and 3-digit Mobile Network
>    Code (MNC).  The IMSI Oversight Council (IOC) is the authority
>    responsible for issuing unique Operator-Name values for operators of
>    this type.
>
>    The REALM operator type can be used to indicate operator names based
>    on any registered domain name.  The Internet Assigned Numbers
>    Authority (IANA) or registered delegate is the authority responsible
>    for issuing unique Operator-Name values for operators of this type.
>
>5.2  Operator-Name Attribute
>
>    This attribute contains an operator name which combined with the
>    Operator-Type attribute serves to uniquely identifies the ownership
>    of an access network.  The attribute value is a non-NULL terminated
>    string whose Length MUST NOT exceed 253 bytes.  The attribute value
>    uniquely identifies the operator name within the scope of the
>    operator type.
>
>
>
>"
>
>15.  IANA Considerations
>
>    The authors request that the Attribute Types, and Attribute Values
>    defined in this document be registered by the Internet Assigned
>    Numbers Authority (IANA) from the RADIUS name spaces as described in
>    the "IANA Considerations" section of RFC 2865 [1], in accordance with
>    BCP 26 [9].
>
>15.1  Operator Type
>
>    This document also defines a new registry for the Operator-Type
>    attribute.  Initially, IANA is requested to register the following
>    values and associated registry owners for the operator namespace:
>
>         +-----+-----------+----------------------------+
>         |  #  | Namespace | Registry Owner             |
>         +-----+-----------+----------------------------+
>         |  1  | GSM       | GSM Association: TADIG WG  |
>         |  2  | CDMA      | IMSI Oversight Council     |
>         |  3  | REALM     | IANA or delegate           |
>         +-----------------+----------------------------+
>
>    Following the policies outlined in [9] new Operator-Types will be
>    assigned after Expert Review by the Geopriv working group or its
>    designated successor.
>"
>
>
>does this meet your expectations?
>
>
>ciao
>hannes
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Wed, 02 Mar 2005 10:50:16 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Clarifications
Date: Wed, 2 Mar 2005 11:21:37 +0100 

hi all, 

lionel has asked for a few clarifications within the draft. 

[lionel] 

1.  Introduction

   Wireless LAN (WLAN) Access Networks (AN) are being deployed in public
   places such as airports, hotels, shopping malls, and coffee shops by
   a diverse set of incumbent operators such as cellular carriers (GSM
   and CDMA), Wireless Internet Service Providers (WISP), and fixed
   broadband operators.[skip]
   
   [skip] Although the proposed attributes in this draft are intended for
   wireless LAN deployments, they can also be used in other wireless and
   wired networks where location-aware services are required.

==> the need goes beyond location-based services for these networks. The
location information may  be needed in any roaming situation, to enable the
home network to authorize/deny access based on  the user's location (network
and/or geographical location), whatever the access network  technology.
Proposal: replace "where location-aware services are required" by "whenever
location information  is necessary"

[hannes] sounds ok to me. 

[lionel] 

4.1  Use Case 1 - Use of Location Information in AAA

   The RADIUS server authenticates and authroizes the session.  If the
   user's location policies are available to the RADIUS server, the
   RADIUS server may deliver those policies in an Access Accept.  This
   information may be needed if intermediaries or other elements want to
   act as Location Servers (see Section 4.2).  In the absence of
   receiving the policies intermediaries MUST NOT divulge the location
   information.

==> (1) the attributes that convey the policies in the Access-Accept are not
described. 
==> (2) As stated in the section 6 (Policy-Information attribute), policies
can also be put by the  access network and propagated with Access-Request or
Accounting-request.

[hannes] we have updated a new of places in the draft to clarify the
above-raised aspects. 

[lionel] 
==> Do the user's location policies received in the Access-Accept (in the
authorization phase)  also apply to Accounting messages?

[hannes] yes. 

[lionel] 
4.2  Scenario 2 - Use of Location Information for other Services

   Location Servers are entities that receive the user's location
   information and transmit it to other entities.  For the purpose of
   this scenario Location servers are the NAS, and RADIUS servers.  The
   RADIUS servers are in the home network, in the visited network, or in
   broker networks.

   Unless otherwise specified, excluding the proxy chain from the NAS to
   the Home RADIUS, the Location Server may not transmit the location
   information to other parties.

==> I think you mean: "Unless otherwise specified, the location servers MUST
NOT transmit the  location information to other parties outside the proxy
chain between the NAS and the Home RADIUS  server". 

[hannes] your proposal sounds good. i will like a small modification: 
"Unless otherwise specified, location information MUST NOT be transmitted to
other parties outside  the proxy chain between the NAS and the Home RADIUS
server". 

[lionel] 

   Upon authentication and authorization, the Home RADIUS may transmit
   the Rule set in an Access-Accept to the other Location Server
   allowing them to transmit location information.  Then and only then
   they are allowed to share the information.

==> Is it possible to discriminate parties allowed to distribute the
location information to third  parties e.g. only the local access network is
allowed and not intermediary networks (e.g.  brokers)?

[hannes] this is possible with the full set of policies. however, i think,
that it is not  particularly likely. 

[lionel] 

6.  Policy-Information Attribute

   In some environments it is possible for the user to attach
   information about its privacy preferences.  These preferences allow
   the visited network, intermediate RADIUS proxies and the home network
   to authorize the distribution of the user's location information.

==> How do these privacy preferences distributed by the Policy-Information
attribute in the  Access-Request interact with the policies being delivered
by the Home RADIUS server in the  Access-Accept?

[hannes] the policy information carried in the accesss request is only used
when the end host was  able to submit them to the access network. since this
is (today) quite unlikely we will only see  policies in the access-accept. 

ciao
hannes

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

Delivery-date: Wed, 02 Mar 2005 10:25:11 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Whose location?
Date: Wed, 2 Mar 2005 11:21:44 +0100 

hi all, 

this mail tries to resolve the issue raised by joel:

[Joel M. Halpern]

Rationale/Explanation of issue:  The location of a user is very different
from the location of an  access device.
Length description of problem:
     The document states that it provides the location of the access device
providing network  service.  The document then goes on to describe this as
"the users location".  The document even  describes this location as being
useful for services other than charging (cf section 4.2).   However, what is
needed for accounting is very different from the location for service
delivery.   The correlation between the two depends many factors outside of
the scope of this draft.  Mixing  the two is not helpful.
     The information format in fact seems designed to provide not the access
device location, but  the location of the subscriber.
     It is also likely that if access identification is desired, geographic
location will often  not be the correct mechanism.

Requested change:
     Decide whether this document is intended to provide subscriber location
(which is rarely  directly useful for AAA), or access device / network
location information.  In either case, remove  the inappropriate material.
     If access device identification is desired, please indicate why
operator defined tokens are  not sufficient.  And reference where such
tokens are when they are needed.

[hannes] to clarify this issue i have added some text to the terminology
section:

"
   Based on the availability of today's protocols we assume that the
   location information is provided by the access network where the end
   host is attached.  As part of the network attachment, which includes
   the execution of an authentication and authorization protocol
   exchange, authentication is accomplished.  The authenticated identity
   can refer to a user, a device or something else.  Although there
   might often be a user associated with the authentication process
   (either directly or indirectly; indirectly when a one-to-one
   relationship between a device and a user exists) there is no
   assurance that a particular real-world entity (such as a person)
   triggered this process.  Since location based authorization is
   executed based on the network access authentication of a particular
   "user" it might be reasonable to talk about user's privacy within
   this document even though scenarios exist where this might not be
   true (and device or network privacy might be the correct term).
   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 more fine-grain granular
   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) 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 but seems to
   be a good approximation.

   Please note that the authors use the term end host or user
   interchangable with respect to the used identities as part of the
   network access authentication.  To cover the worst case the term
   'user' is used whenever the privacy of the user could potentially be
   compromised.

"

do you think that this would work for you? 

ciao
hannes

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

Delivery-date: Wed, 02 Mar 2005 10:25:03 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: When to send location info?
Date: Wed, 2 Mar 2005 11:21:55 +0100 

hi all, 

please take a look at the following issue raised by lionel and bernard:

[Lionel:]

- It is not described whether this location information will be included in
every access-request  or only when some criteria are met e.g. based on a
given realm. It'd be intersting to spell out  these criteria. 
- If the use of location info in access-request could be optional, a COA
explicitly requesting  this info (when not received in the initial
access-request) could be used by the Home RADIUS  server.

How does the AAA server instruct the access network to send location
information attributes within  the new Access-Request? Is there any specific
attribute in the COA indicating that the location  information is requested?
Or do you assume that any Access-Request sent by the NAS will contain  the
location information attribute and so case 1 and 2 are the same?

[Bernard:]

RFC 3576 does not use attributes in the CoA-Request in order to request
attributes in a subsequent  Access-Request.  Nor does it make sense to
include location attributes in a CoA-Request.  The  session to which the CoA
applies is not selected using location attributes, nor is the request  that
the NAS change its location -- "Please move NAS17483 to Cleveland, Ohio."

[Avi]
I agree with Bernard, and we don't send location attributes to the NAS in
COA Request.

I think that the text is confusing:

   "The COA message may instruct the access
   network to generate an Authorize-Only Access-Request (Access-Request
   with Service-Type set to "Authorize-Only") in which case it is
   instructing the access network to send the location information
   attributes."

May be we should say:

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

Is there a way for the AAA server to indicate to the access network that the
request failed  because the location information is missing?

[Lionel:]

See RFC 3576 Error-Cause attribute, value 402 (Missing Attribute)

[Avi]

I don't think that we can use the Error-Cause attribute.  It is only
available in COA ACK/NAK  messages. So the AAA has no way to tell the NAS
that it is missing the location attribute. I don't  think that this
attribute can be placed in an Access-Reject message.
What do you think Bernard? 

[hannes] to me it seems reasonable not to include location information with
every request. a  visited network which knows that it has to send location
information to a particular home network  might do so. i also think that it
would be good to have an error attribute to indicate that it was  not
possible to authorize the user properly based on the missing location
information. 

we have added the usage of the error-cause attribute. within the iana
section we need to register  a new type:

"
15.2  Error-Cause Attribute

   The authors also request that IANA assign a new value for the
   Error-Cause attribute [5], of "Location-Info-Required" TBA.
"

minor text adjustments can be found within the recent draft version. 

ciao
hannes

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

Delivery-date: Wed, 02 Mar 2005 10:24:55 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv draft update
Date: Wed, 2 Mar 2005 11:21:39 +0100 

hi all, 

we have prepared a draft update based on the comments we received. 
please find the updated draft at:
http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-02.txt

a diff-version can be found here: 
http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-02-from-1.diff
.html

we have addressed comments raised on the radiusext and the geopriv mailing
list. i will send a separate mail on each of these issues. 

ciao
hannes

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

Delivery-date: Wed, 02 Mar 2005 10:24:49 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Who adds location information
Date: Wed, 2 Mar 2005 11:21:59 +0100 

hi all, 

bernard and lionel have sent this question to the mailing list: 

[Lionel]

> ==> Is it so sure that NAS is always the source of location information?
> Couldn't we have scenarios where the location information is added by 
> the RADIUS proxy in the visited network, because the NAS is not able 
> to retrieve the user's location for instance?

[Bernard]

This seems quite likely, in fact.

[hannes] we might not have mentioned this explicitly but we made no
restrictions with regard to the endity that may add location information
(e.g., the nas or a proxy). 

ciao
hannes

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

Delivery-date: Wed, 02 Mar 2005 10:24:39 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: CDMA operator-name prefix / registry
Date: Wed, 2 Mar 2005 11:22:15 +0100 

hi all, 

the operator-name lead to a long discussion on the mailing list. the
discussion is far too long to copy-and-paste it into this mail. hence, we
only show the proposed resolution of the issue:

The previously used attribute is split into two attributes. Below you find
the new text  including the relevant parts of the IANA section:

"
5.1  Operator-Type Attribute

   This attribute contains an operator type which combined with the
   Operator-Name attribute serves to uniquely identify the ownership of
   an access network.  The attribute value is a four octet integer.
   This document defines three values for this attribute: 1 (GSM), 2
   (CDMA), and 3 (REALM).  Additional values require an IANA
   registration and MUST be associated with an organization responsible
   for assigning/managing the operator names.

   The GSM operator type can be used to indicate operator names based on
   GSMA TADIG codes.  The TADIG Working Group within the GSM Association
   is the authority responsible for issuing unique Operator-Name values
   for operators of this type.

   The CDMA operator type can be used to indicate operator names based
   on the Home Network Identifier (HNI).  The HNI is the concatenation
   of the 3-digit Mobile Country Code (MCC) and 3-digit Mobile Network
   Code (MNC).  The IMSI Oversight Council (IOC) is the authority
   responsible for issuing unique Operator-Name values for operators of
   this type.

   The REALM operator type can be used to indicate operator names based
   on any registered domain name.  The Internet Assigned Numbers
   Authority (IANA) or registered delegate is the authority responsible
   for issuing unique Operator-Name values for operators of this type.

5.2  Operator-Name Attribute

   This attribute contains an operator name which combined with the
   Operator-Type attribute serves to uniquely identifies the ownership
   of an access network.  The attribute value is a non-NULL terminated
   string whose Length MUST NOT exceed 253 bytes.  The attribute value
   uniquely identifies the operator name within the scope of the
   operator type.

"

15.  IANA Considerations

   The authors request that the Attribute Types, and Attribute Values
   defined in this document be registered by the Internet Assigned
   Numbers Authority (IANA) from the RADIUS name spaces as described in
   the "IANA Considerations" section of RFC 2865 [1], in accordance with
   BCP 26 [9].

15.1  Operator Type

   This document also defines a new registry for the Operator-Type
   attribute.  Initially, IANA is requested to register the following
   values and associated registry owners for the operator namespace:

        +-----+-----------+----------------------------+
        |  #  | Namespace | Registry Owner             |
        +-----+-----------+----------------------------+
        |  1  | GSM       | GSM Association: TADIG WG  |
        |  2  | CDMA      | IMSI Oversight Council     |
        |  3  | REALM     | IANA or delegate           |
        +-----------------+----------------------------+

   Following the policies outlined in [9] new Operator-Types will be
   assigned after Expert Review by the Geopriv working group or its
   designated successor.
"

does this meet your expectations? 

ciao
hannes

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

Delivery-date: Wed, 02 Mar 2005 10:24:33 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Precision
Date: Wed, 2 Mar 2005 11:22:05 +0100 

hi all, 

the text paragraph about precision raised some discussions, see below:

[lionel]
   Additionally, the Precision field provides further information about
   the location information provided via Radius.  For large networks
   information about the location of the user can be provided in
   different degrees of accuracy.  This field gives a hint.  Ideally the
   location of the user is returned to the home network but in some
   cases it might not be available.  It has to be noted that the user
   does not provide the location information itself.

==> (1) I don't understand the end of this paragraph! What kind of user
location are you referring  to here? Whatever the precision and the nature
of the location information, the location of the  user could always be
returned to the home network. Maybe you are talking about the location of
the  user's end point (which could be far away from the NAS)?

==> (2) only two formats of location information are defined at this
stage: civil and geospatial. What about some "location ID" that could be
sent to the AAA server to  retrieve location info? I mean that the location
info attribute may convey either explicit  ("self-explicit") location
information or any identifier if there is a mean for the receiver to
extract explicit information from this ID, such as the CellID in GSM.

[bernard]
I was confused about this as well.

[Hannes] regarding bullet (2): we do not provide some location id tokens
(such as cellids) with  our proposal. 

[lionel] 

     Precision (8 bits):
       Describes which location this attribute refers to:
       (0) describes the location of the NAS
       (1) describes the location of the AAA server
       (2) describes the location of the end host (user)
       (3) describes the location of the network

==> What is the meaning of the fourth value? How could it be possible to
have less than the NAS or  the visited RADIUS location information?

[hannes] the current format allows to specify location information very
precisely. if you have a  larger network you might want to indicate only the
location of the network rather than the  location of each access point
(particularly if we configure the loc-info of the access points  manually).
indicating the precise information of the aaa server might not always what
you want. in  this case you might indicate, for example, a city destrict as
a whole rather than indicating the  floor where the aaa server can be found.

maybe the aspect of precision needs some more text. maybe the terminology
needs to be changed. 

ciao
hannes

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

Delivery-date: Tue, 01 Mar 2005 22:21:47 +0000
Content-class: urn:content-classes:message
Subject: Revised Agenda for IETF 62
Date: Tue, 1 Mar 2005 17:20:32 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Well, folks...  The Secretariat has once again moved our slot in a
last-minute round of schedule juggling.  This is still marked as a
"draft" agenda.

We are now scheduled on Wednesday afternoon, and we have a 2 hour slot,
rather that a 2.5 hour slot.  I don't know that there's any productive
action that we can take at this juncture.  I will request that we be
restored to a 2.5 hour slot.  We'll see...  Otherwise we will
undoubtedly need to adjust our WG Agenda to fit in the reduced meeting
time allotted.  (BTW, no one asked the Chairs if this was OK...)

Stat tuned...

WEDNESDAY, March 9, 2005

1530-1730 Afternoon Sessions II
Salon G   APP  geopriv    Geographic Location/Privacy WG
Salon D   INT  nemo       Network Mobility WG
Salon A   INT  pwe3       Pseudo Wire Emulation Edge to Edge WG
Salon E   IRTF dtnrg      Delay Tolerant Networking Research Group
Rochester OPS  radext     Radius Extensions WG
Salon F   RTG  pim        Protocol Independent Multicast WG
Carver    SEC  inch       Extended Incident Handling WG

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

Delivery-date: Tue, 01 Mar 2005 16:33:00 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: RE: RADEXT WG Agenda for IETF 62: Take three
Date: Tue, 1 Mar 2005 11:32:26 -0500 

Hi Bernard and all,

We also have a bandwidth draft.  Its now called:
http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-lior-radius-band
width-capability-00

Related to other WG.

We also have RADIUS PANA:
http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-lior-pana-radius
-00

And we also have RADIUS MIPv4
http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-nakhjiri-radius-
mip4-00

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, February 28, 2005 10:42 AM
> To: [email-masked]
> Subject: RADEXT WG Agenda for IETF 62: Take three
> 
> 
> IETF 62 RADEXT WG Meeting
> Thursday, March 10, 2005
> 0900 - 1130
> 
> Chairs:
> Bernard Aboba <[email-masked]>
> David Nelson <[email-masked]>
> 
> Preliminaries (5 minutes)
>  Blue Sheets
>  Minutes
>  Document Status
>  Issue Status (see http://www.drizzle.com/~aboba/RADEXT/ )
> 
> Completed IETF Last Call
> 
> RFC 2486bis, Jari Arkko (5 minutes) 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486b
> is-05.txt
> 
> In WG Last Call (to end March 14, 2005)
> 
> RADIUS Digest Authentication, Wolfgang Beck (5 minutes) 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-a
> uth-01.txt
> 
> WG Work Items
> 
> Chargeable User Identity, Farid Adrangi (10 minutes) 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeab
> le-user-id-03.txt
> 
> MIBs
> 
> RADIUS MIB Revision, David Nelson (5 minutes) 
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt
> 
> RFC 3576 MIBs, TBD (5 minutes) 
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
auth-client-mib-03.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mi
b-03.txt

Pre-work Item Review

RADIUS Extensions for IEEE 802, Mauricio Sanchez (10 minutes)
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt

RADIUS Extensions for Management Authorization, David Nelson (10 Minutes)
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authoriza
tion-01.txt

Prepaid Extensions for RADIUS, Avi Lior (10 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-07.
txt

Issues and Fixes, David Nelson (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/

RADIUS Work in Other WGs

Using RADIUS for PE-based VPN Discovery, Greg Weber (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-radius-pe-discovery-01.
txt

RADIUS Location, Hannes Tschofenig (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt

Miscellaneous

Service Decisions, Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-arkko-radext-multi-service-decisio
ns-01.txt

Capabilities Discovery (15 minutes)

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

--
to unsubscribe send 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, 01 Mar 2005 10:53:56 +0000
Date: Tue, 1 Mar 2005 16:23:36 +0530
From: Anj <[email-masked]>
Reply-To: Anj <[email-masked]>
To: [email-masked]
Subject: RFC 2809

Hi,

I have following comments related to RFC 2809, L2TP Compulsory
Tunneling via RADIUS.

1. In the sections, 4.1.1, 4.1.2.2 and 4.1.2.3, following text with
slight variations is mentioned.

"...If LCP renegotiation is to be permitted, the NAS
 SHOULD NOT send an LCP CONFACK completing LCP negotiation. Rather
 than sending an LCP CONFACK, the NAS will instead send an LCP
 Configure-Request packet, described in [6].  ..."

As you knew, authentication phase would be started only after the
completion of LCP phase but above cases require authentication phase
to be started. So, I think above statement is not valid.

2. In the diagrams mentioned in sections, 4.1.2.2, 4.1.2.3 and 4.2,
Start-Control-Connection-Connected message should be sent after
receiving Start-Control-Connection-Reply message.

3. Section 5 mentions about Call-Clear-Request message but there is no
such message in L2TP protocol.

-Anj

PS: I didn't check the archive. So, pardon me if I am mentioning the
comments given already.

--
to unsubscribe send 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, 01 Mar 2005 09:40:53 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Agenda for IETF 62: Take three
Date: Tue, 1 Mar 2005 01:40:09 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

For capability discovery, we have submitted the draft (as I mentioned it
before):
http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-00
.txt
Would you like to add this to the agenda?
Thanks,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, February 28, 2005 7:42 AM
> To: [email-masked]
> Subject: RADEXT WG Agenda for IETF 62: Take three
>=20
>=20
> IETF 62 RADEXT WG Meeting
> Thursday, March 10, 2005
> 0900 - 1130
>=20
> Chairs:
> Bernard Aboba <[email-masked]>
> David Nelson <[email-masked]>
>=20
> Preliminaries (5 minutes)
>  Blue Sheets
>  Minutes
>  Document Status
>  Issue Status (see http://www.drizzle.com/~aboba/RADEXT/ )
>=20
> Completed IETF Last Call
>=20
> RFC 2486bis, Jari Arkko (5 minutes)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486b
> is-05.txt
>=20
> In WG Last Call (to end March 14, 2005)
>=20
> RADIUS Digest Authentication, Wolfgang Beck (5 minutes)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-a
> uth-01.txt
>=20
> WG Work Items
>=20
> Chargeable User Identity, Farid Adrangi (10 minutes)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeab
> le-user-id-03.txt
>=20
> MIBs
>=20
> RADIUS MIB Revision, David Nelson (5 minutes)
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt
>=20
> RFC 3576 MIBs, TBD (5 minutes)
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
auth-client-mib-03.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-serve
r-mib-03.txt

Pre-work Item Review

RADIUS Extensions for IEEE 802, Mauricio Sanchez (10 minutes)
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt

RADIUS Extensions for Management Authorization, David Nelson (10
Minutes)
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho
rization-01.txt

Prepaid Extensions for RADIUS, Avi Lior (10 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-07.txt

Issues and Fixes, David Nelson (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/

RADIUS Work in Other WGs

Using RADIUS for PE-based VPN Discovery, Greg Weber (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-radius-pe-discovery
-01.txt

RADIUS Location, Hannes Tschofenig (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt

Miscellaneous

Service Decisions, Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-arkko-radext-multi-service-dec
isions-01.txt

Capabilities Discovery (15 minutes)

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

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