Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Blumenthal, Uri'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 27 Apr 2005 14:46:38 -0700

Blumenthal, Uri <mailto:[email-masked]> supposedly
scribbled:

>>> "EAP server" is what "eap peer" and "aaa" share.
>> 
>> An EAP server can exist on the authenticator when there is  no
AAA
>> server present.  It is a distinct entity from the EAP peer.  It
is
>> not "shared" between the EAP peer and AAA server.
> 
> In theory EAP server is a distinct entity and can be anywhere, in
> practice it's a part of AAA most of the time. Why are we arguing
> about this?  

I thought we were talking about architecture; and further,
discussing components which might or might not be utilized in that
architecture.  Maybe it's just me, but I think that it's a good idea
to understand how those components actually work (as opposed to how
we might wish or imagine they work, or the direction in which
marketeers might be pushing them).  If a building architect thought
that a brick was part of a girder, he would design a pretty strange
building and  misconceptions in networking can easily lead to
similar results.  For example, there was a recent thread on a
different list in which someone was worried about security problems
if a 4th party (!) was introduced into an EAP conversation.  There
are not 3 or 4 or 17 parties in an EAP exchange, there are exactly
2; there are also (logically) 2 parties in a RADIUS exchange, and
those sets are disjoint.

Hope this helps,

~gwz

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

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

Delivery-date: Wed, 27 Apr 2005 21:26:31 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: "'Blumenthal, Uri'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Wed, 27 Apr 2005 14:25:53 -0700

Bernard Aboba <mailto:[email-masked]> supposedly scribbled:

>> "EAP server" is what "eap peer" and "aaa" share.
> 
> An EAP server can exist on the authenticator when there is  no AAA
> server present.  

I'd actually go a bit further and claim that the distinction between
the authenticator and the EAP "server" is one of convenience & that
they are logically the same entity.

> It is a distinct entity from the EAP peer.  It is
> not "shared" between the EAP peer and AAA server.  
> 
>> Oh and we _are_ talking EAPv2, right?
> 
> The only version of EAP that I'm familiar with is defined in RFC
3748.
> 
> Maybe this entire discussion has been about some *other* version
of
> EAP? 

Hope this helps,

~gwz

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

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

Delivery-date: Wed, 27 Apr 2005 18:32:25 +0000
Content-class: urn:content-classes:message
Subject: RE: L2 NAS-Filter-Rule syntax choices
Date: Wed, 27 Apr 2005 11:31:32 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

There are two strategies for this:

1. We anticipate working with whatever general capabilities
advertisement mechanism is defined for Radius.  I think this particular
application points out the need for some level of granularity around
what is advertised.

2. We are also specifying that for NAS devices that understand the
attribute, but are not capable of supporting it are, by default, to
treat the Access-Accept as an Access-Reject.  We are also recommending
that this default action and behavior be something NAS devices can
configure differently if so desired.

It is fairly common these days to have some simple levels of L2
filtering as well as L3 filtering in switches and access points.

Paul=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Wednesday, April 27, 2005 7:47 AM
> To: Congdon, Paul T (ProCurve)
> Cc: [email-masked]
> Subject: Re: L2 NAS-Filter-Rule syntax choices
>=20
> > The belief is the current proposal covers all bases and is still=20
> > usable, but perhaps specifies more than many NAS devices could=20
> > actually implement or are interested in supporting.
>=20
> Question: how do you know whether a particular NAS device=20
> supports all of the syntax covered in the NAS-Filter-Rule? =20
> For example, a layer 2 switch might only support layer 2=20
> filters, or a NAS might only support layer 3 filters.  A=20
> unified syntax makes sense, but allowing layer 2 and layer 3=20
> filters to be included in one attribute implies that devices=20
> have to implement both layer 2 and layer 3 filters.  If a=20
> device only supports part of the syntax, there is no easy way=20
> for it to advertise that.
>=20
> Or is support for both layer 2 and layer 3 filtering common=20
> enough at this point that we don't need to worry about this?
>=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, 27 Apr 2005 14:46:48 +0000
Date: Wed, 27 Apr 2005 07:46:39 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
cc: [email-masked]
Subject: Re: L2 NAS-Filter-Rule syntax choices

> The belief is the current proposal covers all bases and is still usable,
> but perhaps specifies more than many NAS devices could actually
> implement or are interested in supporting.

Question: how do you know whether a particular NAS device supports all of
the syntax covered in the NAS-Filter-Rule?  For example, a layer 2 switch
might only support layer 2 filters, or a NAS might only support layer 3
filters.  A unified syntax makes sense, but allowing layer 2 and layer 3
filters to be included in one attribute implies that devices have to
implement both layer 2 and layer 3 filters.  If a device only supports
part of the syntax, there is no easy way for it to advertise that.

Or is support for both layer 2 and layer 3 filtering common enough at this
point that we don't need to worry about this?

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

Delivery-date: Wed, 27 Apr 2005 14:41:54 +0000
Date: Wed, 27 Apr 2005 07:41:37 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: RE: [Issue 297] Review of Identity Selection -12

> Since draft-adrangi-eap-network-discovery-12 does not even have
> a reference to RFC 2607, I don't think any "Updates" header
> is needed...

RFC 2607 specifies RADIUS proxy behavior in roaming.  This document
specifies the behavior of RADIUS proxies that handle EAP messages.

Moreoever, the document implicitly assumes a model by which requests
are routed (source routing).

These additions affect the behavior of RADIUS proxies. Between this
document and RFC 2486bis,  many proxies will need to be modified.

I'm suggesting that we explicitly acknowledge the changes by including an
Updates: header.

Another alternative would be to remove the material relating to proxy
behavior, and put it in a separate document within RADEXT WG.  That
document could expand on the required changes in more depth (such as the
expected handling of source routed NAIs).

--
to unsubscribe send a message 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, 27 Apr 2005 14:25:18 +0000
Content-class: urn:content-classes:message
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Wed, 27 Apr 2005 10:23:16 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Glen Zorn writes...

> I may not trust the government of the United States, but it has
> authorized me (through the issuance of a passport) to leave the
> country and return.

I'm not sure this is an apt example of your point.  I rather suspect
that your distrust of the Federal government extends to areas other than
whether or not the agency that issued you a passport has the authority
to do so. :-)

In terms of the trust needed for enforcement of authorization, in your
example it is the trust relationship that various customs agents have
with the US government (among others) that allows them to validate your
passport and grant you passage.

In general, I think that concept of authorization without any form of
trust relationship is pretty useless.

--
to unsubscribe send a message 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, 27 Apr 2005 05:44:12 +0000
Date: Tue, 26 Apr 2005 22:43:05 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "'Blumenthal, Uri'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

> "EAP server" is what "eap peer" and "aaa" share.

An EAP server can exist on the authenticator when there is  no AAA
server present.  It is a distinct entity from the EAP peer.  It is not
"shared" between the EAP peer and AAA server.

> Oh and we _are_ talking EAPv2, right?

The only version of EAP that I'm familiar with is defined in RFC 3748.

Maybe this entire discussion has been about some *other* version of EAP?

--
to unsubscribe send a message 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, 27 Apr 2005 03:43:50 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Blumenthal, Uri'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 20:42:54 -0700

Blumenthal, Uri <mailto:[email-masked]> supposedly
scribbled:

>>> It was my understanding that while EAP is between the client
>>> (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP
>>> method* that runs on top of EAP is between the client and RADIUS
>>> server.
>> 
>> No. Can we just _get it_ once and for all?  AAA & EAP are
_different_
>> and _separate_ things: there is no part of EAP that is "between"
the
>> EAP peer and any AAA entity.
> 
> What about EAP methods that run between the EAP client and EAP
server?
> Are you saying that EAP _method_ does not terminate in an EAP
server,
> or that EAP server is not usually [within and part of] a AAA
server?

No, but this is an implementation detail: it is by no means
necessary to have _any_ AAA infrastructure to deploy EAP.  AAA makes
it more convenient, scale better, etc., but it's not necessary, nor
is EAP "part of" AAA.

> "EAP server" is what "eap peer" and "aaa" share.  
> Oh and we _are_ talking EAPv2, right?

I don't know what that is.

> 
> 
>>> This tunnel created by EAP method can be considered as "trust
>>> between the client and AAA",
>> 
>> See above.
> 
> See above. I consider EAP server running inside AAA server. If
others
> (besides Glen and Bernard) on this list disagree with this
perception
> - I invite them to speak up please.  
> 
> 
>>> and RADIUS between NAS and AAA (however it is
>>> accomplished) is "trust between NAS and AAA".
>>> 
>>> And yes, many find convenient to connect authorization decision
to
>>> some extra information about the supplicant - such as its
posture
>>> evaluation (Cisco NAC, Microsoft NAP, etc). Such information
would
>>> naturally be carried in TLVs as part of EAP inner method
exchange.
>> 
>> Or more rationally (gasp!) in a subsequent _authorization_
protocol
>> exchange.
> 
> Kindly explain how "authorization" doesn't include trust of the
> authorizing entity. 

I may not trust the government of the United States, but it has
authorized me (through the issuance of a passport) to leave the
country and return.  

> Also, it may be news for you - but [at least
> some] people want authentication combined with authorization: i.e.
if
> I get a set of keys, it means that (a) the AAA authenticated me
OK,
> _and_ (b) that the server implicitly authorized me to communicate
> with the given NAS.  

It's not news to me at all -- it's the same old RADIUS story.  
   
> 
> That authorization is dependent on host posture evaluation. I
thought
> it was Cisco that proposed it in their NAC architecture? Perhaps
you
> can/should shed some light on this?  

I thought this was a standards discussion; if you want to talk about
NAC (or any other proprietary Cisco stuff), I suggest that you talk
to your account manager -- I'm sure that he or she would love to
extol its wonders.  

> 
> 
>>> Yes it seems to go way beyond the original purpose of EAP, but
then
>>> it does seem to address the today's need.
>> 
>> If one has a sore toe, shooting oneself in the foot may seem to
>> satisfy "today's need"; in the long run, however, it will
probably
>> turn out to be counterproductive.
> 
> I'm simply describing what I perceive as today's reality. You may
> intensely dislike it - it's your free choice. Looks like the
market
> is moving the above-described way.  

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, 26 Apr 2005 23:43:13 +0000
Content-class: urn:content-classes:message
Subject: L2 NAS-Filter-Rule syntax choices
Date: Tue, 26 Apr 2005 16:42:48 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>

We are working on -04 of the 802 extensions draft and have added in a
syntax for L2 filters for the NAS-Filter-Rule attribute.  I'd like some
feedback from the group on if we are going in the right direction before
posting -04 for review.

The current proposal is trying to balance usability with extensibility.
It provides two ways to express a L2 frame; one for Ethernet
encapsulation and another for everything else. We expect that the vast
majority of the time (maybe 99%) a L2 frame will be encapsulated with
Ethernet type encapsulation.  The Ethernet encapsulation syntax in the
attribute specifies the Ethertype and addresses as seen in the following
example:

	deny in l2:ether2:0x806 from 00-10-A4-23-19-C0 to any

This would block all ARP packets from a particular host.  The key words
are l2:ether2[:value].

A second, more extensible, yet harder to use, syntax is also defined to
cover all other cases.  It uses the OID format defined in RFC2895 for
protocol definitions.  For example:

	deny in l2:0.0.0.2.0.0.0.240

This would block all NetBIOS over LLC traffic.  We should be able to
define all L2 protocols using this format.

The belief is the current proposal covers all bases and is still usable,
but perhaps specifies more than many NAS devices could actually
implement or are interested in supporting.

Alternatives to the current scheme include:

1. defining additional key words like 'ether2' for other encapsulations
like SNAP, LLC, IPX-Raw, etc..
2. Drop the rmon_str syntax and just support ether2
3. only use the rmon_str syntax
4. others?

Let me know what you think

Paul

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

Delivery-date: Tue, 26 Apr 2005 22:33:54 +0000
Date: Tue, 26 Apr 2005 15:33:23 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: David B Harrington <[email-masked]>
cc: "'Blumenthal, Uri'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

> Why are we spending so much time discussing EAP, if the AD has told
> the WG that EAP should not be used, and that the IESG is unlikely to
> approve a solution using EAP?
>
> dbh

Perhaps because the ISMS WG charter talks about RADIUS support?

Just a thought :)

--
to unsubscribe send a message 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, 26 Apr 2005 22:26:52 +0000
Date: Tue, 26 Apr 2005 15:26:39 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "'Avi Lior'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Issue 83: CUI and re-authentication

> > This is just in case the NAS changed the value of CUI. It should
> > never do this.  But to be complete that clause says what will
> happen.
>
> Maybe this stuff could actually be explained in the draft?

That is the optimal way to get the point across, I think.

--
to unsubscribe send a message 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, 26 Apr 2005 22:26:25 +0000
Date: Tue, 26 Apr 2005 15:25:46 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "'Blumenthal, Uri'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

> If one has a sore toe, shooting oneself in the foot may seem to
> satisfy "today's need"; in the long run, however, it will probably
> turn out to be counterproductive.

"Probably".  I sense a window large enough for an elephant to walk through
:)

--
to unsubscribe send a message 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, 26 Apr 2005 19:08:02 +0000
Content-class: urn:content-classes:message
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 15:07:14 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, "Blumenthal, Uri" <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Dave Harrington writes...

> Why are we spending so much time discussing EAP, if the AD has told
> the WG that EAP should not be used, and that the IESG is unlikely to
> approve a solution using EAP?

I don't know.  But I'll offer the somewhat pedantic clarification that
the AD told ISMS that EAP was out of scope because of the EAP
applicability statement.  There exists the finite possibility that the
EAP WG will decide to modify its applicability 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, 26 Apr 2005 19:05:25 +0000
Content-class: urn:content-classes:message
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 15:03:33 -0400
From: "Nelson, David" <[email-masked]>
To: "Blumenthal, Uri" <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Uri Blumenthal writes...

> I consider EAP server running inside AAA server. If others
> (besides Glen and Bernard) on this list disagree with this perception
-
> I invite them to speak up please.

I agree that is most often the case, in practice.  The EAP server is
packaged as part of the RADIUS or Diameter server software distribution.

>From a protocol definition perspective, however, the EAP server and AAA
server are distinct entities.  Any interaction (API) between these
entities is outside the scope of the EAP, RADIUS or Diameter RFCs. Any
security analysis of those protocols cannot take into account the AAA
server to EAP server API, as it is implementation specific.

--
to unsubscribe send a message 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, 26 Apr 2005 16:13:42 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Issue 83: CUI and re-authentication
Date: Tue, 26 Apr 2005 09:04:08 -0700

Avi Lior <> supposedly scribbled:

> Hi John,
> 
>> 1) the CUI may change during reauthentication, but the home
server
>>    doesn't need to check if it has changed.
> 
> The home network is the only entity that can change the value of
the
> CUI. 
> Note that the value of the CUI is opaque to the NAS.
> 
> During reauthentication it may want to change the value of CUI.
This
> could happen because local policy states that change CUI on the
1st
> of every month. So if the session spans midnight it may change the
> CUI.   
> 
> 
>> 2) if the home server does check and notice that it has changed,
>>    then it should send an Access-Reject.
> 
> This is just in case the NAS changed the value of CUI. It should
> never do this.  But to be complete that clause says what will
happen. 

Maybe this stuff could actually be explained in the draft?  

> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, April 26, 2005 2:54 AM
>> To: [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: Issue 83: CUI and re-authentication
>> 
>> 
>> Farid,
>> 
>> I edited your text somewhat:
>> 
>>  When reauthenticating, a NAS that supports CUI MUST include the
CUI
>> attribute with the value of CUI received in a previous
Access-Accept.
>> 
>>  Upon receiving a non-nul CUI in an Access-Request the home
RADIUS
>> server  MAY verify that the value of CUI matches the the CUI from
the
>> previous  Access-Accept If the verification fails, then the
RADIUS
>> server SHOULD  respond with an Access-Reject message.
>> 
>>  During reauthentication, upon receiving an Access-Accept, the
value
>> of  the CUI maybe different from the previously received CUI for
that
>> session. The NAS MUST use this value on all subsequent accounting
>> messages for that session. 
>> 
>> But I am confused by this; you are stating that
>> 
>> 1) the CUI may change during reauthentication, but the home
server
>>    doesn't need to check if it has changed.
>> 2) if the home server does check and notice that it has changed,
>>    then it should send an Access-Reject.
>> 
>> What is the purpose of this, if checking is optional?  A MAY
followed
>> by a SHOULD is not really create deterministic behavior. Can you
>> explain in a bit more detail what kind of behavior you are trying
to
>> get? 
>> 
>> John
>> 
>> 
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]]On Behalf Of ext Adrangi,
>>> Farid Sent: 26 April, 2005 07:12 To: Bernard Aboba
>>> Cc: [email-masked]; Nelson, David
>>> Subject: RE: Issue 83: CUI and re-authentication
>>> 
>>> 
>>> No. The "Validation" means that the RADIUS server checks to see
if
>>> the CUI value is the same as the one that was sent in the
previous
>>> Access-Accept.   However, the RADIUS server does not require
>>> to do this
>>> validation.
>>> Thanks,
>>> Farid
>>> 
>>>> -----Original Message-----
>>>> From: Bernard Aboba [mailto:[email-masked]]
>>>> Sent: Monday, April 25, 2005 6:50 PM
>>>> To: Adrangi, Farid
>>>> Cc: [email-masked]; Nelson, David
>>>> Subject: RE: Issue 83: CUI and re-authentication
>>>> 
>>>> 
>>>> Presumably, by "validated" you mean that the CUI presented is
>>>> associated with the subsequently authenticated identity.
>>>> 
>>>> On Mon, 25 Apr 2005, Adrangi, Farid wrote:
>>>> 
>>>>> Good point Bernard!  Avi and I just discussed this, and our
>>>>> current thinking is to add something like below to the draft:
>>>>> 
>>>>> "
>>>>> When re-authenticating, a NAS that supports CUI MUST include
the
>>>>> CUI attribute with the value of CUI received in a previous
>>>>> Access-Accept. 
>>>>> 
>>>>> Upon receiving a non-nul CUI in an Access-Request the home
RADIUS
>>>>> server MAY validate the value of CUI and if the validation
fails,
>>>>> then the RADIUS server SHOULD respond with an Access-Reject
>>>>> message. 
>>>>> 
>>>>> During reauthentication, upon receiving an Access-Accept, the
>>>>> value of the CUI maybe different from the previously received
CUI
>>>>> for that session. The NAS MUST use this value on all
subsequent
>>>>> accounting messages for that session. " 
>>>>> 
>>>>> Does this work for you, all?
>>>>> 
>>>>> Thanks,
>>>>> Farid
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: [email-masked]
>>>>>> [mailto:[email-masked]] On Behalf Of Bernard
Aboba
>>>>>> Sent: Friday, April 22, 2005 7:33 PM
>>>>>> To: [email-masked]
>>>>>> Subject: Issue 83: CUI and re-authentication
>>>>>> 
>>>>>> 
>>>>>> Issue 83: CUI and re-authentication Submitter name: Bernard
>>>>>> Aboba Submitter email address: [email-masked] Date first
>>>>>> submitted: April 22, 2005 Reference:
>>>>>> Document: CUI-04
>>>>>> Comment type: T
>>>>>> Priority: S
>>>>>> Section: Various
>>>>>> Rationale/Explanation of issue:
>>>>>> 
>>>>>> The document does not state how CUI is used with an
>>>>>> Access-Request that occurs due to re-authentication.  For
>>>>>> example, in the original authentication, the CUI attribute
was
>>>>>> provided within the Access-Accept, and subsequently within
>>>>>> Accounting-Request packets
>>>> (interim).  Let us
>>>>>> assume that a Session-Timeout attribute was sent with
>>>>>> Termination-Action=RADIUS. 
>>>>>> 
>>>>>> What happens at the expiration of the Session-Timeout value?
>>>>>> Does the NAS send an Access-Request containing a CUI
attribute
>>>>>> to the
>>>> RADIUS server
>>>>>> with the currently used CUI, or does it send an empty CUI
>>>>>> attribute?  It seems more appropriate for it to send the
>>>>>> currently used CUI, since that does not require the RADIUS
>>>>>> server to keep state.  I presume that the User-Name and EAP
>>>>>> re-authentication elements are handled the same way (e.g.
>>>>>> User-Name includes "@realm" privacy NAI).
>>>>>> 
>>>>>> --
>>>>>> to unsubscribe send 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/>

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, 26 Apr 2005 15:27:57 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Issue 83: CUI and re-authentication
Date: Tue, 26 Apr 2005 11:26:45 -0400

Hi John,

> 1) the CUI may change during reauthentication, but the home 
> server doesn't need 
>    to check if it has changed. 

The home network is the only entity that can change the value of the CUI.
Note that the value of the CUI is opaque to the NAS.

During reauthentication it may want to change the value of CUI. This could
happen because local policy states that change CUI on the 1st of every
month. So if the session spans midnight it may change the CUI.

> 2) if the home server does check and notice that it has 
> changed, then it should
>    send an Access-Reject. 

This is just in case the NAS changed the value of CUI. It should never do
this.  But to be complete that clause says what will happen.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, April 26, 2005 2:54 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Issue 83: CUI and re-authentication
> 
> 
> Farid,
> 
> I edited your text somewhat:
> 
>  When reauthenticating, a NAS that supports CUI MUST include 
> the CUI  attribute with the value of CUI received in a 
> previous Access-Accept.
> 
>  Upon receiving a non-nul CUI in an Access-Request the home 
> RADIUS server  MAY verify that the value of CUI matches the 
> the CUI from the previous  Access-Accept If the verification 
> fails, then the RADIUS server SHOULD 
>  respond with an Access-Reject message.
> 
>  During reauthentication, upon receiving an Access-Accept, 
> the value of  the CUI maybe different from the previously 
> received CUI for that  session. The NAS MUST use this value 
> on all subsequent accounting  messages for that session.
> 
> But I am confused by this; you are stating that 
> 
> 1) the CUI may change during reauthentication, but the home 
> server doesn't need 
>    to check if it has changed. 
> 2) if the home server does check and notice that it has 
> changed, then it should
>    send an Access-Reject. 
> 
> What is the purpose of this, if checking is optional?  A MAY 
> followed by a SHOULD is not really create deterministic 
> behavior. Can you explain in a bit more detail what kind of 
> behavior you are trying to get?
> 
> John
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of ext Adrangi, Farid
> > Sent: 26 April, 2005 07:12
> > To: Bernard Aboba
> > Cc: [email-masked]; Nelson, David
> > Subject: RE: Issue 83: CUI and re-authentication
> > 
> > 
> > No. The "Validation" means that the RADIUS server checks to 
> see if the 
> > CUI value is the same as the one that was sent in the previous
> > Access-Accept.   However, the RADIUS server does not require 
> > to do this
> > validation.
> > Thanks,
> > Farid
> > 
> > > -----Original Message-----
> > > From: Bernard Aboba [mailto:[email-masked]]
> > > Sent: Monday, April 25, 2005 6:50 PM
> > > To: Adrangi, Farid
> > > Cc: [email-masked]; Nelson, David
> > > Subject: RE: Issue 83: CUI and re-authentication
> > > 
> > > 
> > > Presumably, by "validated" you mean that the CUI presented is
> > > associated
> > > with the subsequently authenticated identity.
> > > 
> > > On Mon, 25 Apr 2005, Adrangi, Farid wrote:
> > > 
> > > > Good point Bernard!  Avi and I just discussed this, and
> > our current
> > > > thinking is to add something like below to the draft:
> > > >
> > > > "
> > > > When re-authenticating, a NAS that supports CUI MUST
> > include the CUI
> > > > attribute with the value of CUI received in a previous
> > > Access-Accept.
> > > >
> > > > Upon receiving a non-nul CUI in an Access-Request the home
> > > RADIUS server
> > > > MAY validate the value of CUI and if the validation
> > fails, then the
> > > > RADIUS server SHOULD respond with an Access-Reject message.
> > > >
> > > > During reauthentication, upon receiving an Access-Accept,
> > > the value of
> > > > the CUI maybe different from the previously received 
> CUI for that 
> > > > session. The NAS MUST use this value on all subsequent 
> accounting 
> > > > messages for that session. "
> > > >
> > > > Does this work for you, all?
> > > >
> > > > Thanks,
> > > > Farid
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> > > > > [mailto:[email-masked]] On Behalf Of 
> Bernard Aboba
> > > > > Sent: Friday, April 22, 2005 7:33 PM
> > > > > To: [email-masked]
> > > > > Subject: Issue 83: CUI and re-authentication
> > > > >
> > > > >
> > > > > Issue 83: CUI and re-authentication
> > > > > Submitter name: Bernard Aboba
> > > > > Submitter email address: [email-masked]
> > > > > Date first submitted: April 22, 2005
> > > > > Reference:
> > > > > Document: CUI-04
> > > > > Comment type: T
> > > > > Priority: S
> > > > > Section: Various
> > > > > Rationale/Explanation of issue:
> > > > >
> > > > > The document does not state how CUI is used with an 
> > > > > Access-Request that occurs due to re-authentication.  For 
> > > > > example, in the original authentication, the CUI 
> attribute was 
> > > > > provided within the Access-Accept,
> > > > > and subsequently within Accounting-Request packets 
> > > (interim).  Let us
> > > > > assume that a Session-Timeout attribute was sent with 
> > > > > Termination-Action=RADIUS.
> > > > >
> > > > > What happens at the expiration of the Session-Timeout value? 
> > > > > Does the NAS send an Access-Request containing a CUI 
> attribute 
> > > > > to the
> > > RADIUS server
> > > > > with the currently used CUI, or does it send an empty CUI 
> > > > > attribute?  It seems more appropriate for it to send the 
> > > > > currently used CUI, since that
> > > > > does not require the RADIUS server to keep state.  I presume
> > > > > that the User-Name and EAP re-authentication elements are
> > > > > handled the same
> > > > > way (e.g. User-Name includes "@realm" privacy NAI).
> > > > >
> > > > > --
> > > > > to unsubscribe send 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: Tue, 26 Apr 2005 15:13:32 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Blumenthal, Uri'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 08:12:58 -0700

Blumenthal, Uri <mailto:[email-masked]> supposedly
scribbled:

> It was my understanding that while EAP is between the client
> (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP
method*
> that runs on top of EAP is between the client and RADIUS server. 

No.  Can we just _get it_ once and for all?  AAA & EAP are
_different_ and _separate_ things: there is no part of EAP that is
"between" the EAP peer and any AAA entity.

> 
> This tunnel created by EAP method can be considered as "trust
between
> the client and AAA", 

See above.

> and RADIUS between NAS and AAA (however it is 
> accomplished) is "trust between NAS and AAA".
> 
> And yes, many find convenient to connect authorization decision to
> some extra information about the supplicant - such as its posture
> evaluation (Cisco NAC, Microsoft NAP, etc). Such information would
> naturally be carried in TLVs as part of EAP inner method exchange.

Or more rationally (gasp!) in a subsequent _authorization_ protocol
exchange.

> Yes it seems to go way beyond the original purpose of EAP, but
then
> it does seem to address the today's need.  

If one has a sore toe, shooting oneself in the foot may seem to
satisfy "today's need"; in the long run, however, it will probably
turn out to be counterproductive.
   
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Bernard Aboba
> Sent: Monday, April 25, 2005 10:02 PM
> To: Glen Zorn (gwz)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> Martin Soukup said:
> 
>> The use of RADIUS itself without a defined extension such as
EAP-TLS
>> or EAP-PEAP over RADIUS cannot securely pass attributes between
>> entities. Note that the defined EAP-TLS (or other EAP mechanisms)
>> over RADIUS provides for secure attribute passing between
entities
>> even through proxies.
> 
> In response to which, Glen Zorn spake thusly:
> 
>> I thought that I was passing familiar w/EAP-TLS (and even more so
>> w/PEAP), but I am completely unaware of such capabilities.  Would
you
>> mind explaining how this is achieved, given that RADIUS & EAP are
>> completely different protocols?
> 
> I also was unaware of the ability of EAP-TLS to transmit RADIUS
> attributes between the EAP peer and server.  I had always thought
> RADIUS was a protocol only spoken between a NAS and a RADIUS
server,
> and that EAP-TLS didn't support transmission of TLVs.  But I guess
> this is a somewhat old fashioned point of view.    
> 
> Perhaps this is referring to EAP-TLS "extended" via the following?
>
http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application
-ext
> ension-01.txt
> 
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms

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, 26 Apr 2005 14:43:18 +0000
Date: Tue, 26 Apr 2005 07:43:08 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: [eap] Implementation Survey:  How does your EAP peer/RADIUS proxy handle internationalization? (fwd)

---------- Forwarded message ----------
Date: Tue, 26 Apr 2005 02:07:53 -0400
From: Yoshihiro Ohba <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: [eap] Implementation Survey:  How does your EAP peer/RADIUS
    proxy handle internationalization?

Hi Bernard,

I have EAP peer implementation (Open Diameter libeap) and I can answer
to the 1st question.

On Mon, Apr 25, 2005 at 08:46:25AM -0700, Bernard Aboba wrote:
> RFC 2486bis specifies how the NAI is internationalized.  In the
> development of this document, some questions have arisen about the
> behavior of existing EAP peers and RADIUS proxies.  In order to understand
> how existing implementations function, we need implementers to volunteer
> the answer to several questions:
>
> 1. How is internationalization supported on your EAP peer implementation?
>
> Does your EAP peer implementation support formating of the realm
> portion in IDN, or does it enable entering of UTF-8, or perhaps just plain
> ASCII?

When an EAP Request/Identity is received, the peer silently discards
the message if it contains a non-UTF-8 string.

When an EAP Response/Identity is going to be sent, the peer checks the
contents of the identity passed from an application (the application
can use any UTF-8 string as identity) and silently discards the
message instead of sending it, if it contains a non-UTF-8 string.

The peer silently discards EAP Request/Identity if it contains a
non-UTF-8 string.

These may be too restrictive (as it accepts only UTF-8 string) and I
may change my implementation to allow more flexibility.

Hope this helps,

Yoshihiro Ohba

>
> 2. How is internationalization supported on your RADIUS proxy
> implementation?.
>
> How does your implementation support internationalization within the realm
> table?  Are realm table entries stored in IDN, UTF-8, or something else?
> How are comparisons done between the realm in the NAI and the realm stored
> in the realm table?
>
> Please respond by May 2, 2005.
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

--
to unsubscribe send a message 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, 26 Apr 2005 14:25:46 +0000
Date: Tue, 26 Apr 2005 07:24:49 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked], "Nelson, David" <[email-masked]>
Subject: RE: Issue 83: CUI and re-authentication

OK.  You might clarify that in the document.

On Mon, 25 Apr 2005, Adrangi, Farid wrote:

> No. The "Validation" means that the RADIUS server checks to see if the
> CUI value is the same as the one that was sent in the previous
> Access-Accept.   However, the RADIUS server does not require to do this
> validation.
> Thanks,
> Farid
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:[email-masked]]
> > Sent: Monday, April 25, 2005 6:50 PM
> > To: Adrangi, Farid
> > Cc: [email-masked]; Nelson, David
> > Subject: RE: Issue 83: CUI and re-authentication
> >
> >
> > Presumably, by "validated" you mean that the CUI presented is
> > associated with the subsequently authenticated identity.

--
to unsubscribe send a message 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, 26 Apr 2005 06:58:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: 2486bis internationalization and ! syntax
Date: Tue, 26 Apr 2005 09:55:57 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Jari,

I agree with Bernard that before deciding on a solution, we need
to better understand what the current implementations are doing.

I think that 1) might be preferable, if this is more in-line with
what current proxies are doing.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Jari Arkko
> Sent: 25 April, 2005 06:26
> To: [email-masked]
> Subject: Issue: 2486bis internationalization and ! syntax
>=20
>=20
> Issue 4 is about the interaction between internationzalition
> an the ! transformation within NAIs. Basically you may change
>=20
>      [email-masked]
>=20
> to
>=20
>      [email-masked]
>=20
> and back, under certain exceptional AAA routing conditions,
> i.e., when the local network can route/roam your request back
> to the right place.
>=20
> Now, what makes this interesting is that the usernamepart is
> in UTF-8 and realmpart is an IDN in ASCII. Here there are
> multiple resolutions of the issue.
>=20
> #1: This transformation is an exceptional case where proxies
> will perform some mapping from one character set to another.
>=20
> Where such transformations are done, an attempt
> to transform a string that can't be mapped to IDN (e.g. illegal
> DNS name) should result in an error. From the user's point
> of view this would be a similar error as you get when the domain
> you are trying to give is unknown. Correct use of the this
> transformation should not result in this error, given that the
> string you put in from the '!' should have originally been a
> realm name.
>=20
> One drawback of this is that in order for the proxy to map UTF-8
> to ASCII, it needs to understand the codepoints. This means in
> practise that a proxy with a today's codepoint data is unable to
> do the transformation for something that uses a newer codepoint.
> New codepoints are often defined but my understanding is that
> they are for quite special and small languages. Given this and
> the exceptional nature of the ! usage this may be acceptable.
>=20
> #2: Realmpart needs to be converted to IDNA if and when a DNS
> query needs to be sent.  However, only  Diameter defines how DNS
> queries can be used to locate AAA servers; RADIUS  implementations
> do not support this.
>=20
> It has been suggested that in order to "optimize for the=20
> common case" that
> the entire string could be left in UTF-8, obviating the need for=20
> conversions
> between UTF-8 and IDNA until a DNS query needed to be sent.  Since
> RADIUS implementations do not send such queries, they would=20
> not need to
> do the conversion at all.  Within a Diameter agent,  the conversion
> could be delayed until it is required, at which time it might
> conceivably fail.
>=20
> One problem with this is that existing nde that does the
> query would be unable to do a UTF-8 query but would be
> able to do an IDN query. Oh well, there isn't much Diameter
> usage that would be hit with this...
>=20
> And there seems to be another more serious problem. Namely, even
> if RADIUS doesn't do DNS queries, it still stores and compares
> strings. If someone has already put in a rule or entry for an
> international DNS name, he has  been able to do so already in
> RFC 2486, because IDNs are really legal DNS names. And he
> likely didn't use UTF-8, because that would have been illegal
> as a NAI. Now, if we suddenly start sending the IDNs as UTF-8
> instead, this will break existing usage. All that is needed for
> this scenario to apply is someone who (a) has an international
> DNS name and (b) has a RADIUS server. What's the likelihood
> of this?
>=20
> My conclusion: problems in approach #2 seem more likely
> to appear in common cases, so my preference is #1. What
> do others think?
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 26 Apr 2005 06:58:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 83: CUI and re-authentication
Date: Tue, 26 Apr 2005 09:54:22 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Farid,

I edited your text somewhat:

 When reauthenticating, a NAS that supports CUI MUST include the CUI
 attribute with the value of CUI received in a previous Access-Accept.

 Upon receiving a non-nul CUI in an Access-Request the home RADIUS =
server
 MAY verify that the value of CUI matches the the CUI from the previous
 Access-Accept If the verification fails, then the RADIUS server SHOULD=20
 respond with an Access-Reject message.

 During reauthentication, upon receiving an Access-Accept, the value of
 the CUI maybe different from the previously received CUI for that
 session. The NAS MUST use this value on all subsequent accounting
 messages for that session.

But I am confused by this; you are stating that=20

1) the CUI may change during reauthentication, but the home server =
doesn't need=20
   to check if it has changed.=20
2) if the home server does check and notice that it has changed, then it =
should
   send an Access-Reject.=20

What is the purpose of this, if checking is optional?  A MAY followed by =
a SHOULD
is not really create deterministic behavior. Can you explain in a bit =
more detail
what kind of behavior you are trying to get?

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Adrangi, Farid
> Sent: 26 April, 2005 07:12
> To: Bernard Aboba
> Cc: [email-masked]; Nelson, David
> Subject: RE: Issue 83: CUI and re-authentication
>=20
>=20
> No. The "Validation" means that the RADIUS server checks to see if the
> CUI value is the same as the one that was sent in the previous
> Access-Accept.   However, the RADIUS server does not require=20
> to do this
> validation.
> Thanks,
> Farid
>=20
> > -----Original Message-----
> > From: Bernard Aboba [mailto:[email-masked]]=20
> > Sent: Monday, April 25, 2005 6:50 PM
> > To: Adrangi, Farid
> > Cc: [email-masked]; Nelson, David
> > Subject: RE: Issue 83: CUI and re-authentication
> >=20
> >=20
> > Presumably, by "validated" you mean that the CUI presented is=20
> > associated
> > with the subsequently authenticated identity.
> >=20
> > On Mon, 25 Apr 2005, Adrangi, Farid wrote:
> >=20
> > > Good point Bernard!  Avi and I just discussed this, and=20
> our current
> > > thinking is to add something like below to the draft:
> > >
> > > "
> > > When re-authenticating, a NAS that supports CUI MUST=20
> include the CUI
> > > attribute with the value of CUI received in a previous=20
> > Access-Accept.
> > >
> > > Upon receiving a non-nul CUI in an Access-Request the home=20
> > RADIUS server
> > > MAY validate the value of CUI and if the validation=20
> fails, then the
> > > RADIUS server SHOULD respond with an Access-Reject message.
> > >
> > > During reauthentication, upon receiving an Access-Accept,=20
> > the value of
> > > the CUI maybe different from the previously received CUI for that
> > > session. The NAS MUST use this value on all subsequent accounting
> > > messages for that session.
> > > "
> > >
> > > Does this work for you, all?
> > >
> > > Thanks,
> > > Farid
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > > > Sent: Friday, April 22, 2005 7:33 PM
> > > > To: [email-masked]
> > > > Subject: Issue 83: CUI and re-authentication
> > > >
> > > >
> > > > Issue 83: CUI and re-authentication
> > > > Submitter name: Bernard Aboba
> > > > Submitter email address: [email-masked]
> > > > Date first submitted: April 22, 2005
> > > > Reference:
> > > > Document: CUI-04
> > > > Comment type: T
> > > > Priority: S
> > > > Section: Various
> > > > Rationale/Explanation of issue:
> > > >
> > > > The document does not state how CUI is used with an
> > > > Access-Request that
> > > > occurs due to re-authentication.  For example, in the original
> > > > authentication, the CUI attribute was provided within the
> > > > Access-Accept,
> > > > and subsequently within Accounting-Request packets=20
> > (interim).  Let us
> > > > assume that a Session-Timeout attribute was sent with
> > > > Termination-Action=3DRADIUS.
> > > >
> > > > What happens at the expiration of the Session-Timeout value?
> > > > Does the NAS
> > > > send an Access-Request containing a CUI attribute to the=20
> > RADIUS server
> > > > with the currently used CUI, or does it send an empty CUI
> > > > attribute?  It
> > > > seems more appropriate for it to send the currently used CUI,
> > > > since that
> > > > does not require the RADIUS server to keep state.  I presume
> > > > that the User-Name and EAP re-authentication elements are
> > > > handled the same
> > > > way (e.g. User-Name includes "@realm" privacy NAI).
> > > >
> > > > --
> > > > 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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 26 Apr 2005 04:13:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 83: CUI and re-authentication
Date: Mon, 25 Apr 2005 21:12:15 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, "Nelson, David" <[email-masked]>

No. The "Validation" means that the RADIUS server checks to see if the
CUI value is the same as the one that was sent in the previous
Access-Accept.   However, the RADIUS server does not require to do this
validation.
Thanks,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Monday, April 25, 2005 6:50 PM
> To: Adrangi, Farid
> Cc: [email-masked]; Nelson, David
> Subject: RE: Issue 83: CUI and re-authentication
>=20
>=20
> Presumably, by "validated" you mean that the CUI presented is=20
> associated
> with the subsequently authenticated identity.
>=20
> On Mon, 25 Apr 2005, Adrangi, Farid wrote:
>=20
> > Good point Bernard!  Avi and I just discussed this, and our current
> > thinking is to add something like below to the draft:
> >
> > "
> > When re-authenticating, a NAS that supports CUI MUST include the CUI
> > attribute with the value of CUI received in a previous=20
> Access-Accept.
> >
> > Upon receiving a non-nul CUI in an Access-Request the home=20
> RADIUS server
> > MAY validate the value of CUI and if the validation fails, then the
> > RADIUS server SHOULD respond with an Access-Reject message.
> >
> > During reauthentication, upon receiving an Access-Accept,=20
> the value of
> > the CUI maybe different from the previously received CUI for that
> > session. The NAS MUST use this value on all subsequent accounting
> > messages for that session.
> > "
> >
> > Does this work for you, all?
> >
> > Thanks,
> > Farid
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > > Sent: Friday, April 22, 2005 7:33 PM
> > > To: [email-masked]
> > > Subject: Issue 83: CUI and re-authentication
> > >
> > >
> > > Issue 83: CUI and re-authentication
> > > Submitter name: Bernard Aboba
> > > Submitter email address: [email-masked]
> > > Date first submitted: April 22, 2005
> > > Reference:
> > > Document: CUI-04
> > > Comment type: T
> > > Priority: S
> > > Section: Various
> > > Rationale/Explanation of issue:
> > >
> > > The document does not state how CUI is used with an
> > > Access-Request that
> > > occurs due to re-authentication.  For example, in the original
> > > authentication, the CUI attribute was provided within the
> > > Access-Accept,
> > > and subsequently within Accounting-Request packets=20
> (interim).  Let us
> > > assume that a Session-Timeout attribute was sent with
> > > Termination-Action=3DRADIUS.
> > >
> > > What happens at the expiration of the Session-Timeout value?
> > > Does the NAS
> > > send an Access-Request containing a CUI attribute to the=20
> RADIUS server
> > > with the currently used CUI, or does it send an empty CUI
> > > attribute?  It
> > > seems more appropriate for it to send the currently used CUI,
> > > since that
> > > does not require the RADIUS server to keep state.  I presume
> > > that the User-Name and EAP re-authentication elements are
> > > handled the same
> > > way (e.g. User-Name includes "@realm" privacy NAI).
> > >
> > > --
> > > 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

--
to unsubscribe send a message 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, 26 Apr 2005 02:01:40 +0000
Date: Mon, 25 Apr 2005 19:01:31 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

Martin Soukup said:

> The use of RADIUS itself without a defined extension such as EAP-TLS
> or EAP-PEAP over RADIUS cannot securely pass attributes between
> entities. Note that the defined EAP-TLS (or other EAP mechanisms)
> over RADIUS provides for secure attribute passing between entities
> even through proxies.

In response to which, Glen Zorn spake thusly:

> I thought that I was passing familiar w/EAP-TLS (and even more so
> w/PEAP), but I am completely unaware of such capabilities.  Would
> you mind explaining how this is achieved, given that RADIUS & EAP
> are completely different protocols?

I also was unaware of the ability of EAP-TLS to transmit RADIUS attributes
between the EAP peer and server.  I had always thought RADIUS was a
protocol only spoken between a NAS and a RADIUS server, and that EAP-TLS
didn't support transmission of TLVs.  But I guess this is a somewhat old
fashioned point of view.

Perhaps this is referring to EAP-TLS "extended" via the following?
http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extension-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: Tue, 26 Apr 2005 01:50:10 +0000
Date: Mon, 25 Apr 2005 18:49:31 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked], "Nelson, David" <[email-masked]>
Subject: RE: Issue 83: CUI and re-authentication

Presumably, by "validated" you mean that the CUI presented is associated
with the subsequently authenticated identity.

On Mon, 25 Apr 2005, Adrangi, Farid wrote:

> Good point Bernard!  Avi and I just discussed this, and our current
> thinking is to add something like below to the draft:
>
> "
> When re-authenticating, a NAS that supports CUI MUST include the CUI
> attribute with the value of CUI received in a previous Access-Accept.
>
> Upon receiving a non-nul CUI in an Access-Request the home RADIUS server
> MAY validate the value of CUI and if the validation fails, then the
> RADIUS server SHOULD respond with an Access-Reject message.
>
> During reauthentication, upon receiving an Access-Accept, the value of
> the CUI maybe different from the previously received CUI for that
> session. The NAS MUST use this value on all subsequent accounting
> messages for that session.
> "
>
> Does this work for you, all?
>
> Thanks,
> Farid
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > Sent: Friday, April 22, 2005 7:33 PM
> > To: [email-masked]
> > Subject: Issue 83: CUI and re-authentication
> >
> >
> > Issue 83: CUI and re-authentication
> > Submitter name: Bernard Aboba
> > Submitter email address: [email-masked]
> > Date first submitted: April 22, 2005
> > Reference:
> > Document: CUI-04
> > Comment type: T
> > Priority: S
> > Section: Various
> > Rationale/Explanation of issue:
> >
> > The document does not state how CUI is used with an
> > Access-Request that
> > occurs due to re-authentication.  For example, in the original
> > authentication, the CUI attribute was provided within the
> > Access-Accept,
> > and subsequently within Accounting-Request packets (interim).  Let us
> > assume that a Session-Timeout attribute was sent with
> > Termination-Action=RADIUS.
> >
> > What happens at the expiration of the Session-Timeout value?
> > Does the NAS
> > send an Access-Request containing a CUI attribute to the RADIUS server
> > with the currently used CUI, or does it send an empty CUI
> > attribute?  It
> > seems more appropriate for it to send the currently used CUI,
> > since that
> > does not require the RADIUS server to keep state.  I presume
> > that the User-Name and EAP re-authentication elements are
> > handled the same
> > way (e.g. User-Name includes "@realm" privacy NAI).
> >
> > --
> > to unsubscribe send 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, 25 Apr 2005 23:45:49 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 83: CUI and re-authentication
Date: Mon, 25 Apr 2005 16:45:16 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Nelson, David" <[email-masked]>

Good point Bernard!  Avi and I just discussed this, and our current
thinking is to add something like below to the draft:

"
When re-authenticating, a NAS that supports CUI MUST include the CUI
attribute with the value of CUI received in a previous Access-Accept.

Upon receiving a non-nul CUI in an Access-Request the home RADIUS server
MAY validate the value of CUI and if the validation fails, then the
RADIUS server SHOULD respond with an Access-Reject message.

During reauthentication, upon receiving an Access-Accept, the value of
the CUI maybe different from the previously received CUI for that
session. The NAS MUST use this value on all subsequent accounting
messages for that session.
"

Does this work for you, all?

Thanks,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, April 22, 2005 7:33 PM
> To: [email-masked]
> Subject: Issue 83: CUI and re-authentication
>=20
>=20
> Issue 83: CUI and re-authentication
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: April 22, 2005
> Reference:
> Document: CUI-04
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>=20
> The document does not state how CUI is used with an=20
> Access-Request that
> occurs due to re-authentication.  For example, in the original
> authentication, the CUI attribute was provided within the=20
> Access-Accept,
> and subsequently within Accounting-Request packets (interim).  Let us
> assume that a Session-Timeout attribute was sent with
> Termination-Action=3DRADIUS.
>=20
> What happens at the expiration of the Session-Timeout value? =20
> Does the NAS
> send an Access-Request containing a CUI attribute to the RADIUS server
> with the currently used CUI, or does it send an empty CUI=20
> attribute?  It
> seems more appropriate for it to send the currently used CUI,=20
> since that
> does not require the RADIUS server to keep state.  I presume
> that the User-Name and EAP re-authentication elements are=20
> handled the same
> way (e.g. User-Name includes "@realm" privacy NAI).
>=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: Mon, 25 Apr 2005 20:18:21 +0000
Date: Mon, 25 Apr 2005 13:18:00 -0700
From: Murtaza Chiba <[email-masked]>
To: [email-masked]
Subject: Issue:

Description of issue:
	VSAs for  Session-Identification

Submitter name: Murtaza S. Chiba

Submitter email address: [email-masked]

Date first submitted: April 25th 2005

Reference: URL to e-mail describing problem, if available

Document: RFC3576

Comment type: E

Priority: 1

Section: 3

Rationale/Explanation of issue:
    Some VSAs could be used for Session-Identification in addition to 
any authorization purpose.

Length description of problem
    In section 3 under Session Identification attributes, 
Vendor-Specific attributes are not mentioned.  This should be left to a 
vendor to decide which attributes designate session identification and 
which designate authorization in the case where ambiguity is clearly 
eliminated.  That is a subtype and/or contents readily distinguish 
between session identification and authorization.

    Also in section 3.3 Note 3 mentions that the VSA is only for 
authorization.  This too should be changed to allow for session 
identification.

Requested change:
Section 3:
Please add VSA to the list under "Session identification attributes" the 
following text

Vendor-Specific    26   [RFC2865]  The Vendor Specific attribute used
                                    for Session Identification purposes.

Section 3.3:
Modify note 3. from

"When included within a CoA-Request, these attributes
  represent an authorization change request"

to

"When included within a CoA-Request, these attributes MAY represent an 
authorization change requests"

Thanks,
Murtaza

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

Delivery-date: Mon, 25 Apr 2005 17:29:21 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Martin Soukup'" <[email-masked]>, "'Thierry Moreau'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Mon, 25 Apr 2005 10:28:56 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0087_01C54981.9B1F8470
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The use of RADIUS itself without a defined extension such as EAP-TLS
or EAP-PEAP over RADIUS cannot securely pass attributes between
entities. Note that the defined EAP-TLS (or other EAP mechanisms)
over RADIUS provides for secure attribute passing between entities
even through proxies. 
 
I thought that I was passing familiar w/EAP-TLS (and even more so
w/PEAP), but I am completely unaware of such capabilities.  Would
you mind explaining how this is achieved, given that RADIUS & EAP
are completely different protocols?

Martin. 

> -----Original Message----- 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thierry Moreau 
> Sent: April 22, 2005 1:56 PM 
> To: Bernard Aboba 
> Cc: [email-masked]; [email-masked]; [email-masked] 
> Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party 
> 
> 
> Thanks for these explanations. 
> 
> See comments in-line below. 
> 
> 
> 
> Bernard Aboba wrote: 
> 
> [... explanations about end-to-end (NAS to server) and current
RADIUS 
> protocols ...] 
> 
> > 
> > Are you proposing creating a new RADIUS security model that 
> would only 
> > be used by ISMS?  That seems like a lot of work for little
overall 
> > benefit to the RADIUS community. 
> > 
> 
> I did assume that an implementation-specific attribute to the
RADIUS 
> Access-Accept packet would pass unmodified through a RADIUS 
> proxy, which 
> in fact is a matter of proxy policy (RFC2865 , section 2.3). 
> With this 
> erroneous assumption, I thought I was proposing an 
> implementation-specific use of existing RADIUS protocol 
> facility. I did 
> not expect any "benefit to the RADIUS community". 
> 
> > 
> > 
> > Rather than designing a new version of RADIUS to meet its needs,
it 
> > seems more profitable for ISMS to either figure out how to use
the 
> > protocol as it exists today, or to summarize its 
> requirements for new 
> > work and ask that it be chartered outside of ISMS. 
> > 
> 
> Point well taken. I just looked at RFC3576, abstract reproduced
below 
> 
>     "This document describes a currently deployed extension 
> to the Remote 
>     Authentication Dial In User Service (RADIUS) protocol,
allowing 
>     dynamic changes to a user session, as implemented by 
> network access 
>     server products.  This includes support for disconnecting 
> users and 
>     changing authorizations applicable to a user session." 
> 
> Unfortunately, the security section of RFC3576 raises a number of 
> concerns. E.g. the following sentence: "It is RECOMMENDED 
> that IPsec be 
> employed to afford better security." 
> 
> Again, thanks for your comments. 
> 
> -- 
> 
> - Thierry Moreau 
> 
> CONNOTECH Experts-conseils inc. 
> 9130 Place de Montgolfier 
> Montreal, Qc 
> Canada   H2M 2A1 
> 
> Tel.: (514)385-5691 
> Fax:  (514)385-5900 
> 
> web site: http://www.connotech.com 
> e-mail: [email-masked] 
> 
> 
> _______________________________________________ 
> Isms mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/isms 
> 
> 

------=_NextPart_000_0087_01C54981.9B1F8470
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [eap] RE: [Isms] RADIUS is not a trusted third =
party</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1498" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2>The use of RADIUS itself =
without a defined=20
extension such as EAP-TLS or EAP-PEAP over RADIUS cannot securely pass=20
attributes between entities. Note that the defined EAP-TLS (or other EAP =

mechanisms) over RADIUS provides for secure attribute passing between =
entities=20
even through proxies.<SPAN class=3D408102217-25042005><FONT face=3DArial =

color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
class=3D408102217-25042005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN =
class=3D408102217-25042005><FONT=20
face=3DArial color=3D#0000ff>I thought that I was passing familiar =
w/EAP-TLS (and=20
even more so w/PEAP), but I am completely unaware of such =
capabilities.&nbsp;=20
Would you mind explaining how this is achieved, given that RADIUS &amp; =
EAP are=20
completely different protocols?</FONT></SPAN></FONT></DIV>
<P><FONT size=3D2>Martin.</FONT> </P>
<P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
From: [email-masked] </FONT><BR><FONT size=3D2>&gt; [<A=20
href=3D"mailto:[email-masked]">mailto:[email-masked]=
f.org</A>]=20
On Behalf Of Thierry Moreau</FONT> <BR><FONT size=3D2>&gt; Sent: April =
22, 2005=20
1:56 PM</FONT> <BR><FONT size=3D2>&gt; To: Bernard Aboba</FONT> =
<BR><FONT=20
size=3D2>&gt; Cc: [email-masked]; [email-masked]; =
[email-masked]</FONT>=20
<BR><FONT size=3D2>&gt; Subject: Re: [eap] RE: [Isms] RADIUS is not a =
trusted=20
third party</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Thanks for these explanations.</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; See comments in-line =
below.</FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Bernard Aboba wrote:</FONT> <BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; [... explanations about end-to-end (NAS =
to server)=20
and current RADIUS </FONT><BR><FONT size=3D2>&gt; protocols ...]</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
Are you proposing creating a new RADIUS security model that =
</FONT><BR><FONT=20
size=3D2>&gt; would only </FONT><BR><FONT size=3D2>&gt; &gt; be used by =
ISMS?&nbsp;=20
That seems like a lot of work for little overall </FONT><BR><FONT =
size=3D2>&gt;=20
&gt; benefit to the RADIUS community.</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
</FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I did =
assume that an=20
implementation-specific attribute to the RADIUS </FONT><BR><FONT =
size=3D2>&gt;=20
Access-Accept packet would pass unmodified through a RADIUS =
</FONT><BR><FONT=20
size=3D2>&gt; proxy, which </FONT><BR><FONT size=3D2>&gt; in fact is a =
matter of=20
proxy policy (RFC2865 , section 2.3). </FONT><BR><FONT size=3D2>&gt; =
With this=20
</FONT><BR><FONT size=3D2>&gt; erroneous assumption, I thought I was =
proposing an=20
</FONT><BR><FONT size=3D2>&gt; implementation-specific use of existing =
RADIUS=20
protocol </FONT><BR><FONT size=3D2>&gt; facility. I did </FONT><BR><FONT =

size=3D2>&gt; not expect any "benefit to the RADIUS community".</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
</FONT><BR><FONT size=3D2>&gt; &gt; Rather than designing a new version =
of RADIUS=20
to meet its needs, it </FONT><BR><FONT size=3D2>&gt; &gt; seems more =
profitable=20
for ISMS to either figure out how to use the </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
protocol as it exists today, or to summarize its </FONT><BR><FONT =
size=3D2>&gt;=20
requirements for new </FONT><BR><FONT size=3D2>&gt; &gt; work and ask =
that it be=20
chartered outside of ISMS.</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Point well taken. I just =
looked at=20
RFC3576, abstract reproduced below</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; "This document describes a =
currently=20
deployed extension </FONT><BR><FONT size=3D2>&gt; to the Remote</FONT> =
<BR><FONT=20
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Authentication Dial In User =
Service (RADIUS)=20
protocol, allowing</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; dynamic=20
changes to a user session, as implemented by </FONT><BR><FONT =
size=3D2>&gt;=20
network access</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
server=20
products.&nbsp; This includes support for disconnecting </FONT><BR><FONT =

size=3D2>&gt; users and</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
changing authorizations applicable to a user session."</FONT> <BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Unfortunately, the security =
section of=20
RFC3576 raises a number of </FONT><BR><FONT size=3D2>&gt; concerns. E.g. =
the=20
following sentence: "It is RECOMMENDED </FONT><BR><FONT size=3D2>&gt; =
that IPsec=20
be </FONT><BR><FONT size=3D2>&gt; employed to afford better =
security."</FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Again, thanks for =
your=20
comments.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
--=20
</FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; - Thierry=20
Moreau</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
CONNOTECH=20
Experts-conseils inc.</FONT> <BR><FONT size=3D2>&gt; 9130 Place de=20
Montgolfier</FONT> <BR><FONT size=3D2>&gt; Montreal, Qc</FONT> <BR><FONT =

size=3D2>&gt; Canada&nbsp;&nbsp; H2M 2A1</FONT> <BR><FONT size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Tel.: (514)385-5691</FONT> <BR><FONT =
size=3D2>&gt;=20
Fax:&nbsp; (514)385-5900</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =

size=3D2>&gt; web site: <A href=3D"http://www.connotech.com"=20
target=3D_blank>http://www.connotech.com</A></FONT> <BR><FONT =
size=3D2>&gt; e-mail:=20
[email-masked]</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
Isms mailing list</FONT> <BR><FONT size=3D2>&gt; =
[email-masked]</FONT>=20
<BR><FONT size=3D2>&gt; <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT></P></BODY></HTML>

------=_NextPart_000_0087_01C54981.9B1F8470--

--
to unsubscribe send 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, 25 Apr 2005 17:14:15 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? 
Date: Mon, 25 Apr 2005 13:11:09 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> 1. How is internationalization supported on your EAP peer implementation?

  The implementation enables internationalization, but doesn't fully
support it.[1]

> Does your EAP peer implementation support formating of the realm
> portion in IDN, or does it enable entering of UTF-8, or perhaps just plain
> ASCII?

  It enables entering UTF-8 text.

> 2. How is internationalization supported on your RADIUS proxy
> implementation?.

  The implementation enables internationalization, but doesn't fully
support it.[1]

> How does your implementation support internationalization within the realm
> table?  Are realm table entries stored in IDN, UTF-8, or something else?

  They are stored as NUL terminated C strings.[2]

> How are comparisons done between the realm in the NAI and the realm stored
> in the realm table?

  strcmp()

Notes: [1] If your file editor will write UTF-8 strings to the
configuration files, FreeRADIUS will read them and use them.  But it
will not print them as the appropriate UTF-8 glyphs in it's output or
log files.  Instead, it will print non-ASCII characters as
octal-encoded strings.  e.g "\303\301"

[2] The RADIUS client, server and EAP peer treat the strings as opaque
tokens for internal processing.  Therefore UTF-8 text may be entered,
or any other non-ASCII data, so long as it does not contain a NUL
(zero) character.

  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, 25 Apr 2005 16:00:30 +0000
Date: Mon, 25 Apr 2005 09:00:18 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Martin Soukup <[email-masked]>
cc: "'Thierry Moreau'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

> The use of RADIUS itself without a defined extension such as EAP-TLS or
> EAP-PEAP over RADIUS cannot securely pass attributes between entities. Note
> that the defined EAP-TLS (or other EAP mechanisms) over RADIUS provides for
> secure attribute passing between entities even through proxies.

EAP does not affect how RADIUS attributes are passed, nor does it enable
the passing of RADIUS attributes between the EAP peer and server.  So as
far as RADIUS attributes are concerned, what EAP method is used, or
whether EAP is used does not affect RADIUS security, except that an
EAP-Message attribute is included in the messages.

Also, EAP-TLS does not permit passing of TLVs between the peer and server;
this is only allowed in tunneled mechanisms such as EAP-TTLS and PEAP.

--
to unsubscribe send a message 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, 25 Apr 2005 15:54:49 +0000
Date: Mon, 25 Apr 2005 08:54:39 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: Issue: 2486bis internationalization and ! syntax

> One problem with this is that existing code that does the
> query would be unable to do a UTF-8 query but would be
> able to do an IDN query. Oh well, there isn't much Diameter
> usage that would be hit with this...
>
> And there seems to be another more serious problem. Namely, even
> if RADIUS doesn't do DNS queries, it still stores and compares
> strings. If someone has already put in a rule or entry for an
> international DNS name, he has  been able to do so already in
> RFC 2486, because IDNs are really legal DNS names. And he
> likely didn't use UTF-8, because that would have been illegal
> as a NAI. Now, if we suddenly start sending the IDNs as UTF-8
> instead, this will break existing usage. All that is needed for
> this scenario to apply is someone who (a) has an international
> DNS name and (b) has a RADIUS server. What's the likelihood
> of this?
>
> My conclusion: problems in approach #2 seem more likely
> to appear in common cases, so my preference is #1. What
> do others think?

I think that we need to understand more about how existing EAP peer and
RADIUS proxy implementations function with respect to
internationalization.  For example, do existing EAP peer implementations
allow the user to enter UTF-8?  How do existing RADIUS proxy
implementations enter the realm table and how do they compare it against
the realm in the NAI?

I've put out an implementation survey that may help us answer these
questions.

--
to unsubscribe send a message 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, 25 Apr 2005 15:44:19 +0000
Date: Mon, 25 Apr 2005 08:43:30 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Implementation Survey:  How does your EAP peer/RADIUS proxy handle internationalization?

RFC 2486bis specifies how the NAI is internationalized.  In the
development of this document, some questions have arisen about the
behavior of existing EAP peers and RADIUS proxies.  In order to understand
how existing implementations function, we need implementers to volunteer
the answer to several questions:

1. How is internationalization supported on your EAP peer implementation?

Does your EAP peer implementation support formating of the realm
portion in IDN, or does it enable entering of UTF-8, or perhaps just plain
ASCII?

2. How is internationalization supported on your RADIUS proxy
implementation?.

How does your implementation support internationalization within the realm
table?  Are realm table entries stored in IDN, UTF-8, or something else?
How are comparisons done between the realm in the NAI and the realm stored
in the realm table?

Please respond by May 2, 2005.

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

Delivery-date: Mon, 25 Apr 2005 05:59:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: 2486bis internationalization and unassigned codepoints
Date: Mon, 25 Apr 2005 08:57:33 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Jari,

This seems reasonable to me.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Jari Arkko
> Sent: 25 April, 2005 06:25
> To: [email-masked]
> Subject: Issue: 2486bis internationalization and unassigned codepoints
>=20
>=20
> At IETF-62, this presentation outlined the i18n issue:
>=20
> http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext_nai.ppt
>=20
> Subproblems 1 and 2 are OK. Subproblems 3 and 4 are still open.
>=20
> 3 is really about what to do with unassigned codepoints. My current
> thinking is that  a username with a particular character X=20
> will not be=20
> entered
> into the Radius server's database unless X is supported the
> Unicode and software versions of the server's admin UI.
> The same for the client end and user's UI. Therefore, I think
> what we need to say is that the all the i18n mapping and
> checking operations happen only at the client (when entering
> a NAI), and when entering this particular user's subscription
> at the server side. And nothing in between should do this
> under normal circumstances, they should just be passing
> bytes along, not checking whether those bytes form unassigned
> or assigned code points.  This ensures that an old proxy doesn't
> prevent your new username from being used.
>=20
> Does this work for everyone?
>=20
> --Jari
>=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: Mon, 25 Apr 2005 03:26:04 +0000
Date: Mon, 25 Apr 2005 06:25:48 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
Subject: Issue: 2486bis internationalization and ! syntax

Issue 4 is about the interaction between internationzalition
an the ! transformation within NAIs. Basically you may change

     [email-masked]

to

     [email-masked]

and back, under certain exceptional AAA routing conditions,
i.e., when the local network can route/roam your request back
to the right place.

Now, what makes this interesting is that the usernamepart is
in UTF-8 and realmpart is an IDN in ASCII. Here there are
multiple resolutions of the issue.

#1: This transformation is an exceptional case where proxies
will perform some mapping from one character set to another.

Where such transformations are done, an attempt
to transform a string that can't be mapped to IDN (e.g. illegal
DNS name) should result in an error. From the user's point
of view this would be a similar error as you get when the domain
you are trying to give is unknown. Correct use of the this
transformation should not result in this error, given that the
string you put in from the '!' should have originally been a
realm name.

One drawback of this is that in order for the proxy to map UTF-8
to ASCII, it needs to understand the codepoints. This means in
practise that a proxy with a today's codepoint data is unable to
do the transformation for something that uses a newer codepoint.
New codepoints are often defined but my understanding is that
they are for quite special and small languages. Given this and
the exceptional nature of the ! usage this may be acceptable.

#2: Realmpart needs to be converted to IDNA if and when a DNS
query needs to be sent.  However, only  Diameter defines how DNS
queries can be used to locate AAA servers; RADIUS  implementations
do not support this.

It has been suggested that in order to "optimize for the common case" that
the entire string could be left in UTF-8, obviating the need for 
conversions
between UTF-8 and IDNA until a DNS query needed to be sent.  Since
RADIUS implementations do not send such queries, they would not need to
do the conversion at all.  Within a Diameter agent,  the conversion
could be delayed until it is required, at which time it might
conceivably fail.

One problem with this is that existing nde that does the
query would be unable to do a UTF-8 query but would be
able to do an IDN query. Oh well, there isn't much Diameter
usage that would be hit with this...

And there seems to be another more serious problem. Namely, even
if RADIUS doesn't do DNS queries, it still stores and compares
strings. If someone has already put in a rule or entry for an
international DNS name, he has  been able to do so already in
RFC 2486, because IDNs are really legal DNS names. And he
likely didn't use UTF-8, because that would have been illegal
as a NAI. Now, if we suddenly start sending the IDNs as UTF-8
instead, this will break existing usage. All that is needed for
this scenario to apply is someone who (a) has an international
DNS name and (b) has a RADIUS server. What's the likelihood
of this?

My conclusion: problems in approach #2 seem more likely
to appear in common cases, so my preference is #1. What
do others think?

--
to unsubscribe send a message 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, 25 Apr 2005 03:25:17 +0000
Date: Mon, 25 Apr 2005 06:24:37 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
Subject: Issue: 2486bis internationalization and unassigned codepoints

At IETF-62, this presentation outlined the i18n issue:

http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext_nai.ppt

Subproblems 1 and 2 are OK. Subproblems 3 and 4 are still open.

3 is really about what to do with unassigned codepoints. My current
thinking is that  a username with a particular character X will not be 
entered
into the Radius server's database unless X is supported the
Unicode and software versions of the server's admin UI.
The same for the client end and user's UI. Therefore, I think
what we need to say is that the all the i18n mapping and
checking operations happen only at the client (when entering
a NAI), and when entering this particular user's subscription
at the server side. And nothing in between should do this
under normal circumstances, they should just be passing
bytes along, not checking whether those bytes form unassigned
or assigned code points.  This ensures that an old proxy doesn't
prevent your new username from being used.

Does this work for everyone?

--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: Sat, 23 Apr 2005 02:33:39 +0000
Date: Fri, 22 Apr 2005 19:33:09 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 83: CUI and re-authentication

Issue 83: CUI and re-authentication
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 22, 2005
Reference:
Document: CUI-04
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

The document does not state how CUI is used with an Access-Request that
occurs due to re-authentication.  For example, in the original
authentication, the CUI attribute was provided within the Access-Accept,
and subsequently within Accounting-Request packets (interim).  Let us
assume that a Session-Timeout attribute was sent with
Termination-Action=RADIUS.

What happens at the expiration of the Session-Timeout value?  Does the NAS
send an Access-Request containing a CUI attribute to the RADIUS server
with the currently used CUI, or does it send an empty CUI attribute?  It
seems more appropriate for it to send the currently used CUI, since that
does not require the RADIUS server to keep state.  I presume
that the User-Name and EAP re-authentication elements are handled the same
way (e.g. User-Name includes "@realm" privacy NAI).

--
to unsubscribe send a message 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, 22 Apr 2005 15:25:25 +0000
Date: Fri, 22 Apr 2005 08:25:05 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Julien Bournelle <[email-masked]>
cc: "Nelson, David" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party

>  I'm wondering if an operator will let its EAP authenticator directly
>  contact EAP server from other operators using redirect functionality of
>  Diameter.

As I understand it, proxy bypass is being considered by TERENA primarily
to eliminate excessive latency in trans-continental roaming.  More info on
the "trust fabric" of EduRoam NG is available here:

http://www.terena.nl/tech/task-forces/tf-mobility/
http://www.eduroam.org/docs/eduroam-article.pdf
http://www.eduroam.org/wiki/NextGeneration?v=ina
http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf
http://www.es.net/raf/ESnet-RAF-WP.html

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

Delivery-date: Fri, 22 Apr 2005 14:53:13 +0000
Date: Fri, 22 Apr 2005 07:52:58 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Thierry Moreau <[email-masked]>
cc: "Blumenthal, Uri" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party

> Is it concievable to design end-to-end security (i.e. from NAS to RADIUS
> server through any intermediate RADIUS proxies) with an
> implementation-specific attribute to the RADIUS Access-Accept packet?

Diameter CMS enabled the creation of attributes that could be sent between
the RADIUS server and NAS without being revealed to an intermediate proxy.
Therefore it could be said that it enabled "end-to-end" trust, something
that was already possible within Diameter in other ways (re-direct).
Since re-direct needed to be supported anyway and also solved the
problem, that was the direction that was taken once it became clear
that there was not enough interest in Diameter CMS to continue the
work.

Note that Re-direct-based trust is built on the following elements:

    1. Support for DNS discovery of RADIUS servers within a domain.
       This allows the RADIUS client to discover which RADIUS server
       it needs to talk to.

    2. Support for certificate-based authentication.  For inter-domain
       purposes, this is handled via TLS within Diameter.  This
       allows a Diameter client to contact an arbitrary Diameter server
       and mutually authenticate to it, provided that the certificate
       chain can be validated.  With TLS it is possible to create
       application-specific trust chains, something that is much more
       difficult within IKE, so that the trust anchor for Diameter
       (e.g. certificates signed by a roaming consortium CA) need
       not be the same as for other applications (e.g. Verisign
       certificate for a Web server).

It is conceivable to add support for both of these elements to RADIUS, but
of these, element #2 is more difficult. RADIUS over IPsec is defined in
RFC 3579, but it is not deployed for inter-domain usage. To address the
limitations, RADIUS over TLS (RADSEC) has now been defined and is shipping.
My understanding is that it is being considered for deployment within large
inter-continental roaming networks (e.g. TERENA).  More info on RADSEC is
available here:

http://www.terena.nl/mail-archives/mobility/msg01225.html
http://www.open.com.au/radiator/radsec-whitepaper.pdf

> This requires a pre-shared secret key between the RADIUS server (or more
> precisely an implementation-specific server co-located with the RADIUS
> server) and the application-specific component co-located with the
> RADIUS NAS.

Are you proposing creating a new RADIUS security model that would only be
used by ISMS?  That seems like a lot of work for little overall benefit
to the RADIUS community.

> The security implication of RADIUS proxies has been noticed in isms
> mailing list early on. Perhaps it has been overlooked at some point in
> the discussion.

Rather than designing a new version of RADIUS to meet its needs, it seems
more profitable for ISMS to either figure out how to use the protocol as
it exists today, or to summarize its requirements for new work and ask
that it be chartered outside of ISMS.

--
to unsubscribe send a message 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, 22 Apr 2005 14:34:08 +0000
Content-class: urn:content-classes:message
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Fri, 22 Apr 2005 10:33:02 -0400
From: "Nelson, David" <[email-masked]>
To: "John Vollbrecht" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

John Vollbrecht writes ... [mailto:[email-masked]]
> The question I am wondering about is whether the RADIUS server could
be
> a trusted third party if it is directly connected to the NAS.  In that
> case it has credentials with all parties.  However the credentials are
> of quite different form - I am wondering if the form of credentials or
> the relationship between the credentials makes a difference in whether
> it can act effectively as a trusted third party.  My first guess  is
> that it could (especially if RADIUS had stronger hashing) but I am not
> sure.
> What is your thought?

I suspect there are cases in which a single (non-proxy) RADIUS server
could act as a trusted third party, but that would depend on the extent
to which the RADIUS server and the EAP server were considered a single
entity.  I think the issue is whether all parties can [directly]
validate the bindings of authenticated identity to keys. When one set of
bindings is created via the EAP session between the EAP peer and EAP
server and another set of bindings is created via the RADIUS
authentication and authorization exchanges between the RADIUS server and
the NAS, there is certainly the opportunity for the parties to have
disjoint sets of key bindings.

--
to unsubscribe send a message 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, 22 Apr 2005 04:51:51 +0000
Date: Thu, 21 Apr 2005 21:51:29 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Blumenthal, Uri" <[email-masked]>
cc: "Nelson, David" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

> Yet NAS takes "go/no-go" decision from RADIUS, and takes the keys to
> talk to the client... If this is not trust - what is it?

There is no IETF standard defining how keys are provided within
RADIUS for exactly that reason -- there is no trust relationship defined
when a proxy is present.  The "Housley Criteria" described in RFC 4017 do
not allow disclosure of keys to additional parties.

The problem does not exist in Diameter EAP, which enables keys to
be provided directly without access by proxies.

--
to unsubscribe send a message 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, 22 Apr 2005 03:00:59 +0000
Date: Thu, 21 Apr 2005 19:59:46 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

> I think there is a subtle difference between a "trusted third party" and
> a RADIUS server which may have bi-lateral trust relationships with
> various parties.

Yes.  Where RADIUS proxies are present there is no trust relationship
between the NAS and RADIUS server.  This is in contrast to Diameter, where
such a relationship can be established via re-direct.

The distinction is important in a number of cases.  In Kerberos, the KDC
is able to provide a ticket to any principal because it has a shared
secret that it shares with that principle.

Within RADIUS this is not possible.  A RADIUS server cannot
provide the user with a ticket to a NAS because it may not have a trust
relationship with that NAS.

Note that at one point, there was a proposal for integration of RADIUS
with Kerberos.  That proposal did in fact enable RADIUS to become a true
trusted third party.  The proposal seemed practical. However, the AAA WG
went with another proposal (Diameter CMS) which it turned out that noone
wanted to implement. Among other things, the proposal enabled a RADIUS
server to send a key to a NAS that could not be viewed by intervening
proxies.  In retrospect, the IETF may have missed an important
opportunity.

For a trip down memory lane, look here:
http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.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: Thu, 21 Apr 2005 18:32:24 +0000
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, John Vollbrecht <[email-masked]>
From: John Vollbrecht <[email-masked]>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 14:31:31 -0400
To: "Nelson, David" <[email-masked]>

Nice explanation David.  I have clarifying question below -

On Apr 21, 2005, at 11:37 AM, Nelson, David wrote:

> Apler Yegin writes...
>
>> I guess the AAA protocol that runs between the NAS and AAA server is a
>> "wire" as you said, but the AAA server is the trusted third party.
> Does
>> this make sense?
>
> I think there is a subtle difference between a "trusted third party" 
> and
> a RADIUS server which may have bi-lateral trust relationships with
> various parties.  The RADIUS server will always have a trust
> relationship with its enrolled Radius clients, via the shared secret.
> Those clients may be NASes or they may be RADIUS proxy servers.  RADIUS
> trust is always hop-by-hop.
>
> Strictly speaking, the RADIUS server has a trust relationship with the
> human user only when the native RADIUS password database is used as the
> source of authentication credentials.  Most often, the RADIUS server
> relies on some other authentication service (e.g. Active Directory,
> LDAP, NIS, etc.).  One tends to think of this as a single entity, and
> for certain purposes this is fine.  For other purposes, we need to
> retain the distinction.
>
> The host (e.g. via a machine certificate) may also have a trust
> relationship, but once again this relationship is typically with an EAP
> server "attached" to the Radius server, which may in turn rely on other
> authentication services.
The question I am wondering about is whether the RADIUS server could be 
a  trusted third party if it is directly connected to the NAS.  In that 
case it has credentials with all parties.  However the credentials are 
of quite different form - I am wondering if the form of credentials or 
the relationship between the credentials makes a difference in whether 
it can act effectively as a trusted third party.  My first guess  is 
that it could (especially if RADIUS had stronger hashing) but I am not 
sure.
What is your thought?

> A more typical example of a "trusted third party" is a Kerberos KDC
> which does in fact directly share credentials with all enrolled
> principals (human users, hosts or applications).
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>
>

--
to unsubscribe send a message 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, 21 Apr 2005 15:38:56 +0000
Content-class: urn:content-classes:message
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 11:37:31 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Apler Yegin writes...

> I guess the AAA protocol that runs between the NAS and AAA server is a
> "wire" as you said, but the AAA server is the trusted third party.
Does
> this make sense?

I think there is a subtle difference between a "trusted third party" and
a RADIUS server which may have bi-lateral trust relationships with
various parties.  The RADIUS server will always have a trust
relationship with its enrolled Radius clients, via the shared secret.
Those clients may be NASes or they may be RADIUS proxy servers.  RADIUS
trust is always hop-by-hop.

Strictly speaking, the RADIUS server has a trust relationship with the
human user only when the native RADIUS password database is used as the
source of authentication credentials.  Most often, the RADIUS server
relies on some other authentication service (e.g. Active Directory,
LDAP, NIS, etc.).  One tends to think of this as a single entity, and
for certain purposes this is fine.  For other purposes, we need to
retain the distinction.

The host (e.g. via a machine certificate) may also have a trust
relationship, but once again this relationship is typically with an EAP
server "attached" to the Radius server, which may in turn rely on other
authentication services.

A more typical example of a "trusted third party" is a Kerberos KDC
which does in fact directly share credentials with all enrolled
principals (human users, hosts or applications).

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

Delivery-date: Thu, 21 Apr 2005 04:57:47 +0000
Date: Wed, 20 Apr 2005 21:57:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Reminder to draft authors and editors: new boilerplate

Dear WG,

Just as a reminder, there's new boilerplate available for the
updated BCP 78 and 79 about IETF rights in contributions and
IPR considerations

Please make sure that you're familiar with the new versions,
and start to use the new boilerplate.

The new format will be mandatory next month sometime, so please
start preparing for the changes now, as you get ready to submit
new drafts of documents.

If you're using xml2rfc, there's a new version of the tool which
provides this now (1.29).

http://xml.resource.org/

--
to unsubscribe send a message 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, 20 Apr 2005 17:11:16 +0000
Content-class: urn:content-classes:message
Subject: RE : [RADIUS location attributes] support of a location identifier in location-information attribute
Date: Wed, 20 Apr 2005 19:10:33 +0200
From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
To: "Tschofenig Hannes" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Hannes,

I precise that it would be not necessary to define the exact format of =
the information contained in the Location-Info field. By manual =
configuration, the sender will know how to fill this field and the =
receiver will know how to process the received information. I insist on =
the fact that such a mechanism would be useful between a NAS and a =
RADIUS server from the same administrative domain if the RADIUS client =
was not able to provide explicit location  information, that is likely =
to be frequent ;)

BR,

Lionel

> -----Message d'origine-----
> De : Tschofenig Hannes [mailto:[email-masked]]=20
> Envoy=E9 : lundi 18 avril 2005 12:22
> =C0 : MORAND Lionel RD-CORE-ISS; [email-masked]
> Cc : [email-masked]
> Objet : AW: [RADIUS location attributes] support of a=20
> location identifier in location-information attribute
>=20
>=20
> hi lionel,=20
>=20
> i remember that you have proposed this feature already once.=20
>=20
> is someone else in favor of this approach?=20
> i don't want to add new functionality based the opinion of a=20
> few individuals only (particularly if the functionality is=20
> not really necessary).
>=20
> ciao
> hannes
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: MORAND Lionel RD-CORE-ISS
> > [mailto:[email-masked]]=20
> > Gesendet: Montag, 18. April 2005 10:34
> > An: Tschofenig Hannes; [email-masked]
> > Cc: [email-masked]
> > Betreff: [RADIUS location attributes] support of a location=20
> > identifier in location-information attribute
> >=20
> >=20
> > Hi Hannes,
> >=20
> > The actuel design of the location-information attribute
> > allows to convey
> > location objects as defined by GEOPRIV, either civic or geospatial
> > location information.
> > I agree that this fulfil the GEOPRIV requirements but what=20
> about some
> > "location ID" that could be sent to the AAA server to=20
> > retrieve location
> > info? I mean that the location info attribute may convey=20
> > either explicit
> > ("self-explicit") location information or any identifier if=20
> there is a
> > mean for the receiver to extract explicit information from=20
> > this ID, such
> > as the CellID in GSM.=20
> > Moreover, it could be seen as a complement of the global design:
> > 1)if the NAS is not able to provide an explicit location,=20
> the NAS can
> > provide the local RADIUS server with the location ID (any identifier
> > related to the access network) in the location-information=20
> attribute;
> > 2)the local RADIUS server performs the mapping between=20
> identifier and
> > location;
> > 3)the local server inserts the extracted information in a new
> > location-information attribute in the Access-Request sent to=20
> > the remote
> > RADIUS server.
> >=20
> > It is therefore proposed to allocate a new code value (2),=20
> defined for=20
> > location identifiers carried in location-information attributes.
> >=20
> > Lionel
> >=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, 20 Apr 2005 01:05:20 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Martin Soukup'" <[email-masked]>, "'Alper Yegin'" <[email-masked]>, "'Tschofenig Hannes'" <[email-masked]>, "'Sam Hartman'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 19 Apr 2005 18:05:08 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0105_01C5450A.536B7D30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I definitely look at RADIUS as a trusted third party:=20

Parties involved:=20

- authenticating entity (user/application)=20
- authenticator/policy enforcement point (device)=20
- authoritative authentication source/policy decision point (RADIUS)

In order for a "trusted third party" in the technical sense to
exist, the other two parties need to a) know about its existence and
b) trust it.  Does the "authenticating entity" know about the RADIUS
server? =20

Martin.=20

> -----Original Message-----=20
> From: Alper Yegin [mailto:[email-masked]]=20
> Sent: April 19, 2005 8:29 PM=20
> To: [email-masked]; 'Tschofenig Hannes'; 'Sam Hartman';=20
> Soukup, Martin [CAR:5K50:EXCH]=20
> Cc: [email-masked]; [email-masked]; [email-masked]=20
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party=20
>=20
>=20
> Glen,=20
>=20
> > > what is radius for you? (you write that it is not a trusted
third=20
> > > party.)=20
> >=20
> > It's not.  From the point of view of authentication protocols
(PAP,=20
> > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":=20
>=20
> What happens when we look at this picture from the=20
> "authorization" perspective? "Host-to-NAS authorization for=20
> the network access service" is dynamically generated from=20
> "host-to-AAA server" authorization and "AAA server to client=20
> (NAS)" authorization. Wouldn't this constitute a 3-party model?=20
>=20
> Alper=20
>=20
>=20
> > the=20
> > operation of the auth protocols should be exactly the same=20
> as if they=20
> > terminated in the AAA client, instead of elsewhere.  Basically,
the=20
> > purpose of AAA (again, from the POV of an authentication=20
> > protocol) is simply scaling.  BTW, a lot of misery has been=20
> caused by=20
> > the erroneous belief that EAP is (or can be) a three-party=20
> > authentication protocol: it isn't, and can't be.  It could=20
> _carry_ a=20
> > three-party protocol (like Kerberos), but EAP in itself is=20
> a two-party=20
> > protocol.=20
> >=20
> > > why do you care that only one party knows that radius is used?
it=20
> > > could also be diameter.=20
> > >=20
> > > i would like to better understand why some people dislike the
aaa=20
> > > architecture (radius, diameter).=20
> >=20
> > I think that the misunderstanding mentioned above might=20
> have something=20
> > to do with it...=20
> >=20
> > >=20
> > > ciao=20
> > > hannes=20
> > >=20
> > >=20
> > >> -----Urspr=FCngliche Nachricht-----=20
> > >> Von: [email-masked]=20
> > >> [mailto:[email-masked]] Im Auftrag von Sam
Hartman=20
> > >> Gesendet: Freitag, 15. April 2005 19:34=20
> > >> An: Martin Soukup=20
> > >> Cc: [email-masked]=20
> > >> Betreff: [Isms] RADIUS is not a trusted third party=20
> > >>=20
> > >>=20
> > >>>>>>> "Martin" =3D=3D Martin Soukup <[email-masked]> writes:=20
> > >>=20
> > >>     Martin> RADIUS "Access-Accept" indicates a successful=20
> > >>     Martin> authenthentication response for a user.=20
> > >>=20
> > >>     Martin> The Access-Accept already returns a=20
> > "Session-Timeout",=20
> > >>     Martin> defined as "Sets the maximum number of seconds of

> > service=20
> > >>     Martin> to be provided to the user before the session=20
> > >>     Martin> terminates. This attribute value becomes the
per-user=20
> > >>     Martin> "absolute timeout."".=20
> > >>=20
> > >> This only tells the SNMP engine talking to the RADIUS server
the=20
> > >> timeout.  You need to tell the other side of the exchange the

> > >> timeout too.=20
> > >>=20
> > >> Remember that RADIUS is a callout service; it is not a
trusted=20
> > third=20
> > >> party.  In other words, in a particular SNMP authentication,
only=20
> > one=20
> > >> of the parties will know that RADIUS is being used.=20
> > >>=20
> > >>=20
> > >> _______________________________________________=20
> > >> Isms mailing list=20
> > >> [email-masked]
https://www1.ietf.org/mailman/listinfo/isms=20
> > >>=20
> > >=20
> > > _______________________________________________=20
> > > Isms mailing list=20
> > > [email-masked]
https://www1.ietf.org/mailman/listinfo/isms=20
> >=20
> > Hope this helps,=20
> >=20
> > ~gwz=20
> >=20
> > Why is it that most of the world's problems can't be solved=20
> by simply=20
> >   listening to John Coltrane? -- Henry Gabriel=20
> > _______________________________________________=20
> > eap mailing list=20
> > [email-masked]=20
> > http://mail.frascone.com/mailman/listinfo/eap=20
>=20
>=20
>=20
>=20

------=_NextPart_000_0105_01C5450A.536B7D30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [eap] RE: [Isms] RADIUS is not a trusted third =
party</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DISO-8859-1">
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2>I definitely look at RADIUS =
as a trusted=20
third party:</FONT> </DIV>
<P><FONT size=3D2>Parties involved:</FONT> </P>
<P><FONT size=3D2>- authenticating entity (user/application)</FONT> =
<BR><FONT=20
size=3D2>- authenticator/policy enforcement point (device)</FONT> =
<BR><FONT=20
size=3D2>- authoritative authentication source/policy decision point=20
(RADIUS)</FONT>&nbsp;<SPAN class=3D877425900-20042005><FONT face=3DArial =

color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
<P><SPAN class=3D877425900-20042005><FONT face=3DArial color=3D#0000ff =
size=3D2>In order=20
for a "trusted third party" in the technical sense to exist, the other =
two=20
parties need to a) know about&nbsp;its existence and b) trust it.&nbsp; =
Does the=20
"authenticating entity"</FONT>&nbsp;<FONT face=3DArial color=3D#0000ff =
size=3D2>know=20
about the RADIUS server?&nbsp; </FONT></SPAN></P>
<P><FONT size=3D2>Martin.</FONT> </P>
<P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
From: Alper Yegin [<A=20
href=3D"mailto:[email-masked]">mailto:[email-masked]</A=
>]=20
</FONT><BR><FONT size=3D2>&gt; Sent: April 19, 2005 8:29 PM</FONT> =
<BR><FONT=20
size=3D2>&gt; To: [email-masked]; 'Tschofenig Hannes'; 'Sam Hartman';=20
</FONT><BR><FONT size=3D2>&gt; Soukup, Martin [CAR:5K50:EXCH]</FONT> =
<BR><FONT=20
size=3D2>&gt; Cc: [email-masked]; [email-masked]; =
[email-masked]</FONT>=20
<BR><FONT size=3D2>&gt; Subject: RE: [eap] RE: [Isms] RADIUS is not a =
trusted=20
third party</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Glen,</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
size=3D2>&gt; &gt; &gt; what is radius for you? (you write that it is =
not a=20
trusted third</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; party.)</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; It's not.&nbsp; =
>From the=20
point of view of authentication protocols (PAP, </FONT><BR><FONT =
size=3D2>&gt;=20
&gt; CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":</FONT> =

<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; What happens when =
we look at=20
this picture from the </FONT><BR><FONT size=3D2>&gt; "authorization" =
perspective?=20
"Host-to-NAS authorization for </FONT><BR><FONT size=3D2>&gt; the =
network access=20
service" is dynamically generated from </FONT><BR><FONT size=3D2>&gt; =
"host-to-AAA=20
server" authorization and "AAA server to client </FONT><BR><FONT =
size=3D2>&gt;=20
(NAS)" authorization. Wouldn't this constitute a 3-party model?</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Alper</FONT> <BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
the</FONT>=20
<BR><FONT size=3D2>&gt; &gt; operation of the auth protocols should be =
exactly the=20
same </FONT><BR><FONT size=3D2>&gt; as if they </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
terminated in the AAA client, instead of elsewhere.&nbsp; Basically, the =

</FONT><BR><FONT size=3D2>&gt; &gt; purpose of AAA (again, from the POV =
of an=20
authentication</FONT> <BR><FONT size=3D2>&gt; &gt; protocol) is simply=20
scaling.&nbsp; BTW, a lot of misery has been </FONT><BR><FONT =
size=3D2>&gt; caused=20
by </FONT><BR><FONT size=3D2>&gt; &gt; the erroneous belief that EAP is =
(or can=20
be) a three-party </FONT><BR><FONT size=3D2>&gt; &gt; authentication =
protocol: it=20
isn't, and can't be.&nbsp; It could </FONT><BR><FONT size=3D2>&gt; =
_carry_ a=20
</FONT><BR><FONT size=3D2>&gt; &gt; three-party protocol (like =
Kerberos), but EAP=20
in itself is </FONT><BR><FONT size=3D2>&gt; a two-party </FONT><BR><FONT =

size=3D2>&gt; &gt; protocol.</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
size=3D2>&gt; &gt; &gt; why do you care that only one party knows that =
radius is=20
used? it </FONT><BR><FONT size=3D2>&gt; &gt; &gt; could also be =
diameter.</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt; i would=20
like to better understand why some people dislike the aaa =
</FONT><BR><FONT=20
size=3D2>&gt; &gt; &gt; architecture (radius, diameter).</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; I think that the=20
misunderstanding mentioned above might </FONT><BR><FONT size=3D2>&gt; =
have=20
something </FONT><BR><FONT size=3D2>&gt; &gt; to do with it...</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt; ciao</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
hannes</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt; -----Urspr=FCngliche =
Nachricht-----</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt; Von: [email-masked]=20
</FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; [<A=20
href=3D"mailto:[email-masked]">mailto:[email-masked]=
f.org</A>]=20
Im Auftrag von Sam Hartman</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =
Gesendet:=20
Freitag, 15. April 2005 19:34</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt; An:=20
Martin Soukup</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; Cc:=20
[email-masked]</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; Betreff: =
[Isms] RADIUS=20
is not a trusted third party</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
&gt;&gt;&gt;&gt;&gt;&gt;&gt; "Martin" =3D=3D Martin Soukup=20
&lt;[email-masked]&gt; writes:</FONT> <BR><FONT size=3D2>&gt; &gt;=20
&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
Martin&gt; RADIUS "Access-Accept" indicates a successful</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
authenthentication=20
response for a user.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; The =
Access-Accept=20
already returns a</FONT> <BR><FONT size=3D2>&gt; &gt; =
"Session-Timeout",</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
defined=20
as "Sets the maximum number of seconds of</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
service</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
Martin&gt; to be provided to the user before the session</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
terminates. This=20
attribute value becomes the per-user</FONT> <BR><FONT size=3D2>&gt; &gt; =

&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; "absolute timeout."".</FONT> =

<BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;&gt;=20
This only tells the SNMP engine talking to the RADIUS server the=20
</FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; timeout.&nbsp; You need to =
tell the=20
other side of the exchange the </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
timeout too.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt; Remember that RADIUS is a callout service; =
it is not a=20
trusted</FONT> <BR><FONT size=3D2>&gt; &gt; third</FONT> <BR><FONT =
size=3D2>&gt;=20
&gt; &gt;&gt; party.&nbsp; In other words, in a particular SNMP =
authentication,=20
only</FONT> <BR><FONT size=3D2>&gt; &gt; one</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
&gt;&gt; of the parties will know that RADIUS is being used.</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
&gt; &gt;&gt; Isms mailing list</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
[email-masked] <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
&gt; &gt; Isms mailing list</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;=20
[email-masked] <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hope this =
helps,</FONT>=20
<BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
~gwz</FONT>=20
<BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Why is =
it that most=20
of the world's problems can't be solved </FONT><BR><FONT size=3D2>&gt; =
by=20
simply</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; listening to John =
Coltrane?=20
-- Henry Gabriel</FONT> <BR><FONT size=3D2>&gt; &gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
&gt; eap mailing list</FONT> <BR><FONT size=3D2>&gt; &gt; =
[email-masked]</FONT>=20
<BR><FONT size=3D2>&gt; &gt; <A=20
href=3D"http://mail.frascone.com/mailman/listinfo/eap"=20
target=3D_blank>http://mail.frascone.com/mailman/listinfo/eap</A></FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; </FONT></P></BODY></HTML>

------=_NextPart_000_0105_01C5450A.536B7D30--

--
to unsubscribe send a message 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, 20 Apr 2005 00:58:14 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Alper Yegin'" <[email-masked]>, "'Tschofenig Hannes'" <[email-masked]>, "'Sam Hartman'" <[email-masked]>, "'Martin Soukup'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 19 Apr 2005 17:57:42 -0700

Alper Yegin <> supposedly scribbled:

> Glen,
>=20
>>> what is radius for you? (you write that it is not a trusted
third
>>> party.)
>>=20
>> It's not.  From the point of view of authentication protocols
(PAP,
>> CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":
>=20
> What happens when we look at this picture from the "authorization"
> perspective? "Host-to-NAS authorization for the network access
> service"=20
> is dynamically generated from "host-to-AAA server" authorization
and
> "AAA server to client (NAS)" authorization. Wouldn't this
constitute
> a 3-party model?=20

I'm pretty sure that both Sam & I were just talking about
authentication.  In any case, could you expound a bit?  I don't
actually know what you're talking about.  What do "Host-to-NAS
authorization for the network access service", "host-to-AAA server
authorization" and "AAA server to client (NAS) authorization" mean?
Are you saying that somehow the host authorizes the NAS to provide
it network access?

>=20
> Alper
>=20
>=20
>> the
>> operation of the auth protocols should be exactly the same as if
they
>> terminated in the AAA client, instead of elsewhere.  Basically,
the
>> purpose of AAA (again, from the POV of an authentication
>> protocol) is simply scaling.  BTW, a lot of misery has been
caused by
>> the erroneous belief that EAP is (or can be) a three-party
>> authentication protocol: it isn't, and can't be.  It could
_carry_ a
>> three-party protocol (like Kerberos), but EAP in itself is a
>> two-party protocol.=20
>>=20
>>> why do you care that only one party knows that radius is used?
it
>>> could also be diameter.=20
>>>=20
>>> i would like to better understand why some people dislike the
aaa
>>> architecture (radius, diameter).
>>=20
>> I think that the misunderstanding mentioned above might have
>> something to do with it...=20
>>=20
>>>=20
>>> ciao
>>> hannes
>>>=20
>>>=20
>>>> -----Urspr=FCngliche Nachricht-----
>>>> Von: [email-masked]
>>>> [mailto:[email-masked]] Im Auftrag von Sam Hartman
>>>> Gesendet: Freitag, 15. April 2005 19:34
>>>> An: Martin Soukup
>>>> Cc: [email-masked]
>>>> Betreff: [Isms] RADIUS is not a trusted third party
>>>>=20
>>>>=20
>>>>>>>>> "Martin" =3D=3D Martin Soukup <[email-masked]> writes:
>>>>=20
>>>>     Martin> RADIUS "Access-Accept" indicates a successful
>>>>     Martin> authenthentication response for a user.
>>>>=20
>>>>     Martin> The Access-Accept already returns a
"Session-Timeout",
>>>>     Martin> defined as "Sets the maximum number of seconds of
>>>>     service Martin> to be provided to the user before the
session
>>>>     Martin> terminates. This attribute value becomes the
per-user
>>>>     Martin> "absolute timeout."".
>>>>=20
>>>> This only tells the SNMP engine talking to the RADIUS server
the
>>>> timeout.  You need to tell the other side of the exchange the
>>>> timeout too.=20
>>>>=20
>>>> Remember that RADIUS is a callout service; it is not a trusted
>>>> third party.  In other words, in a particular SNMP
authentication,
>>>> only one of the parties will know that RADIUS is being used.
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Isms mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/isms
>>>>=20
>>>=20
>>> _______________________________________________
>>> Isms mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/isms
>>=20
>> Hope this helps,
>>=20
>> ~gwz
>>=20
>> Why is it that most of the world's problems can't be solved by
simply
>>   listening to John Coltrane? -- Henry Gabriel
>> _______________________________________________
>> eap mailing list
>> [email-masked]
>> http://mail.frascone.com/mailman/listinfo/eap
>=20
>=20
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

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, 19 Apr 2005 09:01:49 +0000
Content-class: urn:content-classes:message
Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter
Date: Tue, 19 Apr 2005 11:34:43 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C544BA.A3077A2F
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

So, a few points:
=20
This draft should say that because Diameter Base inherits the RADIUS =
code space, this is applicable
for Diameter.  Section 4.1 of RFC 3588 says:
   AVP Code

      The AVP Code, combined with the Vendor-Id field, identifies the

      attribute uniquely.  AVP numbers 1 through 255 are reserved for

      backward compatibility with RADIUS, without setting the Vendor-Id

      field.  AVP numbers 256 and above are used for Diameter, which are

      allocated by IANA (see Section 11.1).
Maybe some text should be added so readers know that. =20
Some text about using NASREQ for protocol translation could be added, in =
addition to what is there already.
Additionally, I think that the IANA considerations should also request =
that IANA update the Diameter registry
with this info as well.
John

 -----Original Message-----
From: ext [mailto:[email-masked]]
Sent: 18 April, 2005 14:16
To: Loughney John (Nokia-NRC/Helsinki); [email-masked]; =
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in =
Diameter

Hi John, Lionel & Jari,

I would assume that the concerns are because in 3GPP we do also
have the Diameter-Diameter case without any translation. The text
below and the draft does not address that case.

Cheers,
       Jouni

-----Original Message-----
From:   [email-masked] on behalf of =
[email-masked]
Sent:   Mon 4/18/2005 1:42 PM
To:     [email-masked]; [email-masked]
Cc:     [email-masked]; [email-masked]
Subject:        RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes =
in Diameter
Hi Lionel,

> The following statement is not enough?
>
> 8.  Diameter RADIUS Interoperability
>
>    In deployments where RADIUS clients talk with DIAMETER servers or
>    DIAMETER clients talk with RADIUS servers then a translation agent
>    will be deployed and operate in accordance to the NASREQ
>    specification [14].

That was what I was wondering.  Some of the people who queried me about =
this
thought it wasn't enough; that's why I am checking with the rest of the
WG.

John

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

------_=_NextPart_001_01C544BA.A3077A2F
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<TITLE>RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in =
Diameter</TITLE>

<META content=3D"MSHTML 6.00.2800.1499" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D591362808-19042005><FONT face=3DArial color=3D#0000ff =
size=3D2>So, a=20
few points:</FONT></SPAN></DIV>
<DIV><SPAN class=3D591362808-19042005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D591362808-19042005><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
draft should say that because Diameter Base inherits the RADIUS code =
space, this=20
is applicable</FONT></SPAN></DIV>
<DIV><SPAN class=3D591362808-19042005><FONT face=3DArial color=3D#0000ff =
size=3D2>for=20
Diameter.&nbsp; Section 4.1 of RFC 3588 says:</FONT></SPAN><SPAN=20
class=3D591362808-19042005></DIV>
<DIV><PRE>   AVP Code
      The AVP Code, combined with the Vendor-Id field, identifies the
      attribute uniquely.  AVP numbers 1 through 255 are reserved for
      backward compatibility with RADIUS, without setting the Vendor-Id
      field.  AVP numbers 256 and above are used for Diameter, which are
      allocated by IANA (see Section 11.1)<SPAN =
class=3D591362808-19042005>.</SPAN></PRE><PRE></SPAN><FONT =
face=3DTahoma><SPAN class=3D591362808-19042005><FONT face=3DArial><SPAN =
class=3D591362808-19042005><FONT face=3DArial color=3D#0000ff =
size=3D2>Maybe some text should be added so readers know that.  =
</FONT></SPAN></FONT></SPAN></FONT></PRE><PRE><FONT face=3DTahoma><SPAN =
class=3D591362808-19042005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN class=3D591362808-19042005>Some text about using NASREQ =
for protocol translation could be added, in addition to what is there =
already.</SPAN></FONT></SPAN></FONT></PRE><PRE><FONT face=3DTahoma><SPAN =
class=3D591362808-19042005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN class=3D591362808-19042005>Additionally, I think that the =
IANA considerations should also request that IANA update the Diameter =
registry<BR>with this info as =
well.</SPAN></FONT></SPAN></FONT></PRE><PRE><FONT face=3DTahoma><SPAN =
class=3D591362808-19042005><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN =
class=3D591362808-19042005>John</SPAN></FONT></SPAN></FONT></PRE></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
  size=3D2><SPAN class=3D591362808-19042005>&nbsp;</SPAN>-----Original=20
  Message-----<BR><B>From:</B> ext=20
  [mailto:[email-masked]]<BR><B>Sent:</B> 18 April, 2005 =

  14:16<BR><B>To:</B> Loughney John (Nokia-NRC/Helsinki);=20
  [email-masked]; [email-masked]<BR><B>Cc:</B>=20
  [email-masked]; [email-masked]<BR><B>Subject:</B> RE: RE : =
[AAA-WG]:=20
  Support for Geopriv RADIUS attributes in =
Diameter<BR><BR></DIV></FONT></FONT><!-- Converted from text/plain =
format -->
  <P><FONT size=3D2>Hi John, Lionel &amp; Jari,<BR><BR>I would assume =
that the=20
  concerns are because in 3GPP we do also<BR>have the Diameter-Diameter =
case=20
  without any translation. The text<BR>below and the draft does not =
address that=20
  case.<BR><BR>Cheers,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Jouni<BR><BR><BR>-----Original Message-----<BR>From:&nbsp;&nbsp;=20
  [email-masked] on behalf of=20
  [email-masked]<BR>Sent:&nbsp;&nbsp; Mon 4/18/2005 1:42=20
  PM<BR>To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked];=20
  [email-masked]<BR>Cc:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked];=20
  =
[email-masked]<BR>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
  RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in =
Diameter<BR>Hi=20
  Lionel,<BR><BR>&gt; The following statement is not =
enough?<BR>&gt;<BR>&gt;=20
  8.&nbsp; Diameter RADIUS =
Interoperability<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp; In=20
  deployments where RADIUS clients talk with DIAMETER servers=20
  or<BR>&gt;&nbsp;&nbsp;&nbsp; DIAMETER clients talk with RADIUS servers =
then a=20
  translation agent<BR>&gt;&nbsp;&nbsp;&nbsp; will be deployed and =
operate in=20
  accordance to the NASREQ<BR>&gt;&nbsp;&nbsp;&nbsp; specification=20
  [14].<BR><BR>That was what I was wondering.&nbsp; Some of the people =
who=20
  queried me about this<BR>thought it wasn't enough; that's why I am =
checking=20
  with the rest of the<BR>WG.<BR><BR>John<BR><BR>--<BR>to unsubscribe =
send a=20
  message to [email-masked] with<BR>the word =
'unsubscribe' in a=20
  single line as the message text body.<BR>archive: &lt;<A=20
  =
href=3D"http://psg.com/lists/radiusext/">http://psg.com/lists/radiusext/<=
/A>&gt;<BR></FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C544BA.A3077A2F--

--
to unsubscribe send a message 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, 18 Apr 2005 12:35:38 +0000
Content-class: urn:content-classes:message
Subject: RE : [RADIUS location attributes] Minor comment on Operator-type attribute
Date: Mon, 18 Apr 2005 14:35:00 +0200
From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Youni,

Yes of course! I just want to align the name of this attribute with the =
provided definition:

   Operator-Type:

         The Operator-Type field is four octets and identifies the
         namespace associated with the Operator-Name attribute.

It is then a namespace that is indicated in this attribute and not an =
operator type.
According to this proposal, I would propose the following revisions:

Change 1:
 5.1  Operator-Namespace Attribute

   This attribute identifies the namespace in which the
   operator name provided in the Operator-Name attribute is uniquely =
identified.
   The attribute value is a four octet integer.
   This document defines three values for this attribute:

   -	The value 1 (GSM), which 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 namespace.

   -	The value 2 (CDMA), which 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 namespace.

   -	The value 3 (REALM), which 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 =
namespace.

   Additional values require an IANA registration and MUST be associated =
with
   an organization responsible for assigning/managing the operator =
names.

Change 2:
 9.1  Operator-Namespace Attribute

   The Operator-Namespace attribute SHOULD be sent in Access-Request, =
and
   Accounting-Request packets where the Acc-Status-Type is set to Start,
   Interim, or Stop.  If this attribute is present, the Operator-Name
   attribute MUST also be present in the packet.

   A summary of the Operator-Type Attribute is shown below.

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type          | Length        |         Operator-Namespace
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Operator-Type (cont)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Type:
       To Be Assigned by IANA  - Operator-Namespace

     Length:
       6

     Operator-Namespace:

         The Operator-Namespace field is four octets and identifies the
         namespace associated with the Operator-Name attribute.

       #     Namespace
      ---    ---------
       1     GSM
       2     CDMA
       3     REALM

Change 3: Replace "Operator-Type" by "Operator-Namespace" in the whole =
text.

BR,

Lionel

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]]=20
> Envoy=E9 : lundi 18 avril 2005 13:54
> =C0 : MORAND Lionel RD-CORE-ISS; [email-masked];=20
> [email-masked]
> Cc : [email-masked]
> Objet : RE: [RADIUS location attributes] Minor comment on=20
> Operator-type attribute
>=20
>=20
>=20
> Lionel,
>=20
> Just for my clarification.. Your proposed change would still=20
> allow delegating the control and management of certain=20
> namespace to the some organization of choice e.g. to GSMA, right?
>=20
> Cheers,
>        Jouni
>=20
> -----Original Message-----
> From:	[email-masked] on behalf of MORAND Lionel=20
> RD-CORE-ISS
> Sent:	Mon 4/18/2005 11:45 AM
> To:	Hannes Tschofenig; [email-masked]
> Cc:	[email-masked]
> Subject:	[RADIUS location attributes] Minor comment on=20
> Operator-type attribute
> Hi Hannes,
>=20
> As explained during the last RADEXT meeting, I would prefer=20
> to remove the wording "Operator-Type" and replace by=20
> "Operator-Namespace". This attrbute doesn't define anymore=20
> the operator's type but in which namespace its name is=20
> defined. I wouldn't like to see any confusion between the=20
> name used by an operator (e.g. France Telecom) and the=20
> operator's type (ISP, telco, mobile, fixed, or whatever).
>=20
> Lionel
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20
>=20
>=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: Mon, 18 Apr 2005 11:54:02 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS location attributes] Minor comment on Operator-type attribute
Date: Mon, 18 Apr 2005 14:53:44 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Lionel,

Just for my clarification.. Your proposed change would still allow
delegating the control and management of certain namespace to the
some organization of choice e.g. to GSMA, right?

Cheers,
       Jouni

-----Original Message-----
From:	[email-masked] on behalf of MORAND Lionel =
RD-CORE-ISS
Sent:	Mon 4/18/2005 11:45 AM
To:	Hannes Tschofenig; [email-masked]
Cc:	[email-masked]
Subject:	[RADIUS location attributes] Minor comment on Operator-type =
attribute
Hi Hannes,

As explained during the last RADEXT meeting, I would prefer to remove
the wording "Operator-Type" and replace by "Operator-Namespace". This
attrbute doesn't define anymore the operator's type but in which
namespace its name is defined. I wouldn't like to see any confusion
between the name used by an operator (e.g. France Telecom) and the
operator's type (ISP, telco, mobile, fixed, or whatever).

Lionel

--
to unsubscribe send 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, 18 Apr 2005 11:16:14 +0000
Content-class: urn:content-classes:message
Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter
Date: Mon, 18 Apr 2005 14:15:49 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi John, Lionel & Jari,

I would assume that the concerns are because in 3GPP we do also
have the Diameter-Diameter case without any translation. The text
below and the draft does not address that case.

Cheers,
       Jouni

-----Original Message-----
From:	[email-masked] on behalf of [email-masked]
Sent:	Mon 4/18/2005 1:42 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in =
Diameter
Hi Lionel,

> The following statement is not enough?
>=20
> 8.  Diameter RADIUS Interoperability
>=20
>    In deployments where RADIUS clients talk with DIAMETER servers or
>    DIAMETER clients talk with RADIUS servers then a translation agent
>    will be deployed and operate in accordance to the NASREQ
>    specification [14].

That was what I was wondering.  Some of the people who queried me about =
this
thought it wasn't enough; that's why I am checking with the rest of the
WG.

John

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

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

Delivery-date: Mon, 18 Apr 2005 10:48:05 +0000
Content-class: urn:content-classes:message
Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter
Date: Mon, 18 Apr 2005 13:42:20 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Lionel,

> The following statement is not enough?
>=20
> 8.  Diameter RADIUS Interoperability
>=20
>    In deployments where RADIUS clients talk with DIAMETER servers or
>    DIAMETER clients talk with RADIUS servers then a translation agent
>    will be deployed and operate in accordance to the NASREQ
>    specification [14].

That was what I was wondering.  Some of the people who queried me about =
this
thought it wasn't enough; that's why I am checking with the rest of the
WG.

John

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

Delivery-date: Mon, 18 Apr 2005 10:37:22 +0000
Content-class: urn:content-classes:message
Subject: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter
Date: Mon, 18 Apr 2005 12:37:02 +0200
From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi John,

The following statement is not enough?

8.  Diameter RADIUS Interoperability

   In deployments where RADIUS clients talk with DIAMETER servers or
   DIAMETER clients talk with RADIUS servers then a translation agent
   will be deployed and operate in accordance to the NASREQ
   specification [14].

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> [email-masked]
> Envoy=E9 : lundi 18 avril 2005 12:24
> =C0 : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : RE: [AAA-WG]: Support for Geopriv RADIUS attributes=20
> in Diameter
>=20
>=20
> Hi Jari,
>=20
> > I'd prefer the NASREQ approach.
>=20
> I think that would be reasonable.  Do you think that this=20
> should be written-up=20
> anywhere?  Should I try to supply some text for the geopriv draft?
>=20
> John
>=20
> > [email-masked] wrote:
> >=20
> > >Hi all,
> > >
> > >I've gotten some queries, off-list, about how 3GPP should
> > handle the location
> > >AVPs that are defined in:
> > >
> > >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius
> > -lo-02.txt
> > >
> > >3GPP has defined the Wa interface, which is based on
> > Diameter, that will
> > >interwork with RADIUS and will carry the RADIUS AVPs. =20
> Would standard=20
> > >NASREQ rules apply here (Diameter would just re-use the
> > RADIUS codes), or
> > >should these AVPs also be defined in a seperate Diameter draft?
> > >
> > >The draft above is quite weak on how these attributes should
> > be handled
> > >in Diameter, so I wanted to see what both the AAA WG and RADEXT WG
> > >thought.
> > >
> > >John
> > >
> > > =20
> > >
> >=20
> >      =20
> >=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Mon, 18 Apr 2005 10:24:51 +0000
From: Tschofenig Hannes <[email-masked]>
To: MORAND Lionel RD-CORE-ISS <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: AW: [RADIUS location attributes] support of a location identifier in location-information attribute
Date: Mon, 18 Apr 2005 12:22:12 +0200

hi lionel,=20

i remember that you have proposed this feature already once.=20

is someone else in favor of this approach?=20
i don't want to add new functionality based the opinion of a few =
individuals
only (particularly if the functionality is not really necessary).

ciao
hannes

> -----Urspr=FCngliche Nachricht-----
> Von: MORAND Lionel RD-CORE-ISS=20
> [mailto:[email-masked]]=20
> Gesendet: Montag, 18. April 2005 10:34
> An: Tschofenig Hannes; [email-masked]
> Cc: [email-masked]
> Betreff: [RADIUS location attributes] support of a location=20
> identifier in location-information attribute
>=20
>=20
> Hi Hannes,
>=20
> The actuel design of the location-information attribute=20
> allows to convey
> location objects as defined by GEOPRIV, either civic or geospatial
> location information.
> I agree that this fulfil the GEOPRIV requirements but what about some
> "location ID" that could be sent to the AAA server to=20
> retrieve location
> info? I mean that the location info attribute may convey=20
> either explicit
> ("self-explicit") location information or any identifier if there is =
a
> mean for the receiver to extract explicit information from=20
> this ID, such
> as the CellID in GSM.=20
> Moreover, it could be seen as a complement of the global design:
> 1)if the NAS is not able to provide an explicit location, the NAS can
> provide the local RADIUS server with the location ID (any identifier
> related to the access network) in the location-information attribute;
> 2)the local RADIUS server performs the mapping between identifier and
> location;
> 3)the local server inserts the extracted information in a new
> location-information attribute in the Access-Request sent to=20
> the remote
> RADIUS server.
>=20
> It is therefore proposed to allocate a new code value (2), defined =
for
> location identifiers carried in location-information attributes.
>=20
> Lionel
>=20

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

Delivery-date: Mon, 18 Apr 2005 10:24:50 +0000
Content-class: urn:content-classes:message
Subject: RE: [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter
Date: Mon, 18 Apr 2005 13:23:48 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Jari,

> I'd prefer the NASREQ approach.

I think that would be reasonable.  Do you think that this should be =
written-up=20
anywhere?  Should I try to supply some text for the geopriv draft?

John

> [email-masked] wrote:
>=20
> >Hi all,
> >
> >I've gotten some queries, off-list, about how 3GPP should=20
> handle the location=20
> >AVPs that are defined in:
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius
> -lo-02.txt
> >
> >3GPP has defined the Wa interface, which is based on=20
> Diameter, that will
> >interwork with RADIUS and will carry the RADIUS AVPs.  Would standard
> >NASREQ rules apply here (Diameter would just re-use the=20
> RADIUS codes), or
> >should these AVPs also be defined in a seperate Diameter draft?
> >
> >The draft above is quite weak on how these attributes should=20
> be handled
> >in Diameter, so I wanted to see what both the AAA WG and RADEXT WG=20
> >thought.
> >
> >John
> >
> > =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: Mon, 18 Apr 2005 10:19:27 +0000
From: Tschofenig Hannes <[email-masked]>
To: MORAND Lionel RD-CORE-ISS <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: AW: [RADIUS location attributes] Minor comment on Operator-type a ttribute
Date: Mon, 18 Apr 2005 12:16:46 +0200

hi lionel, 

i like your proposal. thanks.

ciao
hannes

> Hi Hannes,
> 
> As explained during the last RADEXT meeting, I would prefer to remove
> the wording "Operator-Type" and replace by "Operator-Namespace". This
> attrbute doesn't define anymore the operator's type but in which
> namespace its name is defined. I wouldn't like to see any confusion
> between the name used by an operator (e.g. France Telecom) and the
> operator's type (ISP, telco, mobile, fixed, or whatever).
> 
> Lionel
> 

--
to unsubscribe send a message 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, 18 Apr 2005 10:10:33 +0000
Content-class: urn:content-classes:message
Subject: Support for Geopriv RADIUS attributes in Diameter
Date: Mon, 18 Apr 2005 13:05:49 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi all,

I've gotten some queries, off-list, about how 3GPP should handle the =
location=20
AVPs that are defined in:

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt

3GPP has defined the Wa interface, which is based on Diameter, that will
interwork with RADIUS and will carry the RADIUS AVPs.  Would standard
NASREQ rules apply here (Diameter would just re-use the RADIUS codes), =
or
should these AVPs also be defined in a seperate Diameter draft?

The draft above is quite weak on how these attributes should be handled
in Diameter, so I wanted to see what both the AAA WG and RADEXT WG=20
thought.

John

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

Delivery-date: Mon, 18 Apr 2005 08:45:48 +0000
Content-class: urn:content-classes:message
Subject:  [RADIUS location attributes] Minor comment on Operator-type attribute
Date: Mon, 18 Apr 2005 10:45:40 +0200
From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Hannes,

As explained during the last RADEXT meeting, I would prefer to remove
the wording "Operator-Type" and replace by "Operator-Namespace". This
attrbute doesn't define anymore the operator's type but in which
namespace its name is defined. I wouldn't like to see any confusion
between the name used by an operator (e.g. France Telecom) and the
operator's type (ISP, telco, mobile, fixed, or whatever).

Lionel

--
to unsubscribe send a message 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, 18 Apr 2005 08:34:26 +0000
Content-class: urn:content-classes:message
Subject: [RADIUS location attributes] support of a location identifier in location-information attribute
Date: Mon, 18 Apr 2005 10:33:34 +0200
From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Hannes,

The actuel design of the location-information attribute allows to convey
location objects as defined by GEOPRIV, either civic or geospatial
location information.
I agree that this fulfil the GEOPRIV requirements but 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.=20
Moreover, it could be seen as a complement of the global design:
1)if the NAS is not able to provide an explicit location, the NAS can
provide the local RADIUS server with the location ID (any identifier
related to the access network) in the location-information attribute;
2)the local RADIUS server performs the mapping between identifier and
location;
3)the local server inserts the extracted information in a new
location-information attribute in the Access-Request sent to the remote
RADIUS server.

It is therefore proposed to allocate a new code value (2), defined for
location identifiers carried in location-information attributes.

Lionel

--
to unsubscribe send a message 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, 17 Apr 2005 19:49:18 +0000
Date: Sun, 17 Apr 2005 12:48:55 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "'Tschofenig Hannes'" <[email-masked]>, "'Sam Hartman'" <[email-masked]>, "'Martin Soukup'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [Isms] RADIUS is not a trusted third party

> It's not.  From the point of view of authentication protocols (PAP,
> CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": the
> operation of the auth protocols should be exactly the same as if
> they terminated in the AAA client, instead of elsewhere.  Basically,
> the purpose of AAA (again, from the POV of an authentication
> protocol) is simply scaling.  BTW, a lot of misery has been caused
> by the erroneous belief that EAP is (or can be) a three-party
> authentication protocol: it isn't, and can't be.  It could _carry_ a
> three-party protocol (like Kerberos), but EAP in itself is a
> two-party protocol.
>
> > why do you care that only one party knows that radius is
> > used? it could also be diameter.
> >
> > i would like to better understand why some people dislike the aaa
> > architecture (radius, diameter).
>
> I think that the misunderstanding mentioned above might have
> something to do with it...

As Glen said, EAP is a two-party protocol (run between EAP peer and
server).  RADIUS is also a two party protocol (between the authenticator
and server).  The system may also include a protocol run between the peer
and authenticator (the Secure Association Protocol).

An application has the flexibility to define new AAA attributes
(e.g. Diameter EAP); to define requirements with respect to EAP methods
(e.g. RFC 4017); and to define the Secure Association Protocol
(e.g. 802.11i 4-way handshake).

This flexibility is both a blessing and a curse.  It is a blessing in
that there is a lot of flexibility available to meet requirements if they
are well defined.  It is a curse because a key management application
needs to do considerable work in defining and analyzing the security
properties of the system in order to meet the security requirements
described in RFC 4017 (the Housley Criteria).

To enable analysis, the specification needs to detail the required AAA
protocol and EAP method properties as well as to define the security
properties of the Secure Association Protocol.  The best existing example
of this to date is probably IEEE 802.11i, but even that effort left out
some important pieces.

Note that the ISMS charter explicitly mentions RADIUS support:

"Version 3 of the Simple Network Management Protocol (SNMPv3) was
elevated to Internet Standard in late 2002 and added security to the
previous versions of the protocol. Although the enhanced protocol
is secure, operators and administrators find that deploying it can
be problematic in large distributions. This is due primarily to two
synchronization problems. The first is the addition of yet another
authentication system specific to SNMPv3 that needs to be maintained
across all networking devices. Most of these devices already
contain local accounts and/or the ability to negotiate with
authentication servers (e.g. RADIUS servers). However, SNMPv3 does
not make use of these authentication mechanisms, and this causes
additional synchronization burdens. The second issue found with
deploying SNMPv3 is that distributing and maintaining View-based
Access Control Model (VACM) rules is also difficult in large-scale
environments."

--
to unsubscribe send a message 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, 17 Apr 2005 18:11:34 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Tschofenig Hannes'" <[email-masked]>, "'Sam Hartman'" <[email-masked]>, "'Martin Soukup'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Isms] RADIUS is not a trusted third party
Date: Sun, 17 Apr 2005 11:09:54 -0700

Tschofenig Hannes <> supposedly scribbled:

> hi sam,
>=20
> you have intentionally chosen a provocative title for your mail.
>=20
> you write:
>=20
> "
>> Remember that RADIUS is a callout service; it is not a trusted
third
>> party.  In other words, in a particular SNMP authentication, only
one
>> of the parties will know that RADIUS is being used. "
>=20
> what is a "callout service"?
> what is radius for you? (you write that it is not a trusted third
> party.)=20

It's not.  From the point of view of authentication protocols (PAP,
CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": the
operation of the auth protocols should be exactly the same as if
they terminated in the AAA client, instead of elsewhere.  Basically,
the purpose of AAA (again, from the POV of an authentication
protocol) is simply scaling.  BTW, a lot of misery has been caused
by the erroneous belief that EAP is (or can be) a three-party
authentication protocol: it isn't, and can't be.  It could _carry_ a
three-party protocol (like Kerberos), but EAP in itself is a
two-party protocol.

> why do you care that only one party knows that radius is
> used? it could also be diameter. =20
>=20
> i would like to better understand why some people dislike the aaa
> architecture (radius, diameter).=20

I think that the misunderstanding mentioned above might have
something to do with it...

>=20
> ciao
> hannes
>=20
>=20
>> -----Urspr=FCngliche Nachricht-----
>> Von: [email-masked]
>> [mailto:[email-masked]] Im Auftrag von Sam Hartman
>> Gesendet: Freitag, 15. April 2005 19:34
>> An: Martin Soukup
>> Cc: [email-masked]
>> Betreff: [Isms] RADIUS is not a trusted third party
>>=20
>>=20
>>>>>>> "Martin" =3D=3D Martin Soukup <[email-masked]> writes:
>>=20
>>     Martin> RADIUS "Access-Accept" indicates a successful
>>     Martin> authenthentication response for a user.
>>=20
>>     Martin> The Access-Accept already returns a
"Session-Timeout",
>>     Martin> defined as "Sets the maximum number of seconds of
service
>>     Martin> to be provided to the user before the session
>>     Martin> terminates. This attribute value becomes the per-user
>>     Martin> "absolute timeout."".
>>=20
>> This only tells the SNMP engine talking to the RADIUS server the
>> timeout.  You need to tell the other side of the exchange the
>> timeout too.=20
>>=20
>> Remember that RADIUS is a callout service; it is not a trusted
third
>> party.  In other words, in a particular SNMP authentication, only
one
>> of the parties will know that RADIUS is being used.
>>=20
>>=20
>> _______________________________________________
>> Isms mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/isms
>>=20
>=20
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms

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, 15 Apr 2005 23:25:10 +0000
Date: Fri, 15 Apr 2005 16:24:40 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt 

>   I see IPv6 attributes there, but not 64-bit *integers*.

All of the existing 64 and 128-bit attributes are unsigned values.  Here
is a summary:

Attribute              RFC        Size
---------              ---        ----
ARAP-Password          RFC 2869   128 bits (4 32-bit quantities)
NAS-IPv6-Address       RFC 3162   128 bits
Framed-Interface-Id    RFC 3162   64 bits
Login-IPv6-Host        RFC 3162   128 bits

As Avi mentioned, the bandwidth values would also be unsigned.  So I think
there is precedent for this.

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

Envelope-to: [email-masked]
Delivery-date: Fri, 15 Apr 2005 19:32:54 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt 
Cc: [email-masked]
Date: Fri, 15 Apr 2005 15:29:30 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> 64-bit attributes are already supported in existing RADIUS RFCs such as
> RFC 3162.

  ? I see IPv6 attributes there, but not 64-bit *integers*.

> I don't think you need a 64-bit processor to handle a 64-bit RADIUS
> attribute.

  You will need a 64-bit aware compiler at least.

  Again, my concerns aren't show-stoppers, they're nit-picks.  I just
want to be clear that 64-bit integer support is *new*.

> I think this makes sense.  We should add this to "issues and fixes"
> It will be trickier for RADIUS servers to require Message-Authenticator
> for legacy applications, of course.

  I agree.  Thanks.

  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, 15 Apr 2005 17:46:22 +0000
Date: Fri, 15 Apr 2005 10:45:44 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt 

>   I'm not opposed to 64-bit attributes, but introducing them is a
> major change to RADIUS.

64-bit attributes are already supported in existing RADIUS RFCs such as
RFC 3162.

> Not all platforms support 64-bit operations,
> making *full* implementation of 64-bit attributes problematic.

I don't think you need a 64-bit processor to handle a 64-bit RADIUS
attribute.

>   My preference for the "issues & fixes" draft is to STRONGLY suggest
> that all new implementations always add Message-Authenticator to the
> packet.  This avoids a number of attack vectors.

I think this makes sense.  We should add this to "issues and fixes"
It will be trickier for RADIUS servers to require Message-Authenticator
for legacy applications, of course.

--
to unsubscribe send 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, 15 Apr 2005 16:41:01 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt 
Cc: [email-masked]
Date: Fri, 15 Apr 2005 12:37:32 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> [BA] One thing to keep in mind is that bandwidth increases an order of
> magnitude every 3 years.  10 terrabits might seem like a lot, but we are
> at 10 Gbps now, and increasing by 3 orders of magnitude will only take a
> decade.  So my recommendation is to look at a 64-bit attribute.

  I'm not opposed to 64-bit attributes, but introducing them is a
major change to RADIUS.  Not all platforms support 64-bit operations,
making 8full* implementation of 64-bit attributes problematic.

  That being said, hardware is cheap enough & compilers are smart
enough that 64-bit support shouldn't be too problematic.

> [BA] Are you saying that Message-Authenticator is required in an
> Access-Request including bandwidth attributes?  Today we require
> Message-Authenticator for use with EAP & Digest, but not with legacy
> mechanisms (PAP, CHAP).  I guess this draft won't be used along with
> legacy mechanisms, so perhaps this would be ok.

  My preference for the "issues & fixes" draft is to STRONGLY suggest
that all new implementations always add Message-Authenticator to the
packet.  This avoids a number of attack vectors.

  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, 15 Apr 2005 15:59:47 +0000
Date: Fri, 15 Apr 2005 08:59:36 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt

> think of alternative scales such as Kbps, as well as a 64-bit
> value instead of 32-bits.

We agree.  The bandwidth attribute should be specified as an integer in
units of Kbps. This will give us 2^31 Kbps which is  2^34 bps or 10,000
Gbps.

There is no need to send extra bits.  We can even increase one order of
magnitude by making it an unsigned integer.  If need be we can also
specify Kbytes instead of Kilobits.

[BA] One thing to keep in mind is that bandwidth increases an order of
magnitude every 3 years.  10 terrabits might seem like a lot, but we are
at 10 Gbps now, and increasing by 3 orders of magnitude will only take a
decade.  So my recommendation is to look at a 64-bit attribute.

> 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.

Section 2 is not an architecture section. It defines the behavior.
Section 3 describes the attributes.  Having said that, we could trim back
on the behavior and boaster up the attribute description. But please note
that the attributes in by themselves are very simple.  It's the behavior
that is complex in this case.

[BA] I guess I don't understand why the behavior is so complex.  As I
understand it, the goal here is to specify egress & ingress bandwidth
limits for a client.  Now those limits can be changed via RFC 3576, but
this is a static adjustment, rather than a closed loop control system,
correct?

We agree that we need a better description here.  We will take that as an
action item to tighten that part of the protocol.

[BA] My preference would be for the attribute to represent the rate
negotiated with the client.  For example, with 802.11g it might be
anything from 1 Mbps to 54 Mbps.  Or for Ethernet, anything from 10 Mbps
to 10 Gbps.  Note that the rate can change, so that the value in an
Accounting Interim might be different from the value in the Accounting
Start or STOP.

No actually.  We need to provide both the granted bandwidth and the
measured octets in/out.

[BA] So the value in the Access-Accept is merely being echo'd in the
Accounting records?  If so, that makes sense.

Actually we messed up that section somewhat. We only need one value -
either would work.

[BA] OK.

And really that value is a nice to have.  Mid session changes to bandwidth
are allowed (using COA) and MAY cause Acct Stop followed by Acct Start.

[BA] Yes, an RFC 3576 CoA-Request can cause that.

Having a reason in the Terminate Cause to indicate "session continue"
helps the back systems understand that the session is not really going
away. This may help some folks realize that the arrival of the Stop is not
the end of the session.

[BA] Can't Acct-Multi-Session-Id be used for that?  For example, RFC 3580
suggests that this be used to link together sessions created as a result
of a handoff.

MITM lowering the values in the Access-Request potentially cause the
operator to request lower bandwidth for the user.  To protect against that
we need to integrity protect the Access-Request.

[BA] Are you saying that Message-Authenticator is required in an
Access-Request including bandwidth attributes?  Today we require
Message-Authenticator for use with EAP & Digest, but not with legacy
mechanisms (PAP, CHAP).  I guess this draft won't be used along with
legacy mechanisms, so perhaps this would be ok.

MITM uping the request bandwidth causing a user to be billed for bandwidth
that they didn't ask for.  RADIUS already protects against this.

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

Delivery-date: Fri, 15 Apr 2005 15:26:04 +0000
Date: Fri, 15 Apr 2005 08:25:25 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Last Call on Digest Authentication

This is an announcement of RADEXT WG last call on the Digest
Authentication draft prior to sending the document to the IESG for
consideration as a Proposed Standard.

Prior to showing up on the IETF Archive, the document is available for
review here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-02.txt

Once it is posted to the IETF archive, the document will be available
here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-02.txt

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

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

Delivery-date: Wed, 13 Apr 2005 10:18:33 +0000
From: Avi Lior <[email-masked]>
To: [email-masked], Bernard Aboba <[email-masked]>
Cc: Avi Lior <[email-masked]>, "'Bari, Farooq'" <[email-masked]>, "'Adrangi, Farid'" <[email-masked]>,  "'Congdon, Paul T (ProCurve)'" <[email-masked]>
Subject: My replies to Bernards Comments
Date: Wed, 13 Apr 2005 06:17:52 -0400

Hi Bernard,

Thank you for taking the time to read and review the Bandwidth draft.
Please see our comments inline.

snip

> 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.

We agree.  The bandwidht attribute should be specified as an integer in
units of Kbps. This will give us 2^31 Kbps which is  2^34 bps or 10,000
Gbps.

There is no need to send extra bits.  We can even increase one order of
magnitude by making it an unsigned integer.  If need be we can also specify
Kbytes instead of Kilobits.
 
> 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.

Section 2 is not an architecture section. It defines the behavior.  Section
3 describes the attributes.  Having said that, we could trim back on the
behavior and boaster up the attribute description. But please note that the
attributes in by themselves are very simple.  It's the behavior that is
complex in this case.
 
> 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.

We agree that we need a better description here.  We will take that as an
action item to tighten that part of the protocol.

> 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.

No actually.  We need to provide both the granted bandwidth and the measured
octets in/out.

This is because if the user requests a certain bandwidth and that bandwidth
is allocated then even though the user did not use the bandwidth, the
operator may still want to bill them for the requested bandwidth.  The
operator is billing the user for providing the pipe.

In fact many operators bill the user based solely on the bandwidth
capability and not how much bandwidth they actually use.

>    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.

Yes it is signalling that its only capable of doing symmetric.  We are just
trying to be complete here since there could be a case where a device is
only capable of doing symmetric.

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

Actually we messed up that section somewhat. We only need one value - either
would work.

And really that value is a nice to have.  Mid session changes to bandwidth
are allowed (using COA) and MAY cause Acct Stop followed by Acct Start.
Having a reason in the Terminate Cause to indicate "session continue" helps
the back systems understand that the session is not really going away. This
may help some folks realize that the arrival of the Stop is not the end of
the session.

Other SDOs have been including a VSA for that purpose -- for example a MIP
handoff creates Stop Start records. It helps mediation process when this
type of information is included.

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

It would be nice to get help here.  

Some things that come to mind:

MITM lowering the values in the Access-Request potentially cause the
operator to request lower bandwidth for the user.  To protect against that
we need to integrity protect the Access-Request.

MITM uping the request bandwidth causing a user to be billed for bandwidth
that they didn't ask for.  RADIUS already protects against this.
 
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message 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, 12 Apr 2005 23:51:43 +0000
Date: Tue, 12 Apr 2005 19:51:25 -0400
From: Barney Wolff <[email-masked]>
To: Greg Weber <[email-masked]>
Cc: [email-masked]
Subject: Re: [q] CUI-04: NAS controlled?

On Tue, Apr 12, 2005 at 07:30:19PM -0400, Greg Weber wrote:
> 
> >From draft-ietf-radext-chargeable-user-id-04.txt Section 2.1:
> 
>    If a home RADIUS server that supports the CUI attribute receives an
>    Access-Request packet containing a CUI (set to nul or otherwise), it
>    MUST include the CUI attribute in the Access-Accept packet.
>    Otherwise, if the Access-Request packet does not contain a CUI, the
>    home RADIUS server MUST NOT include the CUI attribute in the
>    Access-Accept packet.
> 
> Looking at the last sentence, that seems to mean that the server
> cannot ever send CUI unless the NAS hints that it's desired.
> Is that the intent?  As you point out in the draft, the NAS can
> ignore CUI if it doesn't understand it.  It may be desirable to
> not have the NAS send CUI in every request- even if the NAS 
> understands how to handle CUI.  This seems to be an unnecessary
> restriction on the server.

We've been over this.  2865 allows ignoring unknown attributes, but
does not mandate it.  Since CUI is strictly for the benefit of the
sender of the Access-Request, if the NAS or proxy doesn't demand it,
the server has no reason to send it.

-- 
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: Tue, 12 Apr 2005 23:30:34 +0000
From: Greg Weber <[email-masked]>
Subject: [q] CUI-04: NAS controlled?
To: [email-masked]
Date: Tue, 12 Apr 2005 19:30:19 -0400 (EDT)

>From draft-ietf-radext-chargeable-user-id-04.txt Section 2.1:

   If a home RADIUS server that supports the CUI attribute receives an
   Access-Request packet containing a CUI (set to nul or otherwise), it
   MUST include the CUI attribute in the Access-Accept packet.
   Otherwise, if the Access-Request packet does not contain a CUI, the
   home RADIUS server MUST NOT include the CUI attribute in the
   Access-Accept packet.

Looking at the last sentence, that seems to mean that the server
cannot ever send CUI unless the NAS hints that it's desired.
Is that the intent?  As you point out in the draft, the NAS can
ignore CUI if it doesn't understand it.  It may be desirable to
not have the NAS send CUI in every request- even if the NAS 
understands how to handle CUI.  This seems to be an unnecessary
restriction on the server.

Comments?

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: Tue, 12 Apr 2005 23:23:18 +0000
From: Greg Weber <[email-masked]>
Subject: [Issue] Editorial cmts on CUI-04
To: [email-masked]
Date: Tue, 12 Apr 2005 19:22:54 -0400 (EDT)

Editorial comments on CUI-04
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: April 12, 2005
Reference: n/a
Document: draft-ietf-radext-chargeable-user-id-04.txt
Comment type: E
Priority: 1
Section: various
Rationale/Explanation of issue:

Some editorial nits by section
(S=Section, P=Paragraph)

S1P5: "subscriber" and "user" seem to be used interchangably.  Unless you
      mean something different by "subscriber", I suggest there would be
      less potential for confusion is you use "user" consistently. Otherwise,
      please explain the difference in meaning.
S1.1P3: "Therfore" -> "Therefore"
S2P1: There aren't really any references to or dependencies on RFC3576.
      Why not just remove this reference?
S2.1P2: "may not choose to send" -> "may choose not to send"
S2.2: In the ASCII art, the bit position numbers are not lined up
      with the diagram (off by one column).
S4:   The Diameter Considerations sections seems to place requirements on
      other documents.  Isn't CUI available to Diameter applications as
      a RADIUS attribute?  Why does another attribute need to be defined?
      Maybe the text of this section can be removed & just say that there
      are no particular Diameter considerations.
S6P2: "clients)outside" -> "clients) outside"

--
to unsubscribe send a message 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, 12 Apr 2005 13:11:10 +0000
Date: Tue, 12 Apr 2005 06:10:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [AAA-WG]: issue with expected response calculation (fwd)

---------- Forwarded message ----------
Date: Tue, 12 Apr 2005 14:26:05 +0200
From: Jo Hermans <[email-masked]>
To: [email-masked]
Subject: [AAA-WG]: issue with expected response calculation

I have a problem with paragraph 8.5.6.1 <http://8.5.6.1> in
draft-ietf-aaa-diameter-sip-app-07 , 3th paragraph ("Please note that the
expected response ...")

The draft mentions that the expected response calculation can't be done when
the SIP UA has sent a expected response based on client nonces. It then
mentions that this is the case when the qop-parameter is present in the
client request.

That last part I don't understand. I though that H(A1) is dependent on the
algorithm, not qop. Qop has only influence on the A2 and digest, which are
both calculated in the Diameter Client (SIP Server). See also <
http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue40>

But even then I don't understand. I think that the Diameter Server does has
the client-nonces available (they're in the SIP-Authorization AVP, and were
used to calculate the request digest !)), and is able to calculate a H(A1).
Even if MD5-sess was used, it could still calculate H(A1). MD5-sess also has
the added advantage that H(A1) could only be used once, which is also the
reason why draft-sterman-aaa-sip-04.txt doesn't want to use MD5 unless the
message is protected against eavesdropping.

I agree that if qop is missing and algorithm is MD5, client-nonces aren't
used at all (backwards compatibility with RFC2069). H(A1) might be stored
inside the Diameter Client (SIP server) when it's first received, and reused
later on. Is it this that the draft is alluding to ?

-- 
Jo Hermans

"Eagles may soar, but weasels aren't sucked into jet engines"

--
to unsubscribe send a message 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, 10 Apr 2005 17:45:42 +0000
Date: Sun, 10 Apr 2005 10:45:36 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG Last Call on Chargeable UserId Draft

This is a reminder about a RADEXT WG last call in progress on
the Chargeable UserId Draft prior to sending the document to the IESG for
consideration as a Proposed Standard.

The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-04.txt

RADEXT WG last call will last until Monday, April 18, 2005.  Please send
comments to the RADEXT WG mailing list ([email-masked]) in the
Issues format described on the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Sun, 10 Apr 2005 17:43:47 +0000
Date: Sun, 10 Apr 2005 10:43:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Any last comments on draft-adrangi-eap-network-discovery-12.txt?

The -12 version of the EAP Network Discovery document is now available on
the IETF archive at:
http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-12.txt

This document has requested publication as an Informational RFC via the
RFC editor individual submissino route.

Unless we hear any comments by Monday, April 18, 2005 we are going to
assume this document has completed review and we will inform the IESG of that.

So if you any remaining issues, please post them to the EAP WG mailing
list ([email-masked]).

Note: there appears to be an IPR claim related to this document:
http://www.ietf.org/ietf/IPR/telecom-italia-ipr-wlan-access.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/>

Envelope-to: [email-masked]
Delivery-date: Thu, 07 Apr 2005 22:07:25 +0000
From: "Alan DeKok" <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Bikramjit Singh <[email-masked]>, [email-masked]
Subject: Re: When to Access-Reject vs. Silently Discard 
Date: Thu, 07 Apr 2005 18:03:57 -0400
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> I don't know what you mean by close in the network.  So a typical case where
> this happens is when there is a NAS in the DMZ zone and a RADIUS is
> internal.

  I understand.

  In that case, the NAT box which the RADIUS server sees as the NAS is
"closer" to the RADIUS box than the real NAS.

  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, 07 Apr 2005 19:16:18 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, Bikramjit Singh <[email-masked]>
Cc: [email-masked]
Subject: RE: When to Access-Reject vs. Silently Discard
Date: Thu, 7 Apr 2005 15:16:05 -0400 

Alan,

I don't know what you mean by close in the network.  So a typical case where
this happens is when there is a NAS in the DMZ zone and a RADIUS is
internal.

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Thursday, April 07, 2005 2:56 PM
> To: Bikramjit Singh
> Cc: [email-masked]
> Subject: Re: When to Access-Reject vs. Silently Discard
> 
> 
> Bikramjit Singh <[email-masked]> wrote:
> > [Bik] Isn't this condition also true if there is NAT in the middle? 
> > And you have provisioned the RADIUS client with the publicly known 
> > external address.
> 
>   In which case, the NAS isn't "close" in the network to the 
> RADIUS server.
> 
>   NAT & RADIUS don't interact well.
> 
>   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/>

Envelope-to: [email-masked]
Delivery-date: Thu, 07 Apr 2005 18:59:38 +0000
From: "Alan DeKok" <[email-masked]>
To: Bikramjit Singh <[email-masked]>
Cc: [email-masked]
Subject: Re: When to Access-Reject vs. Silently Discard 
Date: Thu, 07 Apr 2005 14:56:04 -0400
Message-Id: <[email-masked]>

Bikramjit Singh <[email-masked]> wrote:
> [Bik] Isn't this condition also true if there is NAT in the middle? And you
> have provisioned the RADIUS client with the publicly known external address.

  In which case, the NAS isn't "close" in the network to the RADIUS
server.

  NAT & RADIUS don't interact well.

  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, 07 Apr 2005 18:42:59 +0000
From: Bikramjit Singh <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, 'Bernard Aboba' <[email-masked]>
Cc: "'Glen Zorn (gwz)'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: When to Access-Reject vs. Silently Discard 
Date: Thu, 7 Apr 2005 11:34:32 -0700 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C53BA0.70AEFED0
Content-Type: text/plain

  The only times I can see (NAS-IP-Address != source IP) for local
NASes are buggy implementations, or security breaches.  Is there
another case that text is trying to address, that I'm missing?

[Bik] Isn't this condition also true if there is NAT in the middle? And you
have provisioned the RADIUS client with the publicly known external address.
There are some implementations like that.. 

Thanks

-Bik

------_=_NextPart_001_01C53BA0.70AEFED0
Content-Type: text/html
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 =
5.5.2657.73">
<TITLE>RE: When to Access-Reject vs. Silently Discard </TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&nbsp; The only times I can see (NAS-IP-Address !=3D =
source IP) for local</FONT>
<BR><FONT SIZE=3D2>NASes are buggy implementations, or security =
breaches.&nbsp; Is there</FONT>
<BR><FONT SIZE=3D2>another case that text is trying to address, that =
I'm missing?</FONT>
</P>

<P><FONT SIZE=3D2>[Bik] Isn't this condition also true if there is NAT =
in the middle? And you have provisioned the RADIUS client with the =
publicly known external address. There are some implementations like =
that.. </FONT></P>

<P><FONT SIZE=3D2>Thanks</FONT>
</P>

<P><FONT SIZE=3D2>-Bik</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C53BA0.70AEFED0--

--
to unsubscribe send a message 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, 07 Apr 2005 18:42:36 +0000
Date: Thu, 7 Apr 2005 11:42:03 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: "Glen Zorn (gwz)" <[email-masked]>, [email-masked]
Subject: Re: When to Access-Reject vs. Silently Discard 

>   The only times I can see (NAS-IP-Address != source IP) for local
> NASes are buggy implementations, or security breaches.  Is there
> another case that text is trying to address, that I'm missing?

That's about it.

>   If it's a buggy implementation, upgrade.  If it's a security breach,
> an Access-Reject is wrong: the NAS should be de-listed from the known
> clients, to avoid an attacker using the trust relationship to gain
> knowledge about users.

Certainly the NAS should be delisted, but presumably that will not occur
automatically, but as the result of administrator action responding to an
appropriate alert.

--
to unsubscribe send 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, 07 Apr 2005 18:11:23 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: When to Access-Reject vs. Silently Discard 
Date: Thu, 07 Apr 2005 14:07:50 -0400
Message-Id: <[email-masked]>

"Glen Zorn (gwz)" <[email-masked]> wrote:
> > We "know" it's the right NAS, because it has the right source IP
> > and shared secret, which is the only way to identify any NAS.
>
> But it's not a _user_ authentication or authorization problem,
> either; it's neither fish nor fowl.

  From the point of view of the RADIUS server, it's just more
information in the packet.  It doesn't know about "users", and doesn't
need to.  e.g. MAC address authentication.

  If the RADIUS server doesn't like something in the packet it gets
from a trusted NAS, it sends an Access-Reject.  I'm not sure how the
issue of "NAS authorized for realms" is any different than any other
case.

  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: Thu, 07 Apr 2005 17:26:46 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: "Glen Zorn (gwz)" <[email-masked]>, [email-masked]
Subject: Re: When to Access-Reject vs. Silently Discard 
Date: Thu, 07 Apr 2005 13:23:03 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> > Sending Access-Reject when (NAS-IP-Address != source IP) would
> > break a LOT of deployments.  And it's a SHOULD, not a MUST.
> 
> This is only something for a local proxy, not an intermediate proxy or a
> server.  Assuming that it's only a local proxy why would this break
> deployments?

  If the NAS is actually a NAS, and not a proxying server, and if the
NAS is close (in the network) to the RADIUS server, then this
restriction can make sense.

  It's difficult to administer in practice, however, given the
skill-set and knowledge I've seen.  That restriction would be turned
off in many deployments I've seen, because it's too easy to get wrong,
and it has little to no value.

  To back up: If you're worried that the NAS will impersonate another
one via NAS-IP-Address, why are you listening to it at all?

  The only times I can see (NAS-IP-Address != source IP) for local
NASes are buggy implementations, or security breaches.  Is there
another case that text is trying to address, that I'm missing?

  If it's a buggy implementation, upgrade.  If it's a security breach,
an Access-Reject is wrong: the NAS should be de-listed from the known
clients, to avoid an attacker using the trust relationship to gain
knowledge about users.

  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, 07 Apr 2005 04:32:13 +0000
Date: Wed, 6 Apr 2005 21:31:32 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "'Alan DeKok'" <[email-masked]>, [email-masked]
Subject: RE: When to Access-Reject vs. Silently Discard 

> Sending Access-Reject when (NAS-IP-Address != source IP) would
> break a LOT of deployments.  And it's a SHOULD, not a MUST.

This is only something for a local proxy, not an intermediate proxy or a
server.  Assuming that it's only a local proxy why would this break
deployments?

--
to unsubscribe send a message 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, 07 Apr 2005 01:21:19 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, <[email-masked]>
Subject: RE: When to Access-Reject vs. Silently Discard 
Date: Wed, 6 Apr 2005 18:20:42 -0700

Alan DeKok <> supposedly scribbled:

> Avi Lior <[email-masked]> wrote:
>> In the RADIUS Digest thread (Issue 79) when the Server detects
that
>> the NAS is trying to authenticate a realm for which it is not
>> authorized we need to "reject" the authentication.   This can be
>> done by either Access-Reject or 
>> Silently Discarding the packet.  SO the question is which one is
>> correct? 
> 
>   I would back up, and say when do we discard, versus send reject?
> 
>  - attempted security breaches (bad Message-Authenticator, unknown
>    client) result in the packet being discarded.

Right.

> 
>  - failed authentication or authorization results in Access-Reject
>    (bad password, not permitted to use requested services, etc)

Right.

> 
>> Its not clear:  for example if Message-Authenticator(80) does not
>> validate (as per 3579) we silently discard.  When we detect a
lying
>> NAS again as per 3579 we generate an Access-Reject:   "Where a
match
>> is not found, an 
>> Access-Reject SHOULD be
>>  sent, and an error SHOULD be logged."
> 
>   Sending Access-Reject when (NAS-IP-Address != source IP) would
> break a LOT of deployments.  And it's a SHOULD, not a MUST. 

Yes, that is way broken, IMHO.

> 
> 
>   For the case of a NAS authenticating for a realm it's not
> authorized to use, we need to ask if it's a security problem or
> failed authorization.  The answer to that question will tell us
how
> to handle this case.   
> 
>   My $0.02 is that if the packet contains a valid
> Message-Authenticator, then an Access-Reject should be sent, AND
an
> error message logged saying that the NAS is misconfigured, or may
be
> compromised.  We "know" it's the right NAS, because it has the
right
> source IP and shared secret, which is the only way to identify any
> NAS.     

But it's not a _user_ authentication or authorization problem,
either; it's neither fish nor fowl.

> 
>   If the packet doesn't contain a Message-Authenticator, then the
> answer is more complex. 
> 
>   In this case, I believe that the packet does contain
> Message-Authenticator. 
> 
>   Alan DeKok.

Hope this helps,

~gwz

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

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

Delivery-date: Wed, 06 Apr 2005 19:03:35 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Cc: "'Beck01, Wolfgang'" <[email-masked]>, "Salowey, Joe" <[email-masked]>
Subject: RE: When to Access-Reject vs. Silently Discard
Date: Wed, 6 Apr 2005 15:02:56 -0400 

Hi Alan,

Okay I agree with your $0.02. So we should do a reject in RADIUS Digest in
this case.

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Wednesday, April 06, 2005 1:03 PM
> To: [email-masked]
> Subject: Re: When to Access-Reject vs. Silently Discard
> 
> 
> Avi Lior <[email-masked]> wrote:
> > In the RADIUS Digest thread (Issue 79) when the Server detects that 
> > the NAS is trying to authenticate a realm for which it is 
> not authorized we need to
> > "reject" the authentication.   This can be done by either 
> Access-Reject or
> > Silently Discarding the packet.  SO the question is which one is 
> > correct?
> 
>   I would back up, and say when do we discard, versus send reject?
> 
>  - attempted security breaches (bad Message-Authenticator, unknown
>    client) result in the packet being discarded.
> 
>  - failed authentication or authorization results in Access-Reject
>    (bad password, not permitted to use requested services, etc)
> 
> > Its not clear:  for example if Message-Authenticator(80) does not 
> > validate (as per 3579) we silently discard.  When we detect 
> a lying NAS again as per
> > 3579 we generate an Access-Reject:   "Where a match is not found, an
> > Access-Reject SHOULD be
> >  sent, and an error SHOULD be logged."
> 
>   Sending Access-Reject when (NAS-IP-Address != source IP) 
> would break a LOT of deployments.  And it's a SHOULD, not a MUST.
> 
> 
>   For the case of a NAS authenticating for a realm it's not 
> authorized to use, we need to ask if it's a security problem 
> or failed authorization.  The answer to that question will 
> tell us how to handle this case.
> 
>   My $0.02 is that if the packet contains a valid 
> Message-Authenticator, then an Access-Reject should be sent, 
> AND an error message logged saying that the NAS is 
> misconfigured, or may be compromised.  We "know" it's the 
> right NAS, because it has the right source IP and shared 
> secret, which is the only way to identify any NAS.
> 
>   If the packet doesn't contain a Message-Authenticator, then 
> the answer is more complex.
> 
>   In this case, I believe that the packet does contain 
> Message-Authenticator.
> 
>   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/>

Envelope-to: [email-masked]
Delivery-date: Wed, 06 Apr 2005 17:06:35 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: When to Access-Reject vs. Silently Discard 
Date: Wed, 06 Apr 2005 13:02:55 -0400
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> In the RADIUS Digest thread (Issue 79) when the Server detects that the NAS
> is trying to authenticate a realm for which it is not authorized we need to
> "reject" the authentication.   This can be done by either Access-Reject or
> Silently Discarding the packet.  SO the question is which one is correct?

  I would back up, and say when do we discard, versus send reject?

 - attempted security breaches (bad Message-Authenticator, unknown
   client) result in the packet being discarded.

 - failed authentication or authorization results in Access-Reject
   (bad password, not permitted to use requested services, etc)

> Its not clear:  for example if Message-Authenticator(80) does not validate
> (as per 3579) we silently discard.  When we detect a lying NAS again as per
> 3579 we generate an Access-Reject:   "Where a match is not found, an
> Access-Reject SHOULD be
>  sent, and an error SHOULD be logged."

  Sending Access-Reject when (NAS-IP-Address != source IP) would break
a LOT of deployments.  And it's a SHOULD, not a MUST.

  For the case of a NAS authenticating for a realm it's not authorized
to use, we need to ask if it's a security problem or failed
authorization.  The answer to that question will tell us how to handle
this case.

  My $0.02 is that if the packet contains a valid
Message-Authenticator, then an Access-Reject should be sent, AND an
error message logged saying that the NAS is misconfigured, or may be
compromised.  We "know" it's the right NAS, because it has the right
source IP and shared secret, which is the only way to identify any NAS.

  If the packet doesn't contain a Message-Authenticator, then the
answer is more complex.

  In this case, I believe that the packet does contain
Message-Authenticator.

  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, 06 Apr 2005 16:30:45 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: When to Access-Reject vs. Silently Discard
Date: Wed, 6 Apr 2005 12:29:57 -0400 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C53AC5.DF0210B0
Content-Type: text/plain

Hi,
 
In the RADIUS Digest thread (Issue 79) when the Server detects that the NAS
is trying to authenticate a realm for which it is not authorized we need to
"reject" the authentication.   This can be done by either Access-Reject or
Silently Discarding the packet.  SO the question is which one is correct?
 
Its not clear:  for example if Message-Authenticator(80) does not validate
(as per 3579) we silently discard.  When we detect a lying NAS again as per
3579 we generate an Access-Reject:   "Where a match is not found, an
Access-Reject SHOULD be
 sent, and an error SHOULD be logged."
So is there are rule that can express the correct thing to do?

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

Avi Lior                                    
Bridgewater Systems Corporation                
Phone :  (613) 591-9104 x6417

Cell    :  (613) 297-2177
E-mail :  <mailto:[email-masked]>
mailto:[email-masked]

www.bridgewatersystems.com <http://www.bridgewatersystems.com/>  

 

------_=_NextPart_001_01C53AC5.DF0210B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2604" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D863472116-06042005><FONT face=3DArial=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D863472116-06042005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D863472116-06042005><FONT face=3DArial size=3D2>In =
the RADIUS Digest=20
thread (Issue 79) when the Server detects that the NAS is trying to =
authenticate=20
a realm for which it is not authorized we need to "reject" the=20
authentication.&nbsp;&nbsp; This can be done by either Access-Reject or =
Silently=20
Discarding the packet.&nbsp; SO the question is which one is=20
correct?</FONT></SPAN></DIV>
<DIV><SPAN class=3D863472116-06042005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D863472116-06042005><FONT face=3DArial size=3D2>Its =
not clear:&nbsp;=20
for example if Message-Authenticator(80) does not validate (as per =
3579) we=20
silently discard.&nbsp; When we detect a lying NAS again as per 3579 we =
generate=20
an Access-Reject:&nbsp;&nbsp;</FONT></SPAN><SPAN=20
class=3D863472116-06042005>&nbsp;"Where a match is not found, an =
Access-Reject=20
SHOULD be<BR>&nbsp;sent, and an error SHOULD be logged."</DIV><PRE>So =
is there are rule that can express the correct thing to =
do?</PRE></SPAN>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV class=3DSection1>
<P align=3Dleft><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><?xml:namespace prefix =
=3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=3DMsoNormal><STRONG><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: #0080c0; FONT-FAMILY: =
Verdana">------------------------------------------------</SPAN></STRONG=
></P>
<P class=3DMsoNormal><STRONG><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: #0080c0; FONT-FAMILY: Verdana">Avi=20
Lior</SPAN></STRONG><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: #0080c0; FONT-FAMILY: =
Verdana">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
<BR>Bridgewater Systems=20
Corporation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>Phone :&nbsp; (613) 591-9104 x6417</SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: #0080c0; FONT-FAMILY: =
Verdana">Cell&nbsp;&nbsp;&nbsp;&nbsp;:&nbsp;=20
(613)&nbsp;297-2177<BR>E-mail : </SPAN><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><A=20
href=3D"mailto:[email-masked]"><SPAN=20
style=3D"COLOR: =
#0080c0">mailto:[email-masked]</SPAN></A></SPAN><o:p></o:p><=
/P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><A=20
href=3D"http://www.bridgewatersystems.com/">www.bridgewatersystems.com</=
A></FONT>&nbsp;<o:p></o:p></P></DIV>
<DIV><o:p>&nbsp;</o:p></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C53AC5.DF0210B0--

--
to unsubscribe send a message 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, 05 Apr 2005 07:37:24 +0000
Date: Tue, 05 Apr 2005 10:31:43 +0300
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: AW: AW: Issue 79; digest-auth realm validation

Hi Wolfgang:

Yeap, understood now. The Message-Authenticator will help definitely. 
Then I believe your compromising considerations are right.

/Miguel

Beck01, Wolfgang wrote:

> 
>>So you basically stop in the RADIUS server processing further 
>>requests that come from the same RADIUS client?
> 
> yes.
> 
>>How do you identify the RADIUS client, is it by its IP address?
> 
> yes, and by a shared secret. But I am not sure whether current RADIUS
> server APIs support this.
> 
> 
>>What I am trying to avoid is that this "compromise" prevents 
>>that RADIUS server to process legitimate requests coming from a RADIUS 
>>client just because an attacker wrote a forged RADIUS request to preclude that 
>>client to be operating anymore.
> 
> This would be a quite effective DoS attack. But Message-Authenticator is mandatory
> now and should make forging RADIUS requests much harder.
> 
> 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: Mon, 04 Apr 2005 22:18:55 +0000
content-class: urn:content-classes:message
Subject: RE: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 15:21:55 -0700
From: "Salowey, Joe" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: "Beck01, Wolfgang" <[email-masked]>

=20

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]=20
> Sent: Monday, April 04, 2005 2:22 PM
> To: 'Nelson, David'; [email-masked]
> Cc: Salowey, Joe; 'Beck01, Wolfgang'
> Subject: RE: Issue 79; digest-auth realm validation
>=20
> I agree with you David.  Then perhaps not using shoulds or=20
> may. Even better
> saying:
>=20
>    "A RADIUS MUST check if the RADIUS=20
>    client is authorized to
>    serve users of the realm mentioned in the Digest-Realm=20
> attribute.  If
>    the RADIUS client is not authorized, the RADIUS server sends an
>    Access-Reject.  Other actions taken by the RADIUS server=20
> are out of scope of this document however, the RADIUS server=20
> should notify the operator and may take additional=20
>    action such as rejecting all future
>    requests from this client, until some management action tells it to
>    do so again. "
>=20
> Note above I use Access-Reject but it may still be better to=20
> silently discard.
>=20
[Joe] I'm okay with this wording. I'm also open to the silent discard
behavior if enough people really prefer that.    =20

> > -----Original Message-----
> > From: Nelson, David [mailto:[email-masked]]
> > Sent: Monday, April 04, 2005 4:53 PM
> > To: [email-masked]
> > Subject: RE: Issue 79; digest-auth realm validation
> >=20
> >=20
> > Avi Lior writes...
> >=20
> > > I think that the actions such as informing the operator is=20
> > > informative text and not normative text and therefore we=20
> should use=20
> > > lowercase "SHOULD".
> >=20
> > Two comments: First, which parts of an RFC are typically considered=20
> > informative? The various "Considerations"
> > sections? Others? Second, I don't think that using lower case to=20
> > indicate informative usage is a good idea, as it leads to confusion.
> > =20
> > > Note that the IMO the whole discussion should be included in the
> > security
> > > section.
> >=20
> > I guess that depends on whether one wishes to include a solution to=20
> > the issues/concerns within the body of the specification,=20
> or simply to=20
> > lament about the lack of (inability to provide) a solution in the=20
> > Security Considerations section.  :-)
> >=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
>=20

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

Delivery-date: Mon, 04 Apr 2005 21:22:36 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Cc: "'Salowey, Joe'" <[email-masked]>, "'Beck01, Wolfgang'" <[email-masked]>
Subject: RE: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 17:22:22 -0400 

I agree with you David.  Then perhaps not using shoulds or may. Even better
saying:

   "A RADIUS MUST check if the RADIUS 
   client is authorized to
   serve users of the realm mentioned in the Digest-Realm attribute.  If
   the RADIUS client is not authorized, the RADIUS server sends an
   Access-Reject.  Other actions taken by the RADIUS server are out of scope
of this document however, the RADIUS server should notify the operator and
may take additional 
   action such as rejecting all future
   requests from this client, until some management action tells it to
   do so again. "

Note above I use Access-Reject but it may still be better to silently
discard.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, April 04, 2005 4:53 PM
> To: [email-masked]
> Subject: RE: Issue 79; digest-auth realm validation
> 
> 
> Avi Lior writes...
> 
> > I think that the actions such as informing the operator is
> > informative text and not normative text and therefore we should 
> > use lowercase "SHOULD".
> 
> Two comments: First, which parts of an RFC are typically 
> considered informative? The various "Considerations" 
> sections? Others? Second, I don't think that using lower case 
> to indicate informative usage is a good idea, as it leads to 
> confusion.
>  
> > Note that the IMO the whole discussion should be included in the
> security
> > section.
> 
> I guess that depends on whether one wishes to include a 
> solution to the issues/concerns within the body of the 
> specification, or simply to lament about the lack of 
> (inability to provide) a solution in the Security 
> Considerations section.  :-)
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message 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, 04 Apr 2005 20:54:04 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 16:53:28 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> I think that the actions such as informing the operator is=20
> informative text and not normative text and therefore we should=20
> use lowercase "SHOULD".

Two comments: First, which parts of an RFC are typically considered
informative? The various "Considerations" sections? Others? Second, I
don't think that using lower case to indicate informative usage is a
good idea, as it leads to confusion.
=20
> Note that the IMO the whole discussion should be included in the
security
> section.

I guess that depends on whether one wishes to include a solution to the
issues/concerns within the body of the specification, or simply to
lament about the lack of (inability to provide) a solution in the
Security Considerations section.  :-)

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

Delivery-date: Mon, 04 Apr 2005 20:43:50 +0000
From: Avi Lior <[email-masked]>
To: "'Salowey, Joe'" <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 16:43:24 -0400 

Hi,

See comments inline.

> -----Original Message-----
> From: Salowey, Joe [mailto:[email-masked]] 
> Sent: Monday, April 04, 2005 1:09 PM
> To: Beck01, Wolfgang; [email-masked]
> Cc: [email-masked]
> Subject: RE: Issue 79; digest-auth realm validation
> 
> 
>  
> 
> > -----Original Message-----
> > From: Beck01, Wolfgang [mailto:[email-masked]]
> > Sent: Monday, April 04, 2005 1:52 AM
> > To: [email-masked]; Salowey, Joe
> > Cc: [email-masked]
> > Subject: Re: Issue 79; digest-auth realm validation
> > 
> > Here's a complete 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.
> > 
> >    Correlation between User-Name and SIP-AOR AVP values is
> > required just
> >    to avoid that any user can register or misuse a SIP-AOR 
> > allocated to
> >    another user.
> > 
> >    A RADIUS server MUST check if the RADIUS client is authorized to
> >    serve users of the realm mentioned in the Digest-Realm
> > attribute.  If
> >    the RADIUS client is not authorized, the RADIUS server 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.
> > 
> > Please send me a note if you have objections/additions about
> > this text so we can close the issue.
> 
> [Joe] As Avi mentioned in a previous message this gets a bit 
> complicated in a case where you have proxies under different 
> administrative control. In this case the AAA server that 
> perfroms the digest auth may not have detailed information 
> about the client to realm authorization.  In this case one of 
> the intermediate proxies could be resposible for the 
> authorization check.  It might also be worthwile to warn 
> about the use of the digest-HA1 attribute and MD5 (vs. 
> MD5-SESS) algorithm in the security considerations.  Also I 
> suppose that the action to reject is up to the operator. Here 
> are some suggested revisions:
> 
>    "A RADIUS server in the RADIUS proxy chain MUST check if 
> the RADIUS 
>    client is authorized to
>    serve users of the realm mentioned in the Digest-Realm 
> attribute.  If
>    the RADIUS client is not authorized, the RADIUS server sends an
>    Access-Reject.  The RADIUS server should consider this client as
>    compromised.  It SHOULD notify the operator and MAY take 
> additional 
>    action such as rejecting all future
>    requests from this client, until some management action tells it to
>    do so again. "

So you intend that servers in the proxy chain to the check?  If yes that is
not always possible.  Some servers are truly pass through.

Instead of sending an Access Reject I think we should silently discard.
However, the penalty of doing so is that the Client will never know why and
its not receiving an Access-Accept or Access-Reject and if it is simply a
misconfigured client it will turn off that RADIUS server.  Also note that no
one is proposing to use put in a reason in the Access-Reject as to why we
are rejecting.

I think that the actions such as informing the operator is informative text
and not normative text and therefore we should use lowercase "SHOULD".

Note that the IMO the whole discussion should be included in the security
section.    

> In the security considerations section:
> 
>   "When used with the MD5 algorithm the digest-HA1 attribute contains
>    a hash value that can be used by an attacker in a dictionary
>    attack against the user's password.  This mechanism should only be 
>    used in environments where there is sufficient trust in 
> intermediate 
>    RADIUS proxies and RADIUS client requests can be validated against 
>    their authorized realm.  "
> 
> 
> > 
> > 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/>
> 

--
to unsubscribe send a message 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, 04 Apr 2005 17:06:34 +0000
content-class: urn:content-classes:message
Subject: RE: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 10:08:42 -0700
From: "Salowey, Joe" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:[email-masked]]=20
> Sent: Monday, April 04, 2005 1:52 AM
> To: [email-masked]; Salowey, Joe
> Cc: [email-masked]
> Subject: Re: Issue 79; digest-auth realm validation
>=20
> Here's a complete text proposal:
>=20
>    The RADIUS server MUST check if the user identified by the=20
> 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
>    Correlation between User-Name and SIP-AOR AVP values is=20
> required just
>    to avoid that any user can register or misuse a SIP-AOR=20
> allocated to
>    another user.
>=20
>    A RADIUS server MUST check if the RADIUS client is authorized to
>    serve users of the realm mentioned in the Digest-Realm=20
> attribute.  If
>    the RADIUS client is not authorized, 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.
>=20
> Please send me a note if you have objections/additions about=20
> this text so we can close the issue.

[Joe] As Avi mentioned in a previous message this gets a bit complicated
in a case where you have proxies under different administrative control.
In this case the AAA server that perfroms the digest auth may not have
detailed information about the client to realm authorization.  In this
case one of the intermediate proxies could be resposible for the
authorization check.  It might also be worthwile to warn about the use
of the digest-HA1 attribute and MD5 (vs. MD5-SESS) algorithm in the
security considerations.  Also I suppose that the action to reject is up
to the operator. Here are some suggested revisions:

   "A RADIUS server in the RADIUS proxy chain MUST check if the RADIUS=20
   client is authorized to
   serve users of the realm mentioned in the Digest-Realm attribute.  If
   the RADIUS client is not authorized, the RADIUS server sends an
   Access-Reject.  The RADIUS server should consider this client as
   compromised.  It SHOULD notify the operator and MAY take additional=20
   action such as rejecting all future
   requests from this client, until some management action tells it to
   do so again. "

In the security considerations section:

  "When used with the MD5 algorithm the digest-HA1 attribute contains
   a hash value that can be used by an attacker in a dictionary
   attack against the user's password.  This mechanism should only be=20
   used in environments where there is sufficient trust in intermediate=20
   RADIUS proxies and RADIUS client requests can be validated against=20
   their authorized realm.  "

>=20
> Wolfgang
>=20
> --
> T-Systems
> Next Generation IP Services and Systems
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany=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: Mon, 04 Apr 2005 17:04:24 +0000
From: Avi Lior <[email-masked]>
To: "'Beck01, Wolfgang'" <[email-masked]>, [email-masked],  [email-masked]
Cc: [email-masked]
Subject: RE: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 13:03:52 -0400 

Hi Wolfgang,

See inline:

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:[email-masked]] 
> Sent: Monday, April 04, 2005 4:52 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Issue 79; digest-auth realm validation
> 
> 
> Here's a complete 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.
> 
>    Correlation between User-Name and SIP-AOR AVP values is 
> required just
>    to avoid that any user can register or misuse a SIP-AOR 
> allocated to
>    another user.
> 
>    A RADIUS server MUST check if the RADIUS client is authorized to
>    serve users of the realm mentioned in the Digest-Realm 
> attribute.  If
>    the RADIUS client is not authorized, the RADIUS server 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.

I think if the realm check fails, IMO RADIUS should silently-discard and
log/report.

I don't think it should ignore any further traffic from that client.  After
all, it may not be the client that is compromized but rather another RADIUS
Client in the proxy chain.  Anyway, whether we ingnore traffic or not will
really depend on how RADIUS is being deployed here and should therefore be a
deployment issue.

> Please send me a note if you have objections/additions about 
> this text so we can close the issue.
> 
> 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/>
> 

--
to unsubscribe send a message 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, 04 Apr 2005 14:23:10 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: AW: AW: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 16:22:33 +0200 

> So you basically stop in the RADIUS server processing further 
> requests that come from the same RADIUS client?
yes.
> How do you identify the RADIUS client, is it by its IP address?
yes, and by a shared secret. But I am not sure whether current RADIUS
server APIs support this.

> 
> What I am trying to avoid is that this "compromise" prevents 
> that RADIUS server to process legitimate requests coming from a RADIUS 
> client just because an attacker wrote a forged RADIUS request to preclude that 
> client to be operating anymore.
This would be a quite effective DoS attack. But Message-Authenticator is mandatory
now and should make forging RADIUS requests much harder.

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: Mon, 04 Apr 2005 13:13:40 +0000
Date: Mon, 04 Apr 2005 15:58:41 +0300
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: AW: Issue 79; digest-auth realm validation

So you basically stop in the RADIUS server processing further requests 
that come from the same RADIUS client? How do you identify the RADIUS 
client, is it by its IP address?

What I am trying to avoid is that this "compromise" prevents that RADIUS 
server to process legitimate requests coming from a RADIUS client just 
because an attacker wrote a forged RADIUS request to preclude that 
client to be operating anymore. If you can avoid this case I am fine, 
otherwise, I have a problem with it.

/Miguel

Beck01, Wolfgang wrote:

> Miguel wrote:
> 
>>I have a question:
>>
>>What is the intention of this text:
>>
>>    "The RADIUS server considers this client as
>>    compromised. "
>>
>>What is this consideration? Is it that the RADIUS server marks 
>>"something" as "not being able to use the HTTP or SIP service 
>>any longer"?
> 
> "something" -- the RADIUS client that sent a Digest-Realm with a
> realm it is not allowed to speak for.
> Joe's reasoning was that this can be a sign of compromised
> RADIUS client. If a RADIUS client is compromised, it's better
> not to process any requests from it until the situation has
> been resolved.
> 
> So your proposal would be just to drop the reject the request
> with the offending Digest-Realm attribute?
> 
> 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/>

-- 
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: Mon, 04 Apr 2005 11:51:16 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: AW: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 13:50:52 +0200 

Miguel wrote:
> I have a question:
> 
> What is the intention of this text:
> 
>     "The RADIUS server considers this client as
>     compromised. "
> 
> What is this consideration? Is it that the RADIUS server marks 
> "something" as "not being able to use the HTTP or SIP service 
> any longer"?
"something" -- the RADIUS client that sent a Digest-Realm with a
realm it is not allowed to speak for.
Joe's reasoning was that this can be a sign of compromised
RADIUS client. If a RADIUS client is compromised, it's better
not to process any requests from it until the situation has
been resolved.

So your proposal would be just to drop the reject the request
with the offending Digest-Realm attribute?

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: Mon, 04 Apr 2005 09:29:46 +0000
Date: Mon, 04 Apr 2005 12:23:02 +0300
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Issue 79; digest-auth realm validation

I have a question:

What is the intention of this text:

    "The RADIUS server considers this client as
    compromised. "

What is this consideration? Is it that the RADIUS server marks 
"something" as "not being able to use the HTTP or SIP service any longer"?

I hope it does not mean that the RADIUS server marks the user in a black 
list or something similar.

I hope also that we can focus on the technical aspects of the protocol, 
and leave the issue of alarms, sirens, urgent e-mails and alike for the 
designers of products. I am not referring to this other paragraph:

    "It notifies the operator and rejects all future
    requests from this client, until some management action tells it to
    do so again."

/Miguel

Beck01, Wolfgang wrote:

> Here's a complete 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.
> 
>    Correlation between User-Name and SIP-AOR AVP values is required just
>    to avoid that any user can register or misuse a SIP-AOR allocated to
>    another user.
> 
>    A RADIUS server MUST check if the RADIUS client is authorized to
>    serve users of the realm mentioned in the Digest-Realm attribute.  If
>    the RADIUS client is not authorized, the RADIUS server 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.
> 
> Please send me a note if you have objections/additions about this text so
> we can close the issue.
> 
> 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/>
> 

-- 
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: Mon, 04 Apr 2005 08:53:02 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Issue 79; digest-auth realm validation
Date: Mon, 4 Apr 2005 10:52:11 +0200 

Here's a complete 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.

   Correlation between User-Name and SIP-AOR AVP values is required just
   to avoid that any user can register or misuse a SIP-AOR allocated to
   another user.

   A RADIUS server MUST check if the RADIUS client is authorized to
   serve users of the realm mentioned in the Digest-Realm attribute.  If
   the RADIUS client is not authorized, the RADIUS server 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.

Please send me a note if you have objections/additions about this text so
we can close the issue.

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: Sat, 02 Apr 2005 17:58:35 +0000
Date: Sat, 2 Apr 2005 09:57:38 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Last Call on Chargeable UserId Draft

This is an announcement of RADEXT WG last call on the Chargeable UserId
Draft prior to sending the document to the IESG for consideration as a
Proposed Standard.

The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-04.txt

RADEXT WG last call will last until Monday, April 18, 2005.  Please send
comments to the RADEXT WG mailing list ([email-masked]) in the
Issues format described on the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Fri, 01 Apr 2005 21:57:44 +0000
Date: Fri, 1 Apr 2005 13:57:29 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Salowey, Joe" <[email-masked]>
cc: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: RE: Issue 79; digest-auth realm validation

> [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.

Yes, I don't see this either.  Unless this document is attempting to
modify existing RADIUS proxy behavior, a proxy will automatically forward
an Access-Request containing a User-Name attribute with an NAI as it would
any other Access-Request.  So if the User-Name contains
"[email-masked]" and that proxy is set up with a route to cisco.com
then it will forward the Access-Request to the indicated RADIUS server.

> [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.

Yes, I agree this appears possible.

> [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.

In fact, these attacks have already been carried out by Web servers and
have been used to compromise credentials via offline dictionary attacks.
So they are quite real.

--
to unsubscribe send a message 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, 01 Apr 2005 21:44:35 +0000
Date: Fri, 1 Apr 2005 13:43:56 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, o verview section

Yes, that would be helpful.

On Thu, 24 Mar 2005, Beck01, Wolfgang wrote:

> > > 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/>
>

--
to unsubscribe send a message 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, 01 Apr 2005 18:45:27 +0000
Content-class: urn:content-classes:message
Subject: Minutes of the RADEXT session at IETF62
Date: Fri, 1 Apr 2005 13:44:15 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Please review these minutes and reply to the list with any errors or =
omissions.

Minutes of the RADEXT WG session at IETF62
Wednesday, March 9, 2005 1530 - 1730
Hilton Minneapolis
Rochester Room

Notes taken by Paul Condgon and John Vollbrecht and edited by Dave =
Nelson.
=20
Agenda: =
http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext-agenda.ppt
Slides: http://www.drizzle.com/~aboba/IETF62/radext/
Issues Tracker: http://www.drizzle.com/~aboba/RADEXT
=20

1. Agenda Bashing: The published agenda was set for 2.5 hours but we =
were switched into a 2.0 hour session slot. Agenda will be reshuffled to =
fit in 2 hours because few wanted to cut short the dinner hour.  Will =
start the capabilities discovery discussion at a fixed time.

2. Document status was covered=20
 =20
3. Milestones need to be updated on web site.  Proposed revision is:

- Done=A0=A0  RFC 2486bis submitted as a Proposed Standard RFC
- May 05=A0=A0RADIUS digest auth draft submitted as a Proposed Standard =
RFC
- Jun 05=A0=A0Updates to RFC 2618-2621 RADIUS MIBs submitted for =
publication
- Jul 05  RADIUS CUI draft submitted as a Proposed Standard RFC
- Dec 05=A0=A0RFC 3576 MIBs submitted as an Informational RFC
- Dec 05=A0=A0RADIUS design guidelines submitted as an Informational RFC
- Jul 06=A0(W)LAN attributes draft submitted as a Proposed Standard RFC
- Sep 06=A0=A0RADIUS issues and fixes draft submitted as an =
Informational RFC
- Dec 06=A0=A0RADIUS Prepaid draft submitted as a Proposed Standard RFC
=20
4. Jari Arkko on 2486bis status - updated NAI.
draft-ietf-radext-rfc2486bis-05.txt

-- Document has been sent to IESG and has a single issue.  Some minor =
modifications a have been made.

-- Extended to use international characters, but UTF-8 is a problem.  =
Needs to be made clear in the ABNF.
=20
-- Issue 18n includes a question about unassigned code points. Should =
they be prohibited or allowed?  Approach is to prohibit them from a =
specification perspective.=20

-- Related issue with ! syntax.   Unclear what to do and we need the =
help of internationalization gurus.  Username part may have different =
rules from IDN part of the NAI.

-- Chairs will solicit consultation from an expert in =
internationalization issues.

-- Conversation to be moved to list.

5. Wolfgang Beck on auth digest draft
draft-ietf-radext-digest-auth-01.txt
=20
-- There are several security design alternatives; encryption per =
RFC2868, wait for draft-zorn-radius-encattr or mandate IPSec if RADIUS =
client supports TLS.  Concern about the draft-zorn... being "late" (now =
an individual submission).  Wolfgang believes the IPSec solution is the =
only viable option.
=20
-- Concern about encrypted RADIUS attributes not providing the same =
level of protection as TLS (or IPSec). It was pointed out that most =
operators already protect their RADIUS traffic, but there is some debate =
about this.
=20
-- Other misc. changes in the works regarding alignment with =
diameter-sip-app, digest-Qop, multiple authorization, and document =
re-arranging.=20

-- There is a comment that the parameters being included in the SIP-AOR =
are not properly discussed in the draft.

6. Avi Lior on the CUI draft
draft-ietf-radext-chargeable-user-id-03.txt
=20
-- All issues in the tracker have been addressed to date.  One issues =
raised recently, but not in the tracker yet.  Resolution has been agreed =
on the list. Requesting that the document move to WG last call.

7. Dave Nelson on the base MIBs Revision
draft-nelson-rfc2618bis-00.txt
draft-nelson-rfc2619bis-00.txt
draft-nelson-rfc2620bis-00.txt
draft-nelson-rfc2621bis-00.txt
=20
-- Asked to update the current set of four MIBs.  There are now four =
drafts that update, but not obsolete the existing RFCs.
=20
-- Added support for IPv4/IPv6 textual conventions.  Using the SMI =
AUGMENTS syntax to perform the update and non-obsolesce of the existing =
objects.=20

-- To advance these, there will need to be updates to the boilerplates.=20

-- Has been some informal MIB Doctor review and will be requesting =
formal review and recommend they become WG documents.
=20
-- Dan Romascanu doesn't believe that the boilerplate needs to be =
updated.  Dave Harrington is the one who made this assertion, in his =
slides at IETF60/58.  This is only related to the Standards Track MIBs.  =
The AD wasn't clear what the procedure is.
=20
-- Glen Zorn would like to see the current Standard Track MIBs move to =
Draft Standard status.  We need to understand what all is implied by =
taking this action.

8. Greg Webber on the RFC3576 MIBs=20
draft-decnodder-radext-dynauth-client-mib-03.txt
draft-decnodder-radext-dynauth-server-mib-03.txt

-- This adds support for the new extensions in 3675.  Addresses =
IPv6/IPv6 textual conventions.
=20
-- Four issues are noted: 31, 44, 45, 48.  Various changes to support =
the resolution of these issues.=20

-- Proposed to make these a WG item.  The WG seems to agree.  Validate =
on the list.

9. Mauricio Sanchez on the IEEE 802 Attributes
draft-congdon-radext-ieee802-03.txt
=20
 -- Avi Lior and Farid Adrangi have contributed to this as well and =
should be noted as authors.
=20
-- Because of overlap, the draft-lior-redirection draft has been merged =
in and some changes to the format were made.  The redirection draft was =
dropped.=20
=20
-- NAS-Filter-Rule supports L2 filters now and supports a flush action.

-- 802.11i Key attributes were removed to avoid NIST issues. It was =
noted that all 802.11 attributes were pulled and they shouldn't have =
been.=20

-- The dropping of the Key attributes is a concern by Glen Zorn.  Since =
NIST has a bad track record of responding in a predictable timeframe, we =
don't want to create a dependency.=20

-- Key attributes were copied for Key space so the code points already =
exist, so therefore some of these already exist.=20

-- Several issues have been addressed: 37, 38, 39.=20

-- Will bring back non-key related attributes for 802.11.

-- The TNC of the TCG is interested in these attributes, so is 3GPP.  =
John Vollbrecht will present on the TCG/TNC in the EAP WG tomorrow.

-- Next steps involve incorporating the capabilities discovery direction =
of the group, more formatting of NAS-Filter-Rule and its syntax, improve =
document flow, considering a title change.=20

-- Other SDOs depend on this, so rapid progress is necessary.=20

-- Question about the extended attribute usage being removed. Glen Zorn =
is happy about this.
=20
-- Question about accounting records used on redirect.  There is a stop =
and start used, but could there be a single record?  Avi Lior believes =
it is possible to do this and an Interim should be used.

10. Dave Nelson on Management Authorization Attributes
draft-nelson-radius-management-authorization-01.txt=20
=20
-- Currently two attributes for management; CLI, privileged and =
non-privileged.  The draft would like to extend this for SNMP and HTTP =
management.  Would like the extend the privilege levels, support SSH, =
create a label for policy scope, leverage split horizon views of =
management, and do this on a per-command basis (parity with TACACS+)... =
a lot of improvements.
=20
-- The design is to add a Framed-Management service type and a =
Management-Access-ID (label), Management-Protocol, =
Non-Framed-Management-Command and operation, Management-Context for =
logging and human consumption.=20

-- Today Enterasys uses VSA and believe that there is value in =
multi-vendor environment so would like to open them up.  Would like to =
ask that this become a WG item.  Poll of the room indicated about six to =
eight interested parties.  Will validate on the list.
=20
-- Glen Zorn questions the wisdom of using RADIUS accounting for an =
audit log of command line changes because of the size of Radius logs - =
perhaps syslog would be better.
=20
-- Unclear how this works with SNMP.   The idea is it would leverage the =
ISMS WG work.  The ISMS group should certainly review this and an action =
was taken to put them in the loop.
=20
-- The ISMS scope, however, does not cover management access control.=20

-- Dave Perkins asks if some of the other functionality is to provide =
parity with TACACS+.  Yes, some of this is going to address that, but =
there is also the goal of addressing other management interfaces other =
than CLI.  Dave Perkins points out that it is hard to do =
command-by-command authorization because you need to understand the =
level within the CLI you are operating at.  Greg Weber indicated that =
the Management-Context attribute is defined to address this.

11. Avi Lior on Prepaid Extensions
draft-lior-radius-prepaid-extensions-07.txt=20
=20
-- Now at draft 7.  During IETF60 they were at draft 5.  A number of =
changes identified in the slides.=20

-- Interesting complexities defined to transfer prepaid credit from the =
NAS to the device.

-- The goal is to be similar to Diameter Credit Control, but integration =
will be hard to do.  There are differences between Quotas in the two =
schemes; one is a delta the other is absolute.  More thought needed =
here.=20

-- Is the draft dependent on RFC3576?  No, according to Avi Lior, but =
some disagreement on this.  Any dependency can be taken out, but it =
would be good to have it in.

12. Avi Lior on Bandwidth Parameters
draft-lior-bandwidth-capability-00.txt=20
=20
-- Draft has been thrashing about.  The current draft strives towards =
simplicity with a simple set of attribute with reasonable tightness.=20

-- There are ingress and egress bandwidth attributes, and a Bandwidth-ID =
for labels (similar to Filter-ID).  Can use either of these, but not =
both at the same time.=20

-- There is a capability to advertise, select and confirm bandwidth =
usage. Ability to update these dynamically as well.  Mutual agreement =
among the parties?

-- Reporting via start/stop or interim and the NAS decides which way it =
wants to do this.

-- Bernard claims this draft has grown way out of scope.  Need =
discussion on what is the appropriate set of functionality=20
=20
-- Question about the Bandwidth-Profile-ID and what are the scalability =
issues?   Should it be part of the Filter-Rule attributes?  Avi Lior =
believes it would be a bad idea to overload Filter-Rule with bandwidth =
as well.

13. Dave Nelson on RADIUS Issues and Fixes
=20
-- Kicking off a discussion on problems and points of confusion in =
existing RADIUS RFCs.  Not to be used for new functionality.  Goal is an =
informational RFC.=20

-- Glen Zorn questions how we fix problems if we can't add new =
functionality.    Dave Nelson recommends that we document the issues and =
then consider fixes that might require a re-charter, i.e. a normative =
change to existing RADIUS RFCs, on a case-by-case basis.
=20
-- Slides presented list a large number of current issues and =
clarifications to be addressed.
=20
-- Next steps are to get discussion on the issues and begin a draft.  =
Dave will kick off as editor but would like someone else to take over at =
some point soon.

14. Greg Weber on RADIUS usage in L2PVN WG
draft-ietf-l2vpn-radius-pe-discovery-01.txt=20
=20
-- A current working group item in this group.  How to provision =
customer equipment as it joins a provider network and determine the set =
of interconnected pseudo-wires. =20

-- This is not a traditional use of RADIUS because it is authenticating =
equipment not users, but still using User-Name to identify the customer =
equipment.=20

-- Accounting hasn't been addressed much yet.  Looking into scalability =
concerns.  There is a big question around how 'zero-touch' can be =
supported?  Would like to get customer equipment with credentials so it =
could do something like 802.1X.  This is really how devices are being =
provisioned and authenticated into the network.=20

-- Are there any dependencies?  No objective to do this.  Does RADEXT =
really need to look at this other than provide expertise review?=20

-- There is some concern about using complex and formatted radius =
attributes with structure as this proposes.   There is a general concern =
about how to represent complex attributes such as NAS-Filter-Rule in 802 =
extensions.

15. Jari Arkko on Policy Decisions for Multiple Services
draft-arkko-radext-multi-service-decisions-01.txt=20

-- Work from EAP lower layer efforts.  A single subscription can have =
access to multiple services and providers may have to apply policies on =
how to allow access.=20

-- This is only a problem in roaming environments.  How to identify =
virtual services links such as PANA or IPSec. What is the NAS-Port-Type =
for these?  It might be better for NAS-Port-Type to represent the =
physical port and use something else to represent the virtualized or =
higher-layer.   Unclear that tunnel-type would be a good option either.  =
Perhaps the combination of NAS-Port-Type and Tunnel-Type to describe =
this.=20

-- Several issues with how to use tunnel attributes for these virtual =
services in the slide.  Should there be a definition of something new or =
a clarification of how to use existing attributes?   It was pointed out =
that this is somewhat like the management attributes being defined =
because of using Radius in new ways.  This advocates creating new =
attributes for this.

-- What happens if the NAS "lies"?

-- Several people are interested in the problem, but no-one has a =
solution yet.  Next steps are to put this document into the pre-working =
group item review list.

16. Avi Lior on RADIUS Location Attributes (GEOPRIV WG)
draft-ietf-geopriv-radius-lo-02.txt

-- A number of GeoPriv issues were discussed from the slides=20

-- One particular resolution is to add a capability attribute.=20

-- Dave Nelson points out that this is another space where guidance on =
structured attributes would help=20

-- Jari Arkko comments on Issue 70.  He believes it is a requirement =
that a policy must be followed if the client demands it, but there is no =
link layer that advertises the clients demands.  Somehow it would be =
good if the client could tell the NAS that it didn't want the =
information to be transferred.=20

-- All the GeoPriv wants to do is be able to advertise location, but =
there are requirements to advertise additional objects that are location =
related.  There is a proposal to have an additional type of location =
information beyond civic and geographical to allow this information to =
be advertised.  This issue has been raised in the GeoPriv WG=20

-- There is a question about which device has location information about =
what entities and what is advertised?  There is location of NAS and of =
end-user which are separate.   How would a NAS get location information =
of the user?  Avi points out the goals are to get user location =
information, and if the user can't do this or there is no channel to =
communicate this, the NAS may use other information to represent the =
user's location with reduced capability.

-- This discussion was taken offline to the list.

17. Avi Lior on RADIUS Capability Exchange=20

-- There has been a lot of discussion around NASes advertising their =
capabilities and this draft attempts to capture this and the =
requirements for capability advertisement.=20

-- There are cases where the home AAA server needs to know what the NAS =
is capability of to properly provision services and policies (e.g. =
prepaid)=20

-- There are cases where the NAS would like to tell the AAA server that =
it needs to see certain attributes.=20

-- There are cases where the AAA server would like to get something =
specific from the NAS.=20

-- There are issues with how to represent granularity of the =
capabilities.=20

-- This mechanism is really necessary to implement mandatory attribute =
requirements.=20

-- A question is if this implies that the server needs to be stateful, =
and now does the NAS need to advertise this in every access request?  =
The goal would be to keep the server stateless.  If the info is small it =
might not be a problem to include in each exchange.=20

-- What are the scenarios for capability exchange seen in Diameter?=20

-- Glen Zorn believes the exchange makes more sense when there is a =
persistent session between the NAS and server.  The NAS support won't =
change session to session, but if we don't want the Radius server to =
keep NAS state then how will it understand the capabilities?  The =
concept of a permanent session between the NAS and the server is really =
about keeping state.=20

-- Jari Arkko points out that we are really doing both policy and =
capability advertisement.

End-of-meeting.

Regards,
=A0
Dave
=A0
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330=A0=20
E-mail: [email-masked]
=A0

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

Delivery-date: Fri, 01 Apr 2005 00:14:20 +0000
Date: Thu, 31 Mar 2005 16:13:16 -0800
From: Murtaza Chiba <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Review of draft-chiba-radius-dynauthor-ext-00.txt

All,

Since we are on the topic of adding items to the WG.  I would like to 
propose that this draft be considered as well.

Some views/comments inline.

Bernard Aboba wrote:
> RFC 3576 introduced the concept of dynamic authorization to RADIUS, where
> a session that had previously been authorized can be terminated or
> modified by an exchange initiated by the RADIUS server.
> 
> In order to be able to utilize the facilities introduced in RFC 3576, it
> is necessary for the server initiating a CoA or Disconnect-Request to have
> kept state on the session it is looking to modify.  This includes
> recording the NAS with which the session was initiated (NAS-IP-Address,
> NAS-Identifier, NAS-IPv6-Address) as well as the session itself
> (User-Name, NAS-Port, Framed-IP-Address, Called-Station-Id,
> Calling-Station-Id, Acct-Session-Id, Acct-Multi-Session-Id, NAS-Port-Type,
> NAS-Port-Id, Originating-Line-Info, Framed-Interface-Id,
> Framed-IPv6-Prefix).
> 
> However, since RADIUS Accounting packets may be lost, it is possible for
> the state on the server to have gotten out of sync.  For example, an
> accounting server may not receive an Accounting STOP, and therefore may
> think that a session continues when in fact it had ended.  It is also
> possible for an Accounting Start or Interim message to be lost in which
> case the server may not be aware that it had started (until a subsequent
> Interim or STOP message is received).
> 
> In these circumstances, it is possible for a server initiating a CoA or
> Disconnect-Request to receive an error message in response, indicating
> that the session did not exist.
> 
> Where this occurs, how can the server resynchronize its state?  Note that
> to achieve the resynchronization it may not be sufficient just to retrieve
> the current state of the NAS that responded with an error;  the session
> may have moved elsewhere, and that Accounting message may have been lost
> too (e.g. the server knows of no other session on another NAS with the
> same multi-session-id).
> 
> In order to address this problem, the document introduces a Query-Select
> attribute, enabling a server to query for sessions of a given type.
> 
> The query syntax is quite general, allowing a number of attributes to be
> returned based on whether the service or expression matching.
> 
> Since modern NAS devices can be very large, supporting hundreds of
> sessions, it does seem necessary to be able to support selective queries,
> since a complete dump of NAS session state could easily exceed the maximum
> RADIUS packet size of 4096 octets.
> 

Besides the above being an excellent justification, it should be noted 
that, modern networks now include elements such as the web portal. 
These elements use state information other than the traditional 
"billable" state that is found in Accounting-Requests.

> However, the query syntax introduces an entirely new "URI"-based model for
> RADIUS service types, which has no precedent within previous RADIUS
> documents.  The query syntax also appears to be more complex than is
> required to solve the problem as stated above.  Many NAS devices remain
> short of resources, so that they cannot support complex queries such
> as is proposed here.
> 

The URI based model proposed provides a degree of flexibility and is not 
intended to be used for complex querying.

> For example, in order to attempt to locate the sessions of a given user,
> an equality query for the User-Name attribute would be sufficient.  The
> same could be said of other session attributes; there is no need to do
> other types of comparisons on such session identifiers.
> 

Agreed.  The draft however proposes to give the ability to drill down to 
a specific detail.   For example, many devices now support the notion of 
'services' that may be deployed for a given session, with each 'service' 
affecting a partial/complete data-flow for a given session.  For 
instance, an MP3 'service' would be treated differently from a data 
'service' which would itself be treated differently from a 
video-on-demand 'service'.

Service Providers are now looking at opportunities to generate revenue 
by providing QoS guarantees on these different 'services' with policies 
in effect to guarantee SLAs.  In order to do this, a greater detail of 
state information is required besides a need to gain more current 
information than can be gotten from interim updates.

Also, these 'services' themselves may be comprised of multiple feature 
sets that may individually need to be targetted.

With all of the above considerations, the draft attempts to provide a 
flexible querying mechanism.  Hopefully, we can agree on a limited scope 
for this and the authors would definitely appreciate all feedback.

> The other element this document introduces is the Authorization-Command.
> attribute.  The only value of this attribute used is "Query-Only", used
> for the query functionality described earlier.
> 
> Since there are already multiple RADIUS command codes defined for resource
> querying (23 = Resource-Query-Request, 24 = Resource-Query-Response) it is
> not clear why this new attribute is needed.  RFC 2882 describes these
> commands, but does not provide details on their functionality, and as a
> result, it is not clear that whether the functionality provided in this
> document already exists.
> 

Besides Resource Querying there is a need to start/stop 'services' on 
demand.  The Authorization-Command would eventually include all use cases.

> RFC 3575 includes the following language relating to allocation of new
> RADIUS command codes:
> 
> Packet
>    Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an
>    IETF RFC, but are reserved until a specification is provided for
>    them.  This is being done to avoid interoperability problems with
>    software that implements non-standard RADIUS extensions that are or
>    have been in use on the Internet.  Because a new Packet Type has
>    considerable impact on interoperability, a new Packet Type Code
>    requires IESG Approval.  The intention is that any allocation will be
>    accompanied by a published RFC.  Type Codes 52-249 should be
>    allocated first; when these are exhausted, Type Codes 14-20, 35-39,
>    46-49 may be allocated.  For a list of Type Codes, see Appendix A.
> 
> And Service-Type values:
> 
>    The exception to this policy is
>    the Service-Type attribute (6), whose values define new modes of
>    operation for RADIUS.  Values 1-16 of the Service-Type attribute have
>    been allocated.  Allocation of new Service-Type values are by IETF
>    Consensus.  The intention is that any allocation will be accompanied
>    by a published RFC.
> 
> Between command codes and Service-Type values, it seems to me that the
> functionality required in this document can be covered, so that allocating
> a new Authorization-Command attribute is not necessary or desirable.
> 

As RADIUS has been adopted for the more recent use cases, beyond that of 
the original dial world, its values now represent a mixed bag of loosely 
coupled information.   In its original form it was used to denote the 
type of connection allowed for the user.  In more recent times its been 
used for indicating resource management command "Authorize-Only" and in 
the RFC3576 a complete behaviour has been encoded(send Access-Request). 
  Hence, it was felt that a new attribute would better serve the draft 
if its contents had clearly related values.

Regards,
Murtaza

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

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