Subject: Status of draft-lior-radius-prepaid-extensions?
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Date: Mon, 31 Jul 2006 15:48:14 -0700

Hi.  I'm just wondering if this is going to be adopted as a WG item,
published as an individual submission or ?  Given that there are
apparently at least a couple of independent, interoperable
implementations it seems a bit silly to let it die on the vine...

~ gwz

The Color Brown is a trademark.

--
to unsubscribe send a message 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, 31 Jul 2006 21:58:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Consensus Call:  "Sense of the Room" at RADEXT WG meeting at IETF 66
Date: Mon, 31 Jul 2006 14:57:11 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> At the RADEXT WG meeting at IETF 66, we took a "sense of the room"
> with respect to what the WG should do with respect to the exhaustion
> of the  
> RADIUS standard attribute space.   A  consensus appeared to emerge. 
> We 
> would now like to confirm that consensus on the RADEXT WG mailing
> list. 
> 
> In your reply to this message, please state whether you support the
> consensus described below, or whether you disagree with it (and if
> so, how).  

Sorry for the tardiness of my reply.

> 
> The "sense of the room" in the RADEXT WG meeting at IETF 66 was that:
> 
> * Exhaustion of the RADIUS standard attribute space is a problem that
> should be solved. 

I do not agree with this; as I've pointed out ad nauseam, this problem was already solved some years ago in Diameter.  The current problem is that some folks don't want to accept the solution (though, strangely enough, those same folks seem to be in a rush to turn RADIUS into Diameter (again)).

> * RADEXT WG is the place to solve the problem.

If the first statement garners consensus, I can't think of any other place to do it.

> * The attribute exhaustion problem should be the focus -- not adding
> other capabilities to RADIUS (such as support for the Diameter data
> types).  

I think that the attribute exhaustion problem should definitely be the focus of the solution for the attribute exhaustion problem ;-).  Seriously, I think that one you solve that problem, the solutions to a bunch of other problems will pretty much just fall out.

> 
> In reviewing the potential solutions to the problem, the people
> present at the meeting appeared to strongly favor a RADIUS extension
> approach such as that outlined by Lior & Li (RADIUS attribute
> extension), over the current proposals for adding Diameter AVP
> support to RADIUS (Wolff & Weber and Mitton proposals).  

Agree strongly.

> Some of the
> reasoning behind this was that adding support for Diameter AVP
> parsing and dictionary support would involve a substantial portion of
> the effort to develop a Diameter server, whereas simply adding
> support for an extended space vwould involve less effort, and would
> therefore be more likely to be deployed.         
> 
> This consensus, if it is confirmed on the mailing list, has
> implications for the Design Guidelines document.  If the RADIUS
> attribute space is extended without changing the RADIUS protocol in
> other ways, then Design Guidelines document needs only to focus on
> guidelines for the RADIUS protocol.  Thus, the Design Guidelines
> effort is considerably simplified.     

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 27 Jul 2006 17:00:44 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] Summary of Authorize Only issue
Date: Thu, 27 Jul 2006 13:00:04 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

David Harrington writes...

> We separated the security and transport mappings from the message
> format in the RFC3411 architecture; SNMPv3 refers to a message format.

It also implies the only version with any real security.

> Please do not bind these concepts unnecessarily in your RADIUS
> proposal.

I think we can simplify the naming, as Dan suggests, and refer to SNMP
over SSH.  We can add a statement in the security considerations section
that strongly recommends use only with SNMP versions that have real
security, i.e. v3 (and higher).

> I can envision an SNMPv4 message processing model that uses an XML
> message encoding to improve compatibility with netconf and with data
> models from other SDOs.

Good luck with that!  :-)  

> I do not see a technical engineering reason to limit the RADIUS
> authorization to SNMPv3 over SSH, as compared to SNMP over SSH.

Right, but I think it might be fodder for 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: Thu, 27 Jul 2006 16:08:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
Date: Thu, 27 Jul 2006 12:08:16 -0400
From: "Avi Lior" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Cc: "Glen Zorn \(gwz\)" <[email-masked]>, "David Harrington" <[email-masked]>, "Eliot Lear" <[email-masked]>, <[email-masked]>, <[email-masked]>

I know, but AAA and Liberty Alliance perform different functions and
probably have different performance requirements.

But you are probably right.  My developers will have to cave one day.

The question is, will they kill me first or will I manage to survive. 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Thursday, July 27, 2006 4:08 AM
> To: Avi Lior
> Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; 
> [email-masked]; [email-masked]
> Subject: Re: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Hi Avi,
> 
> your developers might need to get used to XML sooner or later 
> anyway based on the excitement for Liberty Alliance nowadays. 
> The functionality of the asserting party in SAML is very 
> close to what a AA(A) does today.
> 
> Ciao
> Hannes
> 
> Avi Lior wrote:
> > Hi Hannes,
> > 
> > When I wrote the word "assertion"  I was thinking a SAML assertion.
> > 
> > A word of caution though, everytime I mention XML to my AAA 
> developers 
> > they conspire to kill me.
> > 
> > XML, parsing strings etc are performance killers for a AAA server.
> > 
> >   
> > 
> > 
> >>-----Original Message-----
> >>From: Hannes Tschofenig [mailto:[email-masked]]
> >>Sent: Wednesday, July 26, 2006 4:55 AM
> >>To: Avi Lior
> >>Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; [email-masked]; 
> >>[email-masked]
> >>Subject: Re: Follow up on Authorize Only issue (was RE: 
> >>[Isms] ISMS session
> >>
> >>Hi Avi,
> >>
> >>I like the idea of using some information to tie the authentication 
> >>and the authorization process/exchange together. In fact we 
> discussed 
> >>this at the last IETF meeting when David gave his presentation.
> >>
> >>I suggested to use an existing mechanism to accomplish this 
> binding, 
> >>namely SAML. I can elaborate a bit more about the details 
> if someone 
> >>case about it.
> >>
> >>Ciao
> >>Hannes
> >>
> >>Avi Lior wrote:
> >>
> >>>I proably did not make myself clear....or maybe I did and I
> >>
> >>am missing
> >>
> >>>something.
> >>>
> >>>When the NAS sends the Access-Request Auth-Only message I
> >>
> >>agree that
> >>
> >>>it MUST contain Message-Authenticator(80) etc...
> >>>
> >>>What I meant is that it would be nice if there was a token or an 
> >>>assertion that came from the place that did authenticate
> >>
> >>the user  to
> >>
> >>>indicate in a cryptographic way that this user was authenticated.
> >>>
> >>>The AAA server can use that token to verify that the user was 
> >>>authenticated by an entity that it trusts.  Like a 
> kerberose ticket.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Glen Zorn (gwz) [mailto:[email-masked]]
> >>>>Sent: Tuesday, July 25, 2006 3:47 PM
> >>>>To: Avi Lior; David Harrington; Eliot Lear
> >>>>Cc: [email-masked]; [email-masked]
> >>>>Subject: RE: Follow up on Authorize Only issue (was RE: 
> >>>>[Isms] ISMS session
> >>>>
> >>>>Avi Lior <mailto:[email-masked]> supposedly scribbled:
> >>>>
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>If I was specifying how this is done:
> >>>>>
> >>>>>It would be nice if the AAA client could return some sort
> >>>>
> >>>>of token to
> >>>>
> >>>>
> >>>>>the AAA server to assert that the user has been
> >>
> >>authenticated by an
> >>
> >>>>>entity that it trusts. The token can be generated by the
> >>>>>Authentication Server.   
> >>>>>
> >>>>>We need this assertion to make sure we deliver the 
> correct profile.
> >>>>
> >>>>I disagree: the fact that the message is being sent by an 
> >>>>authenticated client at all says that the user has been
> >>
> >>authenticated
> >>
> >>>>elsewhere.  Note that safety requires the inclusion of a
> >>
> >>MAC (either
> >>
> >>>>the Message-Authenticator or preferably the 
> >>>>Message-Authentication-Code Attribute) in the Access-Request.
> >>>>
> >>>>Hope this helps,
> >>>>
> >>>>~gwz
> >>>>
> >>>>Why is it that most of the world's problems can't be solved
> >>
> >>by simply
> >>
> >>>> listening to John Coltrane? -- Henry Gabriel
> >>>>
> >>>
> >>>
> >>>--
> >>>to unsubscribe send a message to
> >>
> >>[email-masked] with
> >>
> >>>the word 'unsubscribe' in a single line as the message text body.
> >>>archive: <http://psg.com/lists/radiusext/>
> >>>
> >>>
> >>
> > 
> > --
> > to unsubscribe send a message to 
> [email-masked] with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> > 
> 
> 

--
to unsubscribe send a message 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, 27 Jul 2006 15:29:54 +0000
content-class: urn:content-classes:message
Subject: RE: [Isms] Summary of Authorize Only issue
Date: Thu, 27 Jul 2006 18:29:42 +0300
To: "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

 

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, July 27, 2006 6:15 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Isms] Summary of Authorize Only issue
> 
> Dave Harrington writes...
> 
> > I think "SNMP over SSH" would be appropriate. I do not see 
> a reason to 
> > limit it to SNMPv3.
> 
> That's fine by me, if that's the consensus.  In the past, 
> I've been encouraged to omit support for v1 and v2c in I-Ds, 
> as those versions have been deprecated.  The comment was from 
> Bert Wijnen, in relation to protocol selection attributes I'd 
> included for v1 and v2c in the NAS-Management draft.
> 

I believe that that recommendation was correct and continues to stand.
The name does not bother me too much, as SNMPv3 is the only standard
version of SNMP but defining special attributes or features for v1 and
v2c should need some strong argumentation. 

Dan

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

Delivery-date: Thu, 27 Jul 2006 15:15:28 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] Summary of Authorize Only issue
Date: Thu, 27 Jul 2006 11:14:53 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Dave Harrington writes...

> I think "SNMP over SSH" would be appropriate. I do not see a reason to
> limit it to SNMPv3.

That's fine by me, if that's the consensus.  In the past, I've been
encouraged to omit support for v1 and v2c in I-Ds, as those versions
have been deprecated.  The comment was from Bert Wijnen, in relation to
protocol selection attributes I'd included for v1 and v2c in the
NAS-Management draft.

> >
> >       (b) Some other authentication mechanism/service
> >           provides initial authentication (and no
> >           authorization) of SNMPv3 over SSH.
> 
> Whether the other services provides authorization or not is
> immaterial.

Perhaps immaterial to RADIUS requirements, per se, but certainly not
immaterial to the security considerations for SNMP over SSH as a whole.

> >       (c) Some other authentication mechanism/service
> >           provides initial authentication (and no
> >           authorization) of SNMPv3 over SSH.  RADIUS
> >           provides base-service authorization of
> >           SNMPv3 over SSH (but no authentication).
> 
> I'm not sure anybody has asked for this combination, but I suppose we
> don't need to rule it out.

Included for completeness.  Wes H. has indicated, in a separate post,
that this might be useful.

> I would like to make sure everybody understands that the NAS is the
> managed device, not only edge devices providing network access
> services; Every SNMP-manageable device in the network might be
> considered a NAS in this scenario.

Yes.  In "RADIUS-speak", the terms "NAS" and "RADIUS Client" are often
used interchangeably.  In this use case, it would probably be desirable
to favor the term "RADIUS Client", for added clarity.

> Educate me. Why primarily the password authentication?

Because this is the RADIUS authentication method most commonly used for
SSH deployments today, I believe.

> Does this imply a (plaintext) password?

Yes, although RADIUS encrypts that password on the wire, on a hop-by-hop
basis, using the shared secret.

> Other authentication mechanisms might be preferable to passwords;
> I assume RADIUS supports a wide range of authentication mechanisms.

No, it does not.  The existing RADIUS authentication methods are:

-- password
-- textual challenge / response
-- CHAP (MD5 Digest)
-- EAP (basically any EAP method)
-- HTTP Digest (newly added)

We already know that EAP is not permissible for use with network
management authentication, because of its narrow applicability
statement.

Practically speaking, that leaves us with password and CHAP.  I believe
most of the current SSH usage of RADIUS for network management uses
password.

> I think there are three extended SNMP use cases that involve RADIUS
 
> 	  (c) RADIUS does not perform authentication or
>             base-service authorization.
>             Some other authentication mechanism/service
>             provides initial authentication and presumably
>             base service authorization for SNMP over whatever
>             secure transport, such as SNMP using USM over UDP,
>             or SNMP using USM and TCP/IPv6, or SNMP using Kerberos
>             and SCTP, or SNMP using 802.1AE and Ethernet.
>             The access control subsystem requests from RADIUS
>             ONLY the granular access control authorization
>             associated with the otherwise-authenticated user.
> 		(e.g., hey RADIUS, which group is this guy in?)

Juergen S., in a separate post, suggests that the two be collapsed into
one.  I'll ponder this a bit and propose something that attempts to
address both suggestions.
 
> Who sets the policy the RADIUS server will enforce?

The system administrator.

> i.e., how does the RADIUS server know which attributes contain
> security-sensitive information related to a user?

That is an implementation detail of the RADIUS Server, and not an
on-the-wire protocol issue.  I suggest that the document include
implementation guidance on this issue, perhaps in the security
considerations section, and that the protocol be designed so as to
provide sufficient information for an implementation to be capable of
accomplishing this goal.

It would certainly be possible to make a (non-exhaustive) list of
sensitive attributes, much as we make a list of sensitive objects in the
security considerations section of MIBs.

--
to unsubscribe send a message 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, 27 Jul 2006 10:54:59 +0000
Date: Thu, 27 Jul 2006 10:07:48 +0200
From: Hannes Tschofenig <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Glen Zorn (gwz)" <[email-masked]>,  David Harrington <[email-masked]>, Eliot Lear <[email-masked]>,  [email-masked],  [email-masked]
Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session

Hi Avi,

your developers might need to get used to XML sooner or later anyway 
based on the excitement for Liberty Alliance nowadays. The functionality 
of the asserting party in SAML is very close to what a AA(A) does today.

Ciao
Hannes

Avi Lior wrote:
> Hi Hannes,
> 
> When I wrote the word "assertion"  I was thinking a SAML assertion.
> 
> A word of caution though, everytime I mention XML to my AAA developers
> they conspire to kill me.
> 
> XML, parsing strings etc are performance killers for a AAA server.
> 
>   
> 
> 
>>-----Original Message-----
>>From: Hannes Tschofenig [mailto:[email-masked]] 
>>Sent: Wednesday, July 26, 2006 4:55 AM
>>To: Avi Lior
>>Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; 
>>[email-masked]; [email-masked]
>>Subject: Re: Follow up on Authorize Only issue (was RE: 
>>[Isms] ISMS session
>>
>>Hi Avi,
>>
>>I like the idea of using some information to tie the 
>>authentication and the authorization process/exchange 
>>together. In fact we discussed this at the last IETF meeting 
>>when David gave his presentation.
>>
>>I suggested to use an existing mechanism to accomplish this 
>>binding, namely SAML. I can elaborate a bit more about the 
>>details if someone case about it.
>>
>>Ciao
>>Hannes
>>
>>Avi Lior wrote:
>>
>>>I proably did not make myself clear....or maybe I did and I 
>>
>>am missing 
>>
>>>something.
>>>
>>>When the NAS sends the Access-Request Auth-Only message I 
>>
>>agree that 
>>
>>>it MUST contain Message-Authenticator(80) etc...
>>>
>>>What I meant is that it would be nice if there was a token or an 
>>>assertion that came from the place that did authenticate 
>>
>>the user  to 
>>
>>>indicate in a cryptographic way that this user was authenticated.
>>>
>>>The AAA server can use that token to verify that the user was 
>>>authenticated by an entity that it trusts.  Like a kerberose ticket.
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Glen Zorn (gwz) [mailto:[email-masked]]
>>>>Sent: Tuesday, July 25, 2006 3:47 PM
>>>>To: Avi Lior; David Harrington; Eliot Lear
>>>>Cc: [email-masked]; [email-masked]
>>>>Subject: RE: Follow up on Authorize Only issue (was RE: 
>>>>[Isms] ISMS session
>>>>
>>>>Avi Lior <mailto:[email-masked]> supposedly scribbled:
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>If I was specifying how this is done:
>>>>>
>>>>>It would be nice if the AAA client could return some sort
>>>>
>>>>of token to
>>>>
>>>>
>>>>>the AAA server to assert that the user has been 
>>
>>authenticated by an 
>>
>>>>>entity that it trusts. The token can be generated by the
>>>>>Authentication Server.   
>>>>>
>>>>>We need this assertion to make sure we deliver the correct profile.
>>>>
>>>>I disagree: the fact that the message is being sent by an 
>>>>authenticated client at all says that the user has been 
>>
>>authenticated 
>>
>>>>elsewhere.  Note that safety requires the inclusion of a 
>>
>>MAC (either 
>>
>>>>the Message-Authenticator or preferably the 
>>>>Message-Authentication-Code Attribute) in the Access-Request.
>>>>
>>>>Hope this helps,
>>>>
>>>>~gwz
>>>>
>>>>Why is it that most of the world's problems can't be solved 
>>
>>by simply
>>
>>>> listening to John Coltrane? -- Henry Gabriel
>>>>
>>>
>>>
>>>--
>>>to unsubscribe send a message to 
>>
>>[email-masked] with 
>>
>>>the word 'unsubscribe' in a single line as the message text body.
>>>archive: <http://psg.com/lists/radiusext/>
>>>
>>>
>>
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 
> 

--
to unsubscribe send a message 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, 27 Jul 2006 08:04:35 +0000
Date: Thu, 27 Jul 2006 10:03:47 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Isms] Summary of Authorize Only issue
Reply-To: [email-masked]
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

On Wed, Jul 26, 2006 at 03:56:04PM -0400, Nelson, David wrote:
> (2) There are two extended SNMP over SSH use cases:
> 
>       (a) RADIUS provides initial authentication and 
>           authorization of SNMPv3 over SSH, base-service
>           authorization, and (optionally) granular access
>           control authorization.
> 
>       (b) Some other authentication mechanism/service 
>           provides initial authentication (and no
>           authorization) of SNMPv3 over SSH.  RADIUS
>           provides base-service authorization and 
>           (optionally) granular access control
>           authorization.
> 
> Note that "granular access control" means a mapping to the VACM or some
> other Access Control Subsystem.
> 
> These use cases are currently out of scope for the ISMS WG charter, but
> might be added at a later date.

Note that the reference "these use cases" is somewhat ambiguous. I
assume you refer to (2a) and (2b). But even with this interpretation,
it is only the optional part which is out of scope for the ISMS WG.

Personally, I consider provisioning of SNMP access control mappings
via RADIUS authorization a functionality which is totally independent
of authentication and base-service authorization. So perhaps (2a) and
(2b) should be combined into an SNMP access control provisioning use
case:

(2) There is an SNMP access control provisioning use case:

    RADIUS provides authorization information to be used by SNMP
    access control models, for example by providing a mapping of
    securityName to securityGroup, for use with the VACM. An example
    of such an attribute is Management-Policy-ID, conceptually similar
    to Filter-ID. Due to the strict separation of access control from
    authentication in the SNMP architecture, this requires that RADIUS
    provides an Authorize Only service for SNMP usage.

/js

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

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

Delivery-date: Wed, 26 Jul 2006 20:19:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Summary of Authorize Only issue
Date: Wed, 26 Jul 2006 16:19:32 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard Aboba writes...

> For this to be successful, the RADIUS server needs to know what 
> service is being requested by the NAS, so that it can limit the 
> attributes to those relevant to that service (or refuse to 
> authorize the service).  The service cannot be characterized by
> saying it is "authorize-only" -- that is merely a particular 
> (authorize-only) mode of a particular service which needs to
> be specified by the NAS.

I agree (100%).
 
> >In any of the use cases, it is important that the NAS, i.e.
> >the RADIUS Client, be able to communicate the kind of service
> >being sought via hint attributes to the RADIUS Server, in the
> >Access-Request message.
> 
> Service-Type is not a "hint". 

It is when it appears in an Access-Request message.  This is the context
of the foregoing paragraph.

> A RADIUS client that receives 
> an Access-Accept with an unknown Service-Type does not treat 
> the attribute as a "hint" -- it treats it as an Access-Reject. 
> This is mandatory behavior in RFC 2865.

I agree, when it appears in an Access-Accept message.

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

Delivery-date: Wed, 26 Jul 2006 20:12:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Summary of Authorize Only issue
Date: Wed, 26 Jul 2006 13:12:46 -0700

>(4) RADIUS Servers SHOULD exercise appropriate policy enforcement in
>terms of providing any NAS with attributes that might disclose security
>sensitive information related to a user, e.g. keys, unless that user has
>been successfully authenticated to the RADIUS Server via the NAS in
>question.  This affects RADIUS Server behavior during any Authorize Only
>service provisioning.

For this to be successful, the RADIUS server needs to know what service is 
being requested by the NAS, so that it can limit the attributes to those 
relevant to that service (or refuse to authorize the service).  The service 
cannot be characterized by saying it is "authorize-only" --  that is merely 
a particular (authorize-only) mode of a particular service which needs to be 
specified by the NAS.

>In any of the use cases, it is important that the NAS, i.e. the RADIUS
>Client, be able to communicate the kind of service being sought via hint
>attributes to the RADIUS Server, in the Access-Request message.

Service-Type is not a "hint".  A RADIUS client that receives an 
Access-Accept with an unknown Service-Type does not treat the attribute as a 
"hint" -- it treats it as an Access-Reject.  This is mandatory behavior in 
RFC 2865.

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

Delivery-date: Wed, 26 Jul 2006 20:03:40 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Wed, 26 Jul 2006 16:03:22 -0400
To: <[email-masked]>, <[email-masked]>

Avi Lior writes...

> But 3576 and WG decided not to go there.

Unless I'm mistaken, RFC 3576 was not the work product of any WG.  It
occurred after the RADIUS WG closed, and prior to the RADEXT WG opening.

> In hindsight, Authorize/Authetnication/Callcheck/etc should have used
an
> attribute specifically for that purpose.

Perhaps.

> The lesson is that we should be learning is not to overload
attributes.

I agree.
 
> I think introducing another Authorize-Only semantic is bad as well. I
> think that saying that Authorize-Only is only a 3576 think flies in
the
> nature of all RADIUS RFCs.

There are potential disadvantages, primarily in terms of how existing
RADIUS servers are implemented, but I don't see this as quite so much of
a problem.

> Finally, in view of the overloading of Service-Type, the use of
> NAS-Port-Type to provide a context for the type of service being
> requested is not ideal but it does work.

IMHO, overloading NAS-Port-Type is as bad as, if not worse than,
overloading Service-Type.  Overloading is overloading.  Overloading is
bad.  ;-)

--
to unsubscribe send a message 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, 26 Jul 2006 19:56:18 +0000
Content-class: urn:content-classes:message
Subject: Summary of Authorize Only issue
Date: Wed, 26 Jul 2006 15:56:04 -0400
To: <[email-masked]>, <[email-masked]>

Let me see if I can summarize the discussion so far, and if folks agree
that I've summarized accurately.

(1) There are three basic SNMP over SSH use cases:

      (a) RADIUS provides initial authentication and 
          base-service authorization of SNMPv3 over
          SSH.

      (b) Some other authentication mechanism/service 
          provides initial authentication (and no
          authorization) of SNMPv3 over SSH.

      (c) Some other authentication mechanism/service 
          provides initial authentication (and no
          authorization) of SNMPv3 over SSH.  RADIUS
          provides base-service authorization of
          SNMPv3 over SSH (but no authentication).

Note that "base-service" authorization means that the SSH server in the
NAS is allowed to provide connectivity via SSH to the SNMPv3 engine of
the NAS.

In case (1a) we require the existing RADIUS authentication methods,
primarily the password authentication, plus some attributes to authorize
the service, such as Service-Type = Framed-Management, and
Framed-Management-Protocol = SNMPv3-over-SSH.

In case (1b) there are no requirements for RADIUS.

In case (1c) we require the ability for RADIUS to provide an Authorize
Only service for SNMP usage.  The provisioning attributes are the same
as for case (1a).

We have seen a considerable amount of discussion on the mailing list of
the issues and properties of an Authorize Only service in RADIUS.  Many
of those discussions focus on potential solutions, but I've restricted
this posting to requirements. 

(2) There are two extended SNMP over SSH use cases:

      (a) RADIUS provides initial authentication and 
          authorization of SNMPv3 over SSH, base-service
          authorization, and (optionally) granular access
          control authorization.

      (b) Some other authentication mechanism/service 
          provides initial authentication (and no
          authorization) of SNMPv3 over SSH.  RADIUS
          provides base-service authorization and 
          (optionally) granular access control
          authorization.

Note that "granular access control" means a mapping to the VACM or some
other Access Control Subsystem.

These use cases are currently out of scope for the ISMS WG charter, but
might be added at a later date.

In case (2a) the additional RADIUS requirement is for an attribute to
authorize granular access control, for example by providing a mapping of
securityName to securityGroup, for use with the VACM.  An example of
such an attribute is Management-Policy-ID, conceptually similar to
Filter-ID.

In case (2b) the additional requirements for RADIUS include those of
case (2a) plus the ability for RADIUS to provide an Authorize Only
service for SNMP usage.

(3) The basic RADIUS trust model dictates that if a NAS, that possess a
valid shared secret with a RADIUS Server, is compromised, nothing in the
RADIUS protocol can mitigate that breach, at least in terms of the
services to which the NAS mediates access.

(4) RADIUS Servers SHOULD exercise appropriate policy enforcement in
terms of providing any NAS with attributes that might disclose security
sensitive information related to a user, e.g. keys, unless that user has
been successfully authenticated to the RADIUS Server via the NAS in
question.  This affects RADIUS Server behavior during any Authorize Only
service provisioning.

In any of the use cases, it is important that the NAS, i.e. the RADIUS
Client, be able to communicate the kind of service being sought via hint
attributes to the RADIUS Server, in the Access-Request message.  This
has implications on the use of the Service-Type in Authorize Only
operations, in which it would otherwise be used as a hint of the
requested service, and not the request authentication method.

It is also important that the RADIUS Server be able to specify the
provisioning of SNMPv3 over SSH service to the NAS in the Access-Accept
message.

Does this accurately summarize the consensus on this issue?  Especially
in terms of requirements that ISMS has of RADEXT?  Please advise, with
suggestions for improvement.

--
to unsubscribe send a message 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, 26 Jul 2006 19:55:36 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Wed, 26 Jul 2006 15:55:43 -0400
From: "Avi Lior" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

I agree with Glen....

If the using Service-Type to convey Authorize-Only was a mistake that
mistake was made a long time before 3576.

During 3576 I did bring up the issue of putting Authorize-Only in
service type.  My concern then was exaclty what we are facing today.  It
becomes hard for us to express both that we want to Authenticate or
Authorize or  and what service this applies to.

But 3576 and WG decided not to go there.

In hindsight, Authorize/Authetnication/Callcheck/etc should have used an
attribute specifically for that purpose.

The lesson is that we should be learning is not to overload attributes.

I think introducing another Authorize-Only semantic is bad as well. I
think that saying that Authorize-Only is only a 3576 think flies in the
nature of all RADIUS RFCs.

Finally, in view of the overloading of Service-Type, the use of
NAS-Port-Type to provide a context for the type of service being
requested is not ideal but it does work. 

Avi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Glen Zorn (gwz)
> Sent: Wednesday, July 26, 2006 11:27 AM
> To: Nelson, David
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Isms] RE: Follow up on Authorize Only issue
> 
> Nelson, David <mailto:[email-masked]> supposedly scribbled:
> 
> > Glen Zorn writes...
> > 
> >>> If this attribute is used for its intended purpose, to allow the 
> >>> RADIUS server to know what service to provision, then it 
> cannot also 
> >>> be used to indicate authorize-only mode.
> > 
> >> Too late, it already is.
> > 
> > Yes, for the Dynamic RADIUS Change of Authorization use case, as 
> > specified in RFC 3576.  It has no formally specified usage outside 
> > 3576, that I recall.  We need not use that method for the "general"
> > authorization only case.  We could devise a new method, such as the 
> > Asserted-Identity attribute, and relegate the Service-Type = 
> > "Authorize Only" usage to CoA only.
> 
> We could, but it seems like a waste of attribute space since 
> the value if any would of necessity be identical to that 
> carried by the User-Name Attribute.
>    
> > 
> > I tend to agree with Jeff that this portion if RFC 3576 was 
> probably a 
> > "mistake".
> 
> Perhaps, but if so, it lines up very well with the original 
> definition of the Service-Type Attribute.  In fact, I can't 
> find any trace of the architectural purity imputed to the 
> Attribute by Jeff: only some of the values of Service-Type 
> are related to service as he has defined it.  Although I 
> wasn't involved (except as a critic ;-) with the development 
> of RFC 3576 either, it would make perfect sense to me to add 
> a value of "Authorize Only" to an Attribute that already had 
> values of "Authenticate Only" & "Call Check" defined, the 
> latter being purely authorizational in character.
> 
> > I can say that as I had nothing to do with that document.  
> Whether it 
> > was or wasn't, we are not obligated to carry
> > that particular usage into other areas of application for RADIUS.   
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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/>
> 

--
to unsubscribe send a message 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, 26 Jul 2006 18:21:12 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Wed, 26 Jul 2006 14:20:54 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Juergen Schoenwaelder writes...
 
> Given our current charter, I like to see the RADIUS document we are
> chartered to produce focus on the RADIUS SSH user authentication and
> RADIUS authorization of the SSH SNMP subsystem.

We'll omit any discussion of "fine grained" access control, i.e.
anything other than whether the SSH server should offer to make a
connection to the SNMP engine, in the -01 version.

> Note that this does of course not impact the RADEXT document which
> may define all attributes needed to address all the RADIUS related 
> ISMS requirements.

OK, thanks.

> I actually like to encourage people to write a document which 
> explains how VACM can utilize RADIUS to provision the security 
> name to group name mapping and to post such a document as an 
> individual draft.

I also think that would be useful, and predict that folks are likely to
implement such a scheme, whether ISMS takes it up or not.

--
to unsubscribe send a message 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, 26 Jul 2006 18:18:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
Date: Wed, 26 Jul 2006 11:18:21 -0700
To: "Avi Lior" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>
Cc: "David Harrington" <[email-masked]>, "Eliot Lear" <[email-masked]>, <[email-masked]>, <[email-masked]>

Avi Lior <mailto:[email-masked]> supposedly scribbled:

> Hi Hannes,
> 
> When I wrote the word "assertion"  I was thinking a SAML assertion.

In order for this to have any meaning at all, the source of this assertion would need to be  trusted by both the RADIUS client and server.  This seems to imply a bunch of new keys, at a minimum, unless you don't care to authenticate the token/assertion/whatever (in which case why bother?).  In addition, the token/assertion/whatever would need to be somehow delivered from something, somewhere in a secure fashion to the RADIUS client for forwarding to the RADIUS server.  Aside from those minor nits (modifying both the RADIUS entities to receive, transmit & understand the token/assertion/whatever & more than likely the SSH/Kerberos/whatever entities to actually generate & deliver the token/assertion/whatever), I think this is a great idea.

> 
> A word of caution though, everytime I mention XML to my AAA
> developers they conspire to kill me. 

Good people & wise!

> 
> XML, parsing strings etc are performance killers for a AAA server.
> 
> 
> 
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email-masked]]
>> Sent: Wednesday, July 26, 2006 4:55 AM
>> To: Avi Lior
>> Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; [email-masked];
>> [email-masked] Subject: Re: Follow up on Authorize Only
>> issue (was RE: [Isms] ISMS session 
>> 
>> Hi Avi,
>> 
>> I like the idea of using some information to tie the authentication
>> and the authorization process/exchange together. In fact we discussed
>> this at the last IETF meeting when David gave his presentation.
>> 
>> I suggested to use an existing mechanism to accomplish this binding,
>> namely SAML. I can elaborate a bit more about the details if someone
>> case about it. 
>> 
>> Ciao
>> Hannes
>> 
>> Avi Lior wrote:
>>> I proably did not make myself clear....or maybe I did and I am
>>> missing something. 
>>> 
>>> When the NAS sends the Access-Request Auth-Only message I agree that
>>> it MUST contain Message-Authenticator(80) etc...
>>> 
>>> What I meant is that it would be nice if there was a token or an
>>> assertion that came from the place that did authenticate the user 
>>> to indicate in a cryptographic way that this user was authenticated.
>>> 
>>> The AAA server can use that token to verify that the user was
>>> authenticated by an entity that it trusts.  Like a kerberose ticket.
>>> 
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Glen Zorn (gwz) [mailto:[email-masked]]
>>>> Sent: Tuesday, July 25, 2006 3:47 PM
>>>> To: Avi Lior; David Harrington; Eliot Lear
>>>> Cc: [email-masked]; [email-masked]
>>>> Subject: RE: Follow up on Authorize Only issue (was RE: [Isms]
>>>> ISMS session 
>>>> 
>>>> Avi Lior <mailto:[email-masked]> supposedly scribbled:
>>>> 
>>>> 
>>>>> Hi,
>>>>> 
>>>>> If I was specifying how this is done:
>>>>> 
>>>>> It would be nice if the AAA client could return some sort
>>>> 
>>>> of token to
>>>> 
>>>>> the AAA server to assert that the user has been authenticated by
>>>>> an entity that it trusts. The token can be generated by the
>>>>> Authentication Server. 
>>>>> 
>>>>> We need this assertion to make sure we deliver the correct
>>>>> profile. 
>>>> 
>>>> I disagree: the fact that the message is being sent by an
>>>> authenticated client at all says that the user has been
>>>> authenticated elsewhere.  Note that safety requires the inclusion
>>>> of a MAC (either the Message-Authenticator or preferably the
>>>> Message-Authentication-Code Attribute) in the Access-Request.
>>>> 
>>>> 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/>

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, 26 Jul 2006 18:09:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
Date: Wed, 26 Jul 2006 14:09:37 -0400
From: "Avi Lior" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>, "David Harrington" <[email-masked]>, "Eliot Lear" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Jeffrey.

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 6:43 PM
> To: Avi Lior; Glen Zorn (gwz); David Harrington; Eliot Lear
> Cc: [email-masked]; [email-masked]; Jeffrey Hutzelman
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> 
> 
> On Tuesday, July 25, 2006 05:40:00 PM -0400 Avi Lior 
> <[email-masked]> wrote:
> 
> > I proably did not make myself clear....or maybe I did and I 
> am missing 
> > something.
> >
> > When the NAS sends the Access-Request Auth-Only message I 
> agree that 
> > it MUST contain Message-Authenticator(80) etc...
> >
> > What I meant is that it would be nice if there was a token or an 
> > assertion that came from the place that did authenticate 
> the user  to 
> > indicate in a cryptographic way that this user was authenticated.
> >
> > The AAA server can use that token to verify that the user was 
> > authenticated by an entity that it trusts.  Like a kerberose ticket.
> 
> First, the user was authenticated by the NAS.  That is all 
> the RADIUS server needs to know.  The RADIUS server provides 
> service to the NAS, not the user, and the NAS has asked for 
> information about what the user is allowed to do.  Either the 
> RADIUS server is willing to give that information to the NAS 
> or it is not, but it is the NAS that is making the request, 
> not the user.

I don't have a problem with that.  But it would be better if the NAS can
prove to the AAA server that the user was authenticated.  Normally it is
the AAA that authenticates the user and provides authorization
attributes.

> 
> RADIUS servers provide authentication as a _service_ to the 
> NAS, not as a means of determining whether the NAS is 
> legitimate or should be given information.  A NAS that is not 
> interested in that service should not be required to use it 
> in order to make use of the other services that the RADIUS 
> server can provide, such as provisioning and accounting.  
> Once again, the RADIUS server's relationship is with the NAS, 
> not the user.

Not true.  Normally the RADIUS server (in particular the home RADIUS
server) owns the user. Therefore it has a trust relationship with the
user.  The mechanism for that trust relationship is a credential
(password or shared key) known only to those two parties.

The RADIUS server trusts the NAS directly or via a trust chain.  The
trust mechanism is a shared secret or in the case of a trust chain, a
set of trust secrets.

> 
> Secondly, as I already said, the sort of token you describe 
> simply does not exist for most authentication mechanisms.  A 
> Kerberos ticket is not cryptographic proof that a user has 
> authenticated.  It is an encrypted message from the Kerberos 
> server to a particular service, and is useless to anyone 
> else.  And, it's not a message saying "this user authenticated". 
> It's a message telling the service the keys it needs to know 
> in order to conduct an exchange with a user and determine 
> whether that user is real.

Well if that token did exist then it will be useful to use it. 

I stand corrected on Kerberose.

However, there are tokens that are used for single-sign-on that do prove
the authenticity of the token holder.  Why can't something like that be
used?  

> 
> Thirdly, as I've also said before, this is a serious 
> abstraction violation. 
> Even if every service had such a magic cookie, what you're 
> suggesting would require defining what it is, for RADIUS, for 
> every authentication mechanism that might be used by a NAS 
> using authorize-only.  What magic token are you going to use 
> for TLS?  What about USM?  GSS-spkm?  SSH public key? 
> one-time passwords?  SSH host-based public key?  NTLM?  
> IPsec?  How about the Frobozz protocol I referred to in an 
> earlier message?  You don't even know how that works, so 
> you'd basically guarantee that when I get a NAS that supports 
> the Frobozz protocol, I can't use it until I define an 
> extension to the RADIUS protocol and upgrade my server.

Perhaps I missled you and I am sorry. So let me clarify...

First and foremost I am in favour of supporting the scheme that a NAS
ought to be able to peform an Authorize-Only to a AAA sever regardless
if that AAA server has authenticated the user or not.  There are a huge
security issues but so be it.  Those security issue can be managed in
many ways.

The scheme is useful!!!

The second part of my email was about one method of managing that
security.  Again, I would not want to mandate that method and mandate
that that would be the only way to design such a system.

In general my philosophy is that the IETF should build tools.  Some of
these tools can be dangerous if not used properly.  The IETF should
provide its wisdom on how one may use these tools and identify the risks
as best it can.

> 
> -- Jeff
> 

--
to unsubscribe send a message 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, 26 Jul 2006 17:41:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
Date: Wed, 26 Jul 2006 13:41:49 -0400
From: "Avi Lior" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Cc: "Glen Zorn \(gwz\)" <[email-masked]>, "David Harrington" <[email-masked]>, "Eliot Lear" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Hannes,

When I wrote the word "assertion"  I was thinking a SAML assertion.

A word of caution though, everytime I mention XML to my AAA developers
they conspire to kill me.

XML, parsing strings etc are performance killers for a AAA server.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Wednesday, July 26, 2006 4:55 AM
> To: Avi Lior
> Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; 
> [email-masked]; [email-masked]
> Subject: Re: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Hi Avi,
> 
> I like the idea of using some information to tie the 
> authentication and the authorization process/exchange 
> together. In fact we discussed this at the last IETF meeting 
> when David gave his presentation.
> 
> I suggested to use an existing mechanism to accomplish this 
> binding, namely SAML. I can elaborate a bit more about the 
> details if someone case about it.
> 
> Ciao
> Hannes
> 
> Avi Lior wrote:
> > I proably did not make myself clear....or maybe I did and I 
> am missing 
> > something.
> > 
> > When the NAS sends the Access-Request Auth-Only message I 
> agree that 
> > it MUST contain Message-Authenticator(80) etc...
> > 
> > What I meant is that it would be nice if there was a token or an 
> > assertion that came from the place that did authenticate 
> the user  to 
> > indicate in a cryptographic way that this user was authenticated.
> > 
> > The AAA server can use that token to verify that the user was 
> > authenticated by an entity that it trusts.  Like a kerberose ticket.
> > 
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Glen Zorn (gwz) [mailto:[email-masked]]
> >>Sent: Tuesday, July 25, 2006 3:47 PM
> >>To: Avi Lior; David Harrington; Eliot Lear
> >>Cc: [email-masked]; [email-masked]
> >>Subject: RE: Follow up on Authorize Only issue (was RE: 
> >>[Isms] ISMS session
> >>
> >>Avi Lior <mailto:[email-masked]> supposedly scribbled:
> >>
> >>
> >>>Hi,
> >>>
> >>>If I was specifying how this is done:
> >>>
> >>>It would be nice if the AAA client could return some sort
> >>
> >>of token to
> >>
> >>>the AAA server to assert that the user has been 
> authenticated by an 
> >>>entity that it trusts. The token can be generated by the
> >>>Authentication Server.   
> >>>
> >>>We need this assertion to make sure we deliver the correct profile.
> >>
> >>I disagree: the fact that the message is being sent by an 
> >>authenticated client at all says that the user has been 
> authenticated 
> >>elsewhere.  Note that safety requires the inclusion of a 
> MAC (either 
> >>the Message-Authenticator or preferably the 
> >>Message-Authentication-Code Attribute) in the Access-Request.
> >>
> >>Hope this helps,
> >>
> >>~gwz
> >>
> >>Why is it that most of the world's problems can't be solved 
> by simply
> >>  listening to John Coltrane? -- Henry Gabriel
> >>
> > 
> > 
> > --
> > to unsubscribe send a message to 
> [email-masked] with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> > 
> 
> 

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

Delivery-date: Wed, 26 Jul 2006 15:27:16 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Wed, 26 Jul 2006 08:26:38 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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

> Glen Zorn writes...
> 
>>> If this attribute is used for its intended purpose, to allow the
>>> RADIUS server to know what service to provision, then it cannot also
>>> be used to indicate authorize-only mode.
> 
>> Too late, it already is.
> 
> Yes, for the Dynamic RADIUS Change of Authorization use case, as
> specified in RFC 3576.  It has no formally specified usage outside
> 3576, that I recall.  We need not use that method for the "general"
> authorization only case.  We could devise a new method, such as the
> Asserted-Identity attribute, and relegate the Service-Type =
> "Authorize Only" usage to CoA only.  

We could, but it seems like a waste of attribute space since the value if any would of necessity be identical to that carried by the User-Name Attribute.
   
> 
> I tend to agree with Jeff that this portion if RFC 3576 was probably
> a "mistake".  

Perhaps, but if so, it lines up very well with the original definition of the Service-Type Attribute.  In fact, I can't find any trace of the architectural purity imputed to the Attribute by Jeff: only some of the values of Service-Type are related to service as he has defined it.  Although I wasn't involved (except as a critic ;-) with the development of RFC 3576 either, it would make perfect sense to me to add a value of "Authorize Only" to an Attribute that already had values of "Authenticate Only" & "Call Check" defined, the latter being purely authorizational in character.

> I can say that as I had nothing to do with that
> document.  Whether it was or wasn't, we are not obligated to carry
> that particular usage into other areas of application for RADIUS.   
> 
> 
> 
> 
> _______________________________________________
> 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: Wed, 26 Jul 2006 11:45:56 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Wed, 26 Jul 2006 07:45:29 -0400
To: <[email-masked]>, <[email-masked]>

Glen Zorn writes...
 
> > If this attribute is used for its intended purpose, to allow the
> > RADIUS server to know what service to provision, then it 
> > cannot also be used to indicate authorize-only mode.

> Too late, it already is.

Yes, for the Dynamic RADIUS Change of Authorization use case, as specified in RFC 3576.  It has no formally specified usage outside 3576, that I recall.  We need not use that method for the "general" authorization only case.  We could devise a new method, such as the Asserted-Identity attribute, and relegate the Service-Type = "Authorize Only" usage to CoA only.

I tend to agree with Jeff that this portion if RFC 3576 was probably a "mistake".  I can say that as I had nothing to do with that document.  Whether it was or wasn't, we are not obligated to carry that particular usage into other areas of application for RADIUS.

--
to unsubscribe send a message 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, 26 Jul 2006 09:22:20 +0000
Date: Wed, 26 Jul 2006 10:55:06 +0200
From: Hannes Tschofenig <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Glen Zorn (gwz)" <[email-masked]>,  David Harrington <[email-masked]>, Eliot Lear <[email-masked]>,  [email-masked],  [email-masked]
Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session

Hi Avi,

I like the idea of using some information to tie the authentication and 
the authorization process/exchange together. In fact we discussed this 
at the last IETF meeting when David gave his presentation.

I suggested to use an existing mechanism to accomplish this binding, 
namely SAML. I can elaborate a bit more about the details if someone 
case about it.

Ciao
Hannes

Avi Lior wrote:
> I proably did not make myself clear....or maybe I did and I am missing
> something.
> 
> When the NAS sends the Access-Request Auth-Only message I agree that it
> MUST contain Message-Authenticator(80) etc...
> 
> What I meant is that it would be nice if there was a token or an
> assertion that came from the place that did authenticate the user  to
> indicate in a cryptographic way that this user was authenticated.
> 
> The AAA server can use that token to verify that the user was
> authenticated by an entity that it trusts.  Like a kerberose ticket.
> 
> 
> 
> 
>>-----Original Message-----
>>From: Glen Zorn (gwz) [mailto:[email-masked]] 
>>Sent: Tuesday, July 25, 2006 3:47 PM
>>To: Avi Lior; David Harrington; Eliot Lear
>>Cc: [email-masked]; [email-masked]
>>Subject: RE: Follow up on Authorize Only issue (was RE: 
>>[Isms] ISMS session
>>
>>Avi Lior <mailto:[email-masked]> supposedly scribbled:
>>
>>
>>>Hi,
>>>
>>>If I was specifying how this is done:
>>>
>>>It would be nice if the AAA client could return some sort 
>>
>>of token to 
>>
>>>the AAA server to assert that the user has been authenticated by an 
>>>entity that it trusts. The token can be generated by the
>>>Authentication Server.   
>>>
>>>We need this assertion to make sure we deliver the correct profile.
>>
>>I disagree: the fact that the message is being sent by an 
>>authenticated client at all says that the user has been 
>>authenticated elsewhere.  Note that safety requires the 
>>inclusion of a MAC (either the Message-Authenticator or 
>>preferably the Message-Authentication-Code Attribute) in the 
>>Access-Request.  
>>
>>Hope this helps,
>>
>>~gwz
>>
>>Why is it that most of the world's problems can't be solved by simply
>>  listening to John Coltrane? -- Henry Gabriel
>>
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 
> 

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

Delivery-date: Wed, 26 Jul 2006 07:13:39 +0000
Date: Wed, 26 Jul 2006 09:13:17 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Isms] RE: Follow up on Authorize Only issue
Reply-To: [email-masked]
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

On Tue, Jul 25, 2006 at 05:12:10PM -0400, Nelson, David wrote:
 
> We've had this discussion many months ago.  My opinion hasn't changed.
> I think that providing a way for RADIUS to provision group membership
> information that can be used to map into any Access Control Subsystem
> ought to be part of the work.  Especially if it does not actually affect
> the architectural model, and is accomplished in an implementation
> dependent fashion.

My understanding is that the concept of a group name is specific to
VACM. The ASIs into the ACM subsystem do not carry such a thing as a
group name. As such, mappings of security names to group names is VACM
specific and clearly happens within VACM from an architectural point
of view.

While I do see interest in addressing this VACM security name to group
name mapping issue, I do indeed see this work item in conflict with
the current ISMS charter:

: Work on new access control models or centralized administration of
: View-based Access Control Model (VACM) rules and mappings is outside
: the scope of the working group.

Given our current charter, I like to see the RADIUS document we are
chartered to produce focus on the RADIUS SSH user authentication and
RADIUS authorization of the SSH SNMP subsystem.  Another document
detailing how RADIUS can be used by VACM to obtain security name to
group name mappings might be written and become a WG item in the
future once we have completed our current work items and we can
re-charter and take on new work.

Note that this does of course not impact the RADEXT document which may
define all attributes needed to address all the RADIUS related ISMS
requirements.

I actually like to encourage people to write a document which explains
how VACM can utilize RADIUS to provision the security name to group
name mapping and to post such a document as an individual draft. But
as explained above, this work can't become an official WG work item
under the current charter.

/js

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

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

Delivery-date: Wed, 26 Jul 2006 04:54:53 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 21:54:37 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

Jeffrey Hutzelman <mailto:[email-masked]> supposedly scribbled:

> On Tuesday, July 25, 2006 02:20:49 PM -0700 "Glen Zorn (gwz)"
> <[email-masked]> wrote:
> 
>> Actually, no, at least in current usage an authentication type
>> _always_ has an associated attribute, which can be seen as something
>> that the server doesn't understand.
> 
> Is there a requirement that a server reject a request which contains
> any attributes it doesn't understand? 
> 
> 
> 
>>> A RADIUS server which supports authorize-only will
>>> probably want to return success for the request using that feature,
>>> but still must return failure for requests using methods it doesn't
>>> understand.  To make the distinction, you need an affirmative
>>> indication from the client that it wants authorize-only;
>> 
>> Is that not provided by the Service-Type of Authorize-Only?
> 
> Not if you want to use Service-Type to actually indicate the service
> type, 
> instead of overloading it to mean something else.  As I understand
> it, this 
> attribute is _supposed_ to indicate the type of service the NAS is
> providing to the user, and overloading it to mean something else was a
> mistake.  If this attribute is used for its intended purpose, to
> allow the 
> RADIUS server to know what service to provision, then it cannot also
> be 
> used to indicate authorize-only mode.

Too late, it already is.

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, 26 Jul 2006 04:34:53 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 21:33:56 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Jeffrey Hutzelman <mailto:[email-masked]> supposedly scribbled:

> On Tuesday, July 25, 2006 02:16:41 PM -0700 "Glen Zorn (gwz)"
> <[email-masked]> wrote:
> 
>> Don't quite understand this either: if a server doesn't recognize the
>> postulated Asserted-Identity Attribute, it seems that as far as it is
>> concerned there will be no credential-bearing attribute in the
>> message. So just omitting any credential-bearing attribute (along
>> with the addition of the other stuff we've been talking about)
>> should get just the same response from a legacy server, right?
> 
>> From a _legacy_ server, yes.  The concern is about how this would
>> affect
> handling of some new authentication method invented in the future. 
> Suppose there is a new method that requires a "Frobozz" attribute,
> and we have a client that sends a request using that method.  A
> server which supports "Frobozz" will respond correctly, as will a
> server that does not support either "Frobozz" or authorize-only.    
> 
> 
> However, a server that supports authorize-only but does _not_ support
> "Frobozz" will believe the client intended authorize-only, and will
> return a successful response on that basis, without verifying the
> user's identity.   
> That's the situation which we need an "Asserted-Identity" attribute
> to avoid.  The _contents_ of such an attribute are irrelevant; the
> important thing is an affirmative indication that the client meant
> authorize-only and not some unknown "Frobozz".   

OK, one more time: that seems to be what a Service-Type of Authorize-Only would do....

> 
> -- Jeff

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, 25 Jul 2006 21:39:49 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
Date: Tue, 25 Jul 2006 17:40:00 -0400
From: "Avi Lior" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>, "David Harrington" <[email-masked]>, "Eliot Lear" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

I proably did not make myself clear....or maybe I did and I am missing
something.

When the NAS sends the Access-Request Auth-Only message I agree that it
MUST contain Message-Authenticator(80) etc...

What I meant is that it would be nice if there was a token or an
assertion that came from the place that did authenticate the user  to
indicate in a cryptographic way that this user was authenticated.

The AAA server can use that token to verify that the user was
authenticated by an entity that it trusts.  Like a kerberose ticket.

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 3:47 PM
> To: Avi Lior; David Harrington; Eliot Lear
> Cc: [email-masked]; [email-masked]
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Avi Lior <mailto:[email-masked]> supposedly scribbled:
> 
> > Hi,
> > 
> > If I was specifying how this is done:
> > 
> > It would be nice if the AAA client could return some sort 
> of token to 
> > the AAA server to assert that the user has been authenticated by an 
> > entity that it trusts. The token can be generated by the
> > Authentication Server.   
> > 
> > We need this assertion to make sure we deliver the correct profile.
> 
> I disagree: the fact that the message is being sent by an 
> authenticated client at all says that the user has been 
> authenticated elsewhere.  Note that safety requires the 
> inclusion of a MAC (either the Message-Authenticator or 
> preferably the Message-Authentication-Code Attribute) in the 
> Access-Request.  
> 
> 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, 25 Jul 2006 21:20:57 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 14:20:49 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

Jeffrey Hutzelman <mailto:[email-masked]> supposedly scribbled:

> On Tuesday, July 25, 2006 01:10:57 PM -0700 "Glen Zorn (gwz)"
> <[email-masked]> wrote:
> 
>> Aside from the fact that "Authorize Only" is hardly an authentication
>> method
> 
> It's not an authentication method, but it fills that role in the
> protocol. 
> Ordinarily, the RADIUS server must have some means of verifying the
> user's identity, because the NAS is counting on it to do that.  The
> authentication method is simply the answer to the question "what is
> that means?".  What we're doing is defining a new possible answer,
> which is "there is none; the NAS is not counting on you to verify the
> user's identity, so you don't have to do it".     
> 
> Now, you've suggested that the way to represent that answer is simply
> by not including the attributes required for some other method.  The
> problem with that is that such a request is indistinguishable to the
> RADIUS server from a request using an authentication method it does
> not understand.  

Actually, no, at least in current usage an authentication type _always_ has an associated attribute, which can be seen as something that the server doesn't understand.

> A RADIUS server which supports authorize-only will
> probably want to return success for the request using that feature,
> but still must return failure for requests using methods it doesn't
> understand.  To make the distinction, you need an affirmative
> indication from the client that it wants authorize-only; 

Is that not provided by the Service-Type of Authorize-Only?

> that is,
> that it is not depending on the RADIUS server to verify the user's
> identity.          
> 
> 
>>>> I must note, BTW, that if you are trying to restrict what
>>>> information the RADIUS server gives out because you don't trust the
>>>> NAS, then giving out informaton based on what service the NAS
>>>> claims it is providing, or what port type the NAS claims the user
>>>> came in on, is kind of silly.
>> 
>> What's actually silly is talking about untrusted NASen at all: if a
>> RADIUS client that has a valid shared secret has been compromised,
>> life is pretty much over anyway.
> 
> Not necessarily.  With the kinds of authentication mechanisms which
> make authorize-only RADIUS attractive, a NAS never gains the ability
> to impersonate a user.  So, the service that NAS is providing
> probably has big problems, but the users' passwords haven't been
> compromised, and neither have other RADIUS clients.  The compromised
> device can be turned off, and the problem is gone.     
> 
> 
> -- Jeff

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, 25 Jul 2006 21:16:48 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 14:16:41 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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

> Glen Zorn writes...
> 
>> Aside from the fact that "Authorize Only" is hardly an authentication
>> method,  ...
> 
> It's been described as the "null" authentication method, purely from
> a conceptual viewpoint. 
> 
>> ... it seems a bit silly to define a new attribute to indicate that
>> other attributes are missing.  The absence of User-Password, etc.
>> would seem to be enough to implicitly select authorize-only...
> 
> Well, the new attribute need not be empty.  I could contain an
> identity string, for auditing purposes. 
> 
> I think that the use of User-Name to contain the auditing information
> (as you posited in a separate post) is problematic.  

Not sure I really understand this.

> I also think
> that omitting the User-Name as the only way to signal Authorize Only
> is also problematic.  

If User-Name is omitted, how do you know who is being authorized?

> The problems I see are with existing RADIUS
> server implementations.  Since the _presence_ of a particular kind of
> credential-bearing attribute has always selected the authentication
> method, I'm concerned about the backwards compatibility aspects of
> simply omitting any such.  Perhaps others have thoughts on this? 

Don't quite understand this either: if a server doesn't recognize the postulated Asserted-Identity Attribute, it seems that as far as it is concerned there will be no credential-bearing attribute in the message.  So just omitting any credential-bearing attribute (along with the addition of the other stuff we've been talking about) should get just the same response from a legacy server, right?
  
...

> 
>> What's actually silly is talking about untrusted NASen at all: if a
>> RADIUS client that has a valid shared secret has been compromised,
>> life is pretty much over anyway.
> 
> I think we have rough consensus on that point.

That's gratifying to hear!

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, 25 Jul 2006 21:12:23 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 17:12:10 -0400
To: <[email-masked]>, <[email-masked]>

Dave Harrington writes...

> But "provisioning SNMP parameters" explicitly does not include mapping
> to the access control subsytem; ...

I don't read that in the charter.  You apparently read it between the
lines.  Defining a new Access Control Subsystem or making changes to
VACM is explicitly out of scope.

> ...that is a separate issue that is out of scope for the WG,
> and should be dealt with in a separate document when such a
> document is included in a subsequent ISMS charter.

We've had this discussion many months ago.  My opinion hasn't changed.
I think that providing a way for RADIUS to provision group membership
information that can be used to map into any Access Control Subsystem
ought to be part of the work.  Especially if it does not actually affect
the architectural model, and is accomplished in an implementation
dependent fashion.

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

Delivery-date: Tue, 25 Jul 2006 21:00:21 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 17:00:08 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Jeff Hutzelman writes...

> If the RADIUS server wishes to log the NAS's request, it's welcome to
do
> so, but what information is relevant to that that's not a necessary
part
> of the request?

I think I've added some unintentional confusion.  Indeed, the "user
name" is necessary in the access request so that the server can perform
the profile lookup.  Someone had suggested on the list that additional
information _might_ be provided as an outcome of authentication that
could be additionally passed along for auditing purposes.  I think the
example was given of a Kerberos ticket.  Now I don't know if that makes
any sense, and the suggestion wasn't accompanied by a detailed use case.
So, maybe the auditing suggestion is a red herring.

--
to unsubscribe send a message 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, 25 Jul 2006 20:50:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 13:50:10 -0700

>What's actually silly is talking about untrusted NASen at all: if a RADIUS 
>client that has a valid >shared secret has been compromised, life is pretty 
>much over anyway.

There is still the 'cascading vulnerabilty' problem.

That is, compromise of a single NAS should not imply compromise of other 
services, NASes or users.

--
to unsubscribe send a message 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, 25 Jul 2006 20:33:37 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 16:33:14 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Glen Zorn writes...

> Aside from the fact that "Authorize Only" is hardly an authentication
> method,  ...

It's been described as the "null" authentication method, purely from a
conceptual viewpoint.

> ... it seems a bit silly to define a new attribute to indicate that
> other attributes are missing.  The absence of User-Password, etc.
would
> seem to be enough to implicitly select authorize-only...

Well, the new attribute need not be empty.  I could contain an identity
string, for auditing purposes.

I think that the use of User-Name to contain the auditing information
(as you posited in a separate post) is problematic.  I also think that
omitting the User-Name as the only way to signal Authorize Only is also
problematic.  The problems I see are with existing RADIUS server
implementations.  Since the _presence_ of a particular kind of
credential-bearing attribute has always selected the authentication
method, I'm concerned about the backwards compatibility aspects of
simply omitting any such.  Perhaps others have thoughts on this? 

I believe that the presence of User-Name already has a well defined
semantics.  I am concerned that the omission of User-Name may have
muddled semantics, given RFC 3576 implementations.  In RFC 3576 the
Service-Type of Authorize Only in an Access-Request provides that
signal.  We wish to use a Service-Type of Framed-Management (or some
such) in the ISMS use case, so we need another attribute to signal
Authorize Only.

> What's actually silly is talking about untrusted NASen at all: if a
RADIUS
> client that has a valid shared secret has been compromised, life is
pretty
> much over anyway.

I think we have rough consensus on that point.

--
to unsubscribe send a message 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, 25 Jul 2006 20:11:35 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 13:10:57 -0700
To: "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

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

> Jeffrey Hutzelman writes...
> 
>> Overloading Service-Type in this way was almost certainly a mistake;
>> ...
> 
> Perhaps.
> 
>> ...as you note, it prevents the attribute for being used for its
>> intended purpose, ...
> 
> In this case, providing a service hint.
> 
>> I think this is up to radext to fix; possibilities I can think of are
>> defining an "authorize-only" authentication mechanism, or defininig
>> a new attribute which carries the value that Service-Type would have
>> had. 
> 
> One suggestion that comes to mind is to create a new attribute called
> Asserted-Identity, which could be empty.  In RADIUS, the
> authentication method is implicitly selected by the inclusion of the
> corresponding credential-bearing attribute(s), such as User-Password,
> CHAP-Password, EAP-Message, etc.  Asserted-Identity could be the
> attribute which selects the Authorize Only authentication method.  

Aside from the fact that "Authorize Only" is hardly an authentication method, it seems a bit silly to define a new attribute to indicate that other attributes are missing.  The absence of User-Password, etc. would seem to be enough to implicitly select authorize-only...
   
> 
>> I must note, BTW, that if you are trying to restrict what
>> information the RADIUS server gives out because you don't trust the
>> NAS, then giving out informaton based on what service the NAS claims
>> it is providing, or what port type the NAS claims the user came in
>> on, is kind of silly.

What's actually silly is talking about untrusted NASen at all: if a RADIUS client that has a valid shared secret has been compromised, life is pretty much over anyway.

...

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, 25 Jul 2006 19:59:25 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 12:59:16 -0700
To: "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

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

...

> 
> There was also a suggestion on the list that the NAS convey the
> asserted identity to the RADIUS Server for audit purposes.  This
> could be accomplished by a (new) Asserted-Identity attribute.  

How would this be different than the User-Name attribute?

~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, 25 Jul 2006 19:47:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
Date: Tue, 25 Jul 2006 12:46:42 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "David Harrington" <[email-masked]>, "Eliot Lear" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Avi Lior <mailto:[email-masked]> supposedly scribbled:

> Hi,
> 
> If I was specifying how this is done:
> 
> It would be nice if the AAA client could return some sort of token to
> the AAA server to assert that the user has been authenticated by an
> entity that it trusts. The token can be generated by the
> Authentication Server.   
> 
> We need this assertion to make sure we deliver the correct profile.

I disagree: the fact that the message is being sent by an authenticated client at all says that the user has been authenticated elsewhere.  Note that safety requires the inclusion of a MAC (either the Message-Authenticator or preferably the Message-Authentication-Code Attribute) in the Access-Request.  

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, 25 Jul 2006 18:48:59 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 14:48:41 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

David Harrington writes...

> Ergo, I believe SSHSM should never use the "authorize-only" 
> feature.

I'm more that a little fuzzy on the architecture, the ASIs, etc., so
please bear with me.

I agree that the Access Control Subsystem will be the ultimate consumer
of the "fine granularity" authorization, such as that provided by
Management-Policy-ID, or a similar attribute.

It is my understanding, and please correct me if I miss some details,
that the Transport Mapping Subsystem (e.g. the SSN server) has the
responsibility of enforcing "coarse granularity" authorization, i.e.
whether a SNMP subsystem may be spawned by the SSH server.  It also has
the responsibility to pass along the securityName to the Access Control
Subsystem.  Given that any additional authorization information that
comes during an integrated RADIUS authentication and authorization also
needs to be passed along with the securityName, that implies some
participation by the Transport Mapping Subsystem.

In the case where RADIUS is only used for authorization, it could be
argued that it is the responsibility of the Access Control subsystem to
obtain that information.  I suppose the interface would be
implementation dependent.

This needs to be described somewhere.  If not in the RADIUS Usage for
SSHSM document, then where?

--
to unsubscribe send a message 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, 25 Jul 2006 18:38:23 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 14:38:03 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Jeffrey Hutzelman writes...

> Overloading Service-Type in this way was almost certainly a 
> mistake; ...

Perhaps.

> ...as you note, it prevents the attribute for being used for 
> its intended purpose, ...

In this case, providing a service hint.

> I think this is up to radext to fix; possibilities I can think of are
> defining an "authorize-only" authentication mechanism, or defininig a
new
> attribute which carries the value that Service-Type would have had.

One suggestion that comes to mind is to create a new attribute called
Asserted-Identity, which could be empty.  In RADIUS, the authentication
method is implicitly selected by the inclusion of the corresponding
credential-bearing attribute(s), such as User-Password, CHAP-Password,
EAP-Message, etc.  Asserted-Identity could be the attribute which
selects the Authorize Only authentication method. 

> I must note, BTW, that if you are trying to restrict what information
the
> RADIUS server gives out because you don't trust the NAS, then giving
out
> informaton based on what service the NAS claims it is providing, or
what
> port type the NAS claims the user came in on, is kind of silly.

Right.  But providing hints in the Access-Request message is still
necessary for the RADIUS server to make an informed policy decision as
to which service to provision, from among those allowed for the user,
and to put the corresponding attributes in the Access-Accept message.

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

Delivery-date: Tue, 25 Jul 2006 18:12:45 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 14:12:23 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard Aboba writes...

> Does the Service-Type of "Framed-Management" imply 
> authorization-only?

No.  It could equally be used when RADIUS is providing both
authentication and authorization.

> Or is it possible for authentication to be requested 
> as well?

Yes.

> For example, what attributes are used in existing SSH 
> implementations acting as a RADIUS client?

I rather suspect that existing implementations either ignore the
Service-Type (i.e. authenticate only) or expect something like
NAS-Prompt.

There is an issue to be worked out, and that it how does the NAS signal
to the RADIUS Server that it is seeking Authorize Only service
specifically for SSHSM?

The existing Authorize only usage in RFC 3576 suggests that:

   The NAS then sends an Access-Request
   to the RADIUS server with a Service-Type Attribute with value
   "Authorize Only".  This Access-Request SHOULD contain the NAS
   attributes from the Disconnect or CoA-Request, as well as the session
   attributes from the Request legal for inclusion in an Access-Request
   as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].  As
   noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
   SHOULD be included in an Access-Request that does not contain a
   User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.

So it seems clear that the Access-Request message, in the SSHSM
Authorize Only usage, should contain;

Service-Type = Authorize Only
Message-Authenticator

Plus various forms of ID attributes, such as NAS-IP-Address,
NAS-Identifier, etc.

But what else?

It would be typical to include:

Service-Type = Framed-Management
Framed-Management-Protocol = SNMPv3

as hints, however, the value of Service-Type conflicts.

Perhaps simply including: 

Framed-Management-Protocol = SNMPv3

is a sufficient hint to the RADIUS Server, along with Service-Type =
Authorize Only, to indicate the SSHSM Authorize Only use case.

I would fully expect that the Access-Accept message would contain:

Service-Type = Framed-Management
Framed-Management-Protocol = SNMPv3
Message-Authenticator

Plus what ever else might be desired.

There was also a suggestion on the list that the NAS convey the asserted
identity to the RADIUS Server for audit purposes.  This could be
accomplished by a (new) Asserted-Identity attribute.

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

Delivery-date: Tue, 25 Jul 2006 16:37:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 09:36:58 -0700

>Actually, in the NAS-Management draft we
>recommend that the Service-Type attribute be "Framed-Management" and the
>(new) Framed-Management-Protocol attribute be "SNMPv3".  I think that
>this is much cleaner than overloading the NAS-Port-Type.

This makes sense.

>Right.  For those deployments that are using non-RADIUS authentication
>today, the SSHSM usage of RADIUS will likely be for authorization only.

Does the Service-Type of "Framed-Management" imply authorization-only?  Or 
is it possible for authentication to be requested as well?   For example, 
what attributes are used in existing SSH implementations acting as a RADIUS 
client?

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

Envelope-to: [email-masked]
Delivery-date: Tue, 25 Jul 2006 16:09:49 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: [Isms] RE: Follow up on Authorize Only issue 
cc: [email-masked], [email-masked]
Date: Tue, 25 Jul 2006 12:00:40 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Uh, something like that.  Actually, in the NAS-Management draft we
> recommend that the Service-Type attribute be "Framed-Management" and the
> (new) Framed-Management-Protocol attribute be "SNMPv3".  I think that
> this is much cleaner than overloading the NAS-Port-Type.

  I agree.

  Alan DeKok.

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

Delivery-date: Tue, 25 Jul 2006 14:52:40 +0000
Content-class: urn:content-classes:message
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 10:52:09 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard Aboba writes...

> Typically this is handled by utilization of a unique Service-Type
> or NAS-Port-Type value.  The RADIUS policy engine then selects the 
> attribute set to be returned based on these values.

The values of NAS-Port-Type are (almost exclusively) related to media
type:

     0  Async
     1  Sync
     2  ISDN Sync
     3  ISDN Async V.120
     4  ISDN Async V.110
     5  Virtual
     6  PIAFS
     7  HDLC Clear Channel
     8  X.25
     9  X.75
    10  G.3 Fax
    11  SDSL - Symmetric DSL
    12  ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
        Modulation
    13  ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
    14  IDSL - ISDN Digital Subscriber Line
    15  Ethernet
    16  xDSL - Digital Subscriber Line of unknown type
    17  Cable
    18  Wireless - Other
    19  Wireless - IEEE 802.11
    20  Token-Ring  
    21  FDDI                                 
    22  Wireless - CDMA2000 
    23  Wireless - UMTS       
    24  Wireless - 1X-EV  
    25  IAPP   
    26  FTTP - Fiber to the Premises  
 27-29  Unassigned
    30  PPPoA - PPP over ATM  
    31  PPPoEoA - PPP over Ethernet over ATM 
    32  PPPoEoE - PPP over Ethernet over Ethernet  
    33  PPPoEoVLAN - PPP over Ethernet over VLAN  
    34  PPPoEoQinQ - PPP over Ethernet over IEEE 802.1QinQ 

While there have been proposals to over-load NAS-Port-Type with
application layer protocol information, I think this is not a good idea.

> As far as I know there is no specification for SSH authentication
> support within RADIUS so I'm not sure if this is true or not.

That is one of the issues that we have addressed in the NAS-Management
draft. (
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho
rization-03.txt )  SSH implementations use RADIUS today for
authentication, with or without a formal specification.  What is lacking
is a set of authorization attributes targeted at SSH, SNMP over SSH, and
similar use cases.

> For example, as I understand it SSH can support authentication 
> mechanisms such as Kerberos which are not supported in RADIUS.

SSH authentication support indeed extends beyond RADIUS.

> In this case it sounds like the NAS-Port-Type might be "SSH" but the
> Service-Type might be "SNMP".

Uh, something like that.  Actually, in the NAS-Management draft we
recommend that the Service-Type attribute be "Framed-Management" and the
(new) Framed-Management-Protocol attribute be "SNMPv3".  I think that
this is much cleaner than overloading the NAS-Port-Type.  Once could
argue that a generic service such as Framed-Management, with subsidiary
attributes such as Framed-Management-Protocol, is "too much".  One could
flatten all the combinations into a set of new service types.  I think
that the approach in the NAS-Management draft is more in line with
traditional RADIUS usages (e.g. Service-Type = Framed, and
Framed-Protocol = PPP).

> I think this depends on whether RADIUS can support all the required
> authentication methods.  If not, then either that support needs to 
> be added to RADIUS or only authorization will be available.

Right.  For those deployments that are using non-RADIUS authentication
today, the SSHSM usage of RADIUS will likely be for authorization only.
The goal of the ISMS WG is to re-use existing AAA infrastructures.
Where RADIUS is already in use, it would naturally be used for both
authentication and authorization.  Where it is not already in use, it
may be used only for authorization.
 
> Question:  In the case where SSH is used, do you just need SSH 
> attributes, or are SNMP attributes required there as well?

This is addressed in the NAS-Management draft.  Provisioning of "plain"
SSH, SNMPv3 over SSH, and other protocol combinations are described.
So, yes, more than a single attribute (or single service provisioning
description) is necessary.

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

Delivery-date: Tue, 25 Jul 2006 13:26:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue
Date: Tue, 25 Jul 2006 09:26:32 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Well I am not exactly against using an Authorize Only in this way.

I do recognize that there is a severe security issue.

However, I still think designers need to be aware of the issues and
design appropriately.

We in the IETF need to make sure that designers are aware of the
security risk of a particular feature.  That is afterall what the
Security section is about.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, July 23, 2006 5:31 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Follow up on Authorize Only issue
> 
> >A compromised NAS can leverage this requested feature to obtain that 
> >information more readily.  Right now, if the NAS hasn't had 
> a user log 
> >in through it, it can get those credentials only through a 
> brute force 
> >attack on the password.  The server *should* be able to catch that 
> >attack, mitigating the vulnerability.
> 
> Right.
> 
> > > If this is allowed, it should follow the principle of "least 
> > > privilege", only providing the attributes relevant to SSH.
> >
> >Which means that the Access-Request has to be recognizable 
> as for SSH 
> >in this use-case.  This means an attribute or value specifically for 
> >this purpose.  The RADIUS server can then key off of that special 
> >request, and return a limited response.
> 
> Right.  For example an additional Service-Type value of "SSH" 
> could be allocated One concern would be whether an attacker 
> could use this Service-Type with any NAS-Port-Type, in order 
> to retrieve attributes relevant to that NAS-Port-Type.  To 
> prevent this,  one possibility is to add NAS-Port-Type values 
> of "SSH" and "ISMS" (since different attributes might be 
> returned for a straight SSH or SSH-protected ISMS session) 
> and only allow Service-Type="SSH" to be used with those 
> NAS-Port-Type values; all other NAS-Port-Type values would 
> result in an Access-Reject.
> 
> >The use case should also enumerate the possible attributes 
> and values 
> >needed in the Access-Accept, and state explicitely that 
> responding with 
> >any other attributes or values may result in security 
> violations.  i.e. 
> >Other attributes and values SHOULD NOT be sent in the Access-Accept.
> 
> Makes sense.
> 
> 
> 
> --
> to unsubscribe send 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, 25 Jul 2006 04:24:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: [Isms] RE: Follow up on Authorize Only issue
Date: Mon, 24 Jul 2006 21:23:35 -0700

>OK. If RADIUS supports this, we can probably ask for specific
>attributes or attribute sets.

Typically this is handled by utilization of a unique Service-Type or 
NAS-Port-Type value.  The RADIUS policy engine then selects the attribute 
set to be returned based on these values.

>There are multiple possible proposals on the ISMS table, and we are
>trying to determine what RADIUS can or cannot provide for us.
>
>We know that RADIUS can provide SSH-related attributes when the user
>connects to the NAS using an SSH session and RADIUS provides the
>authentication.

As far as I know there is no specification for SSH authentication support 
within RADIUS so I'm not sure if this is true or not.  For example, as I 
understand it SSH can support authentication mechanisms such as Kerberos 
which are not supported in RADIUS.

>We know that the RADIUS server might be able to provide SNMP-related
>attributes when the user connects to the NAS using an SSH transport
>and RADIUS provides the authentication.

In this case it sounds like the NAS-Port-Type might be "SSH" but the 
Service-Type might be "SNMP".

>We do not need "authorize-only" support for those situations, since
>RADIUS would be doing the authentication.

I think this depends on whether RADIUS can support all the required 
authentication methods.  If not, then either that support needs to be added 
to RADIUS or only authorization will be available.

>The authentication might have been provided via Kerberos
>or TLS or SNMPv3's USM, but RADIUS is not involved in the
>authentication, only the (later) authorization.

In this case you might have a Service-Type of "SNMP" and a NAS-Port-Type of 
"SNMP".

>The attributes we want to see are
>specific to SNMP, or to Network Management via SNMP/Netconf/CLI, etc.
>
>If RADIUS supports it, the RADIUS client may be able to identify that
>the request is associated wih an SNMP engine, so the server can return
>only SNMP-related attributes.

A Service-Type of "SNMP" with a NAS-Port-Type of "SNMP" could be used to 
indicate this.

Question:  In the case where SSH is used, do you just need SSH attributes, 
or are SNMP attributes required there as well?   In other words, how is SSH 
for SNMP distinguished from plain old SSH?

--
to unsubscribe send a message 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, 24 Jul 2006 22:03:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
Date: Mon, 24 Jul 2006 18:03:35 -0400
To: "David Harrington" <[email-masked]>, "Eliot Lear" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi,

If I was specifying how this is done:

It would be nice if the AAA client could return some sort of token to
the AAA server to assert that the user has been authenticated by an
entity that it trusts. The token can be generated by the Authentication
Server.

We need this assertion to make sure we deliver the correct profile.

Even if we don't have this type of interaction I still think that we
should support Authorize-Only for this type of transaction.  Since this
can be used in cases where the NAS is absolutely trusted or there are
other means to secure the NAS/AAA -- eg in a closed system.

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 4:01 PM
> To: 'Eliot Lear'
> Cc: Avi Lior; 'Nelson, David'; [email-masked]; [email-masked]
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Hi Eliot,
> 
> The ISMS concern is that some operators want to use 
> authentication mechanisms other than RADIUS to authenticate 
> the SNMP principal (which may or may not be a human user), 
> but would like to be able to use a RADIUS server to provide 
> information about what "SNMP-policy" (think SNMP-specific 
> FilterID) the SNMP agent should apply regarding "which SNMP 
> operations to what SNMP data sets" the already-authenticated 
> "user" is permitted. 
> 
> And they would like to get the SNMP-policy without having to 
> perform another authentication of the principal via the 
> RADIUS server, since requiring that might force the operators 
> to store the principal's authentication credentials at the 
> SNMP agent or require the realtime intervention of a human 
> being. The "NAS" has already done an authentication and does 
> not want to waste resources doing yet another one.
> 
> We only want this "authorize-only" service to be performed at 
> the request of an authenticated/trusted RADIUS client. If the 
> AAA trust for an ISMS-related client is compromised, the 
> situation should be identical to that of any other 
> compromised AAA client - all bets are off concerning the 
> behavior of the RADIUS client.  
> 
> Who provides the hints that identify which set of attributes 
> should be returned in a request-accept? The AAA client? If 
> the AAA client is compromised, who provides the hints that 
> identify which set of attributes should be returned?
> 
> dbh
> 
> > -----Original Message-----
> > From: Eliot Lear [mailto:[email-masked]]
> > Sent: Monday, July 24, 2006 3:16 PM
> > To: David Harrington
> > Cc: 'Avi Lior'; 'Nelson, David'; [email-masked];
> [email-masked]
> > Subject: Re: Follow up on Authorize Only issue (was RE: 
> > [Isms] ISMS session
> > 
> > Dave,
> > > Hi,
> > >
> > > Let me point out that authorize only is being requested for use
> with
> > > SNMP. The NAS is effectively the SNMP agent, and the RADIUS 
> > > interaction is to determine which data the already authenticated 
> > > principal should be allowed to access.
> > >
> > > If the NAS is compromised, then the SNMP agent is 
> compromised, and 
> > > within the scope of the managed entity, you are probably already 
> > > toast, with or without support from RADIUS. And if the SNMP agent
> is
> > > compromised, then an attacker probably doesn't much care what
> RADIUS
> > > has to say about accessing the SNMP MIB.
> > >   
> > 
> > I've lost the plot just a little here.  I thought the concern was 
> > beyond the scope of the managed entity but the broader 
> service area of 
> > the radius server.
> > 
> > Eliot
> > 
> 
> 

--
to unsubscribe send a message 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, 23 Jul 2006 21:31:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Follow up on Authorize Only issue
Date: Sun, 23 Jul 2006 14:31:12 -0700

>A compromised NAS can leverage this requested feature to obtain
>that information more readily.  Right now, if the NAS hasn't had a
>user log in through it, it can get those credentials only through a
>brute force attack on the password.  The server *should* be able to
>catch that attack, mitigating the vulnerability.

Right.

> > If this is allowed, it should follow the principle of "least privilege",
> > only providing the attributes relevant to SSH.
>
>Which means that the Access-Request has to be recognizable as for
>SSH in this use-case.  This means an attribute or value specifically
>for this purpose.  The RADIUS server can then key off of that special
>request, and return a limited response.

Right.  For example an additional Service-Type value of "SSH" could be 
allocated One concern would be whether an attacker could use this 
Service-Type with any NAS-Port-Type, in order to retrieve attributes 
relevant to that NAS-Port-Type.  To prevent this,  one possibility is to add 
NAS-Port-Type values of "SSH" and "ISMS" (since different attributes might 
be returned for a straight SSH or SSH-protected ISMS session) and only allow 
Service-Type="SSH" to be used with those NAS-Port-Type values; all other 
NAS-Port-Type values would result in an Access-Reject.

>The use case should also enumerate the possible attributes and
>values needed in the Access-Accept, and state explicitely that
>responding with any other attributes or values may result in security
>violations.  i.e. Other attributes and values SHOULD NOT be sent in
>the Access-Accept.

Makes sense.

--
to unsubscribe send a message 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, 23 Jul 2006 16:02:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue
Date: Sun, 23 Jul 2006 09:02:01 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Bernard Aboba <> supposedly scribbled:

> The security implications of unrestricted access to *any* user
> attributes are fairly severe. 

I agree, but apparently not severe enough to warrant changing the way RADIUS handles CHAP at any time over, oh , the last 10 years.

> 
> For example, should a NAS be able to retrieve the Tunnel-Password
> attribute of any user, regardless of whether they are connected? 

Of course not, but there are arguably lots of things that shouldn't be yet are: the point is that allowing Authorize-Only in this case actually doesn't open any new security holes.

> 
> There are also VSAs that contain sensitive information.
> 
> The Call-Check Service typically provides very little information in
> the Access-Accept (all that is needed is whether to accept or reject
> the call) so there is minimal leakage.  
> 
> If this is allowed, it should follow the principle of "least
> privilege", only providing the attributes relevant to SSH. 
> 
> 
> 
> 
>> For the SSHSM usage case, the question is whether it is an
>> unacceptable security risk for a trusted NAS to be able to obtain
>> authorization information about a user that is not actually
>> "present"  at the NAS?

OK, this is becoming slightly absurd.  I am not a cryptographer, but I do know that one of the cardinal assumptions of secret-key cryptography is that the secret key stays secret.  This "trusted NAS" should not be trusted because the secret has been compromised; if the secret is no longer a secret, all bets are off. 

Hope this helps,

~gwz

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

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

Envelope-to: [email-masked]
Delivery-date: Sat, 22 Jul 2006 15:27:14 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Follow up on Authorize Only issue 
cc: [email-masked], [email-masked]
Date: Sat, 22 Jul 2006 11:17:37 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> For example, should a NAS be able to retrieve the Tunnel-Password attribute 
> of any user, regardless of whether they are connected?

  i.e. A compromised NAS can leverage this requested feature to obtain
that information more readily.  Right now, if the NAS hasn't had a
user log in through it, it can get those credentials only through a
brute force attack on the password.  The server *should* be able to
catch that attack, mitigating the vulnerability.

  For users who have logged in through a compromised NAS, nearly all
hope for security is lost.

> If this is allowed, it should follow the principle of "least privilege", 
> only providing the attributes relevant to SSH.

  Which means that the Access-Request has to be recognizable as for
SSH in this use-case.  This means an attribute or value specifically
for this purpose.  The RADIUS server can then key off of that special
request, and return a limited response.

  The use case should also enumerate the possible attributes and
values needed in the Access-Accept, and state explicitely that
responding with any other attributes or values may result in security
violations.  i.e. Other attributes and values SHOULD NOT be sent in
the Access-Accept.

  Alan DeKok.

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

Delivery-date: Sat, 22 Jul 2006 06:58:22 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Follow up on Authorize Only issue
Date: Fri, 21 Jul 2006 23:57:53 -0700

The security implications of unrestricted access to *any* user attributes 
are fairly severe.

For example, should a NAS be able to retrieve the Tunnel-Password attribute 
of any user, regardless of whether they are connected?

There are also VSAs that contain sensitive information.

The Call-Check Service typically provides very little information in the 
Access-Accept (all that is needed is whether to accept or reject the call) 
so there is minimal leakage.

If this is allowed, it should follow the principle of "least privilege", 
only providing the attributes relevant to SSH.

>For the SSHSM usage case, the question is whether it is an
>unacceptable security risk for a trusted NAS to be able to obtain
>authorization information about a user that is not actually
>"present"  at the NAS?

--
to unsubscribe send a message 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, 21 Jul 2006 21:29:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue
Date: Fri, 21 Jul 2006 14:27:47 -0700
From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

I agree with Avi, Glen and Alan.   

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Friday, July 21, 2006 1:44 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Follow up on Authorize Only issue
> 
> > For the SSHSM usage case, the question is whether it is an 
> > unacceptable security risk for a trusted NAS to be able to obtain 
> > authorization information about a user that is not actually 
> "present" 
> > at the NAS?
> 
> My interpretation is that three respondents (Glen, Alan, Avi) 
> believe that the answer is "no".  The existing RADIUS trust 
> model collapses if the NAS has been compromised and does 
> nefarious or foolish things.
> 
> I'd like to determine if we have consensus on this position.  If you
> *have* an opinion on this issue, please *respond* whether you 
> agree or disagree with this assertion.
> 
> 
> --
> to unsubscribe send 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, 21 Jul 2006 20:44:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue
Date: Fri, 21 Jul 2006 16:43:47 -0400
To: <[email-masked]>, <[email-masked]>

> For the SSHSM usage case, the question is whether it 
> is an unacceptable security risk for a trusted NAS to be 
> able to obtain authorization information about a user that
> is not actually "present" at the NAS?

My interpretation is that three respondents (Glen, Alan, Avi) believe
that the answer is "no".  The existing RADIUS trust model collapses if
the NAS has been compromised and does nefarious or foolish things.

I'd like to determine if we have consensus on this position.  If you
*have* an opinion on this issue, please *respond* whether you agree or
disagree with this assertion.

--
to unsubscribe send a message 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, 21 Jul 2006 18:45:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session
Date: Fri, 21 Jul 2006 14:44:52 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

 David,

I agree with Glen and Alan.

NAS is within the trust boundary of AAA.  

If you comprise the NAS you are done.  It can leak information, modify
accounting, disallow or allow services that are not authorized.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Tuesday, July 18, 2006 6:10 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Follow up on Authorize Only issue (was RE: 
> [Isms] ISMS session
> 
> Avi Lior writes...
>  
> > I am having trouble understanding "user that is not 
> actually present".
> 
> In the proposed use case, the NAS could request, from a 
> RADIUS server, authorization information for a user that it 
> asserts is present, but is not.  The RADIUS server cannot 
> tell, since no user credentials are presented.  Well behaved 
> NASes won't do this.  One might argue that all trusted NASes 
> will be well behaved, but that makes certain threat model assumptions.
> 
> Why would a (compromised) NAS want to do this?  Well, leaking 
> authorization information on various user accounts may help 
> an attacker select high value target accounts. 
> 
> The only standardized scenario for non-authenticated 
> authorization RADIUS is call check.  The assumption is that 
> the PSTN is a reliable source of the telephone number(s), the 
> NAS is trusted and non-compromised, and the user will 
> typically be authenticated once the session is initiated.  
> Thus, the risk is relatively low.
> 
> For Dynamic RADIUS, RFC 3576 requires a State attribute, 
> which can only have come from a previous successful authentication.
> 
> In this particular ISMS use case, SNMP service is authorized 
> based on the assertion of identity of the user by the NAS, 
> without the RADIUS server ever having performed an 
> authentication, and without the benefit of the resultant 
> State attribute.  Thus, the risk is potentially higher.
> 
> The questions at hand are whether the risk is high enough to 
> be of serious concern, and whether or not it can be mitigated?
> 
> 
> --
> to unsubscribe send 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, 20 Jul 2006 17:52:51 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Issues & fixes (was Re: Tagged attibutes ) 
cc: [email-masked]
Date: Thu, 20 Jul 2006 13:43:25 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> I respectfully disagree.  RFC 2868 also says:
...
> Both the ASCII art and the sentence "If the Tag field is unused, it MUST
> be zero (0x00)." tell me that that Tag Field is not optional.  It is
> always present in these attributes, and if it is not used it is set to
> zero, rather than omitted.

  I agree, and that doesn't invalidate my earlier comments.

  The Tunnel-Type attribute overloads the "integer" types previously
defined in RFC 2865.  The intent was that older RADIUS servers can
treat the 4 octets of "tag + value" as a 32-bit integer, for full
compatibility.  So for "integer" types, the requirement that they be 4
octets means that the tag field MUST be present, and MUST be zero if
unused.

  Let's look at another attribute:

3.3.  Tunnel-Client-Endpoint
...
   A summary of the Tunnel-Client-Endpoint Attribute format is shown
   below.  The fields are transmitted from left to right.

    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     |       Tag     |    String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.
...

  i.e. there is NO requirement here that the tag be set to zero if
it's unused.  This is because this attribute is overloading the
"text/string" types previously defined in RFC 2865.  As many older
servers treat the attributes as C strings, a requirement to always put
a tag of 0 for "no tag" would mean breaking backwards compatibility
with those servers.

  The original question starting this was about
Tunnel-Private-Group-Id, which is also "tag + string".

  If a RADIUS server *always* puts a tag of zero for "no tag", then
there are other servers out there, and probably clients, which will
interpret that attribute as being an empty string.

> Now, I realize that it is possible to omit the Tag Field and parse the
> packet correctly when the first octet of the value field is not a Tag
> and is greater than 0x1F or less than 0x00.  I think that RFC 2868 is
> internally inconsistent in this regard and that we should indeed address
> this issue in the Issues & Fixes document.

  I don't see any inconsistency in RFC 2868.  I see that the
requirement to be backwards compatible is more important than the
requirement to always put a tag in a "string" attribute.

  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, 20 Jul 2006 15:44:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Issues & fixes (was Re: Tagged attibutes )
Date: Thu, 20 Jul 2006 11:44:13 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

> > So we know what to do if the tag is greater then 0. 
> > But what do we do it it is equal to zero?
> 
> My opinion is that the tag should be suppressed, and not
> put into the attribute.

I respectfully disagree.  RFC 2868 also says:

<quote>

   A summary of the Tunnel-Type Attribute format is shown below.  The
   fields are transmitted from left to right.

    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     |     Tag       |     Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Value (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      64 for Tunnel-Type

   Length
      Always 6.

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the Tag field is unused, it MUST be zero (0x00).

</quote>

Both the ASCII art and the sentence "If the Tag field is unused, it MUST
be zero (0x00)." tell me that that Tag Field is not optional.  It is
always present in these attributes, and if it is not used it is set to
zero, rather than omitted.

Now, I realize that it is possible to omit the Tag Field and parse the
packet correctly when the first octet of the value field is not a Tag
and is greater than 0x1F or less than 0x00.  I think that RFC 2868 is
internally inconsistent in this regard and that we should indeed address
this issue in the Issues & Fixes document.

--
to unsubscribe send 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, 20 Jul 2006 15:23:29 +0000
From: "Alan DeKok" <[email-masked]>
To: Tomasz Wolniewicz <[email-masked]>
Subject: Issues & fixes (was Re: Tagged attibutes )
cc: [email-masked]
Date: Thu, 20 Jul 2006 11:13:48 -0400
Message-Id: <[email-masked]>

Tomasz Wolniewicz <[email-masked]> wrote (edited):
>   I have recently got hit by  a VLAN setting problem and lack of
> interoperability between ZZZ Radius server and 3COM access-point.
> As it turned out, it seems that the access-point does not handle tagged
> attributes. On the other hand ZZZ does a strange thing when one
> does not specify the tag.  I looked at RFC 2868 and found out that it is
> impossible to tell who gets things wrong. The RFC says:
> 
> 3.6.  Tunnel-Private-Group-ID
> 
> ....
> ....
> 
> The Tag field is one octet in length and is intended to provide a
>       means of grouping attributes in the same packet which refer to the
>       same tunnel.  If the value of the Tag field is greater than 0x00
>       and less than or equal to 0x1F, it SHOULD be interpreted as
>       indicating which tunnel (of several alternatives) this attribute
>       pertains.  If the Tag field is greater than 0x1F, it SHOULD be
>       interpreted as the first byte of the following String field.
> 
> So we know what to do if the tag is greater then 0. But what do we do it
> it is equal to zero? 

  My opinion is that the tag should be suppressed, and not put into
the attribute.

> the RFC does not say that it MUST NOT be equal to zero. FreeRadius
> seems to handle tags equal to zero well, but if you try to set a tag
> to zero in the configuration, the FreeRadius will simply send an
> untagged value. ZZZ, however sets the tag to 0 and there seems
> to be no way to make it to send an untagged value.

  If the other server sends a tag with value zero, the client SHOULD
ignore it.

> My 3COM AP obviously has a problem that it does not handle tags greater
> then 0 but with those equal to 0 things are not so clear.

  It would appear then that the problem mainly lies with the AP, which
implements support for tagged attributes... so long as they don't have
a tag.  If the other RADIUS server can't be made to suppress the tag
of zero, then there is an interoperability problem.

> So my point is - don't you think that RFC 2868 should be fixed as well
> and that such a thing would fit into the draft that you are co-authoring?

  We could mention it in the "issues and fixes" document.  Client
implementations that support tagged attributes, but don't support the
tag in those attributes are... odd.

  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: Wed, 19 Jul 2006 04:10:14 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) 
cc: [email-masked], [email-masked]
Date: Wed, 19 Jul 2006 00:00:44 -0400
Message-Id: <[email-masked]>

"Glen Zorn \(gwz\)" <[email-masked]> wrote:
> OK, yeah, but I didn't say anything about guesses: in that scenario, the
> compromised NAS has saved valid credentials from previous > authentications & used them for nefarious purposes.

  It could also save authorization parameters, for precisely the same
reason.

> I hope that the issue is not divulging the contents of RADIUS attributes
> but something a bit more serious, like authorizing an imposter.

  A compromised NAS can authorize anyone it chooses for any purpose.

  If the threat we're trying to avoid is a compromised NAS, then there
is little point in doing more security analysis.  The NAS is *inside*
of the RADIUS trust boundary, with all of the side-effects that result.

  If the threat we're trying to avoid is someone fooling a trusted NAS
into leaking information about users, then that situation is somewhat
more managable.

  Alan DeKok.

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

Delivery-date: Tue, 18 Jul 2006 23:55:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) 
Date: Tue, 18 Jul 2006 16:54:42 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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

> "Glen Zorn \(gwz\)" <[email-masked]> wrote:
>> The risk I mention above has never seemed to bother anyone, at least
>> not enough to fix it;
> 
>   True.  I think the concern here is that the user has not been
> authenticated.  In the above scenario, the bad guesses 

OK, yeah, but I didn't say anything about guesses: in that scenario, the compromised NAS has saved valid credentials from previous authentications & used them for nefarious purposes.

> have been
> rejected, and no additional information leaks from the RADIUS server
> to the NAS.  If the user is authenticated, then information about the
> user can, and should be sent from the server to the NAS.    
> 
>   I could rephrase the original question as: what information can the
> RADIUS server send to the NAS about the user, if the user was not
> authenticated through RADIUS?  
> 
>   For privacy and security, I think the answer is "none".  For useful
> networks, I think "authorize only" is pretty safe. 
> 
>   If we look at another threat scenairo: A user is authenticated
> through RADIUS, and RADIUS returns authorization parameters in the
> Access-Accept.  Since the contents of RADIUS packets aren't
> encrypted, anyone who can see that traffic can see all of the users
> authorization.  So the information could be construed as public.    
> 
>   In that case, there's little additional risk in sending that
> information, again unencrypted, to a NAS without authenticating the
> user.  
> 
>   If the traffic *is* encrypted, then the previous analysis doesn't
> apply... 

I hope that the issue is not divulging the contents of RADIUS attributes but something a bit more serious, like authorizing an imposter.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Jul 2006 22:54:28 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) 
cc: [email-masked], [email-masked]
Date: Tue, 18 Jul 2006 18:45:05 -0400
Message-Id: <[email-masked]>

"Glen Zorn \(gwz\)" <[email-masked]> wrote:
> The risk I mention above has never seemed to bother anyone, at least not
> enough to fix it;

  True.  I think the concern here is that the user has not been
authenticated.  In the above scenario, the bad guesses have been
rejected, and no additional information leaks from the RADIUS server
to the NAS.  If the user is authenticated, then information about the
user can, and should be sent from the server to the NAS.

  I could rephrase the original question as: what information can the
RADIUS server send to the NAS about the user, if the user was not
authenticated through RADIUS?

  For privacy and security, I think the answer is "none".  For useful
networks, I think "authorize only" is pretty safe.

  If we look at another threat scenairo: A user is authenticated
through RADIUS, and RADIUS returns authorization parameters in the
Access-Accept.  Since the contents of RADIUS packets aren't encrypted,
anyone who can see that traffic can see all of the users
authorization.  So the information could be construed as public.

  In that case, there's little additional risk in sending that
information, again unencrypted, to a NAS without authenticating the
user.

  If the traffic *is* encrypted, then the previous analysis doesn't
apply...

  Alan DeKok.

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

Delivery-date: Tue, 18 Jul 2006 22:35:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary)
Date: Tue, 18 Jul 2006 15:34:40 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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

...

> 
> In this particular ISMS use case, SNMP service is authorized based on
> the assertion of identity of the user by the NAS, without the RADIUS
> server ever having performed an authentication, and without the
> benefit of the resultant State attribute.  Thus, the risk is
> potentially higher.   

Actually, the same risk has always been present in RADIUS, because of the way that PPP CHAP (&, for that matter, the MD5-Challenge EAP method) is implemented.  The RADIUS server in the CHAP case generally has no idea whether the user is actually present or not: the NAS presents the server with a self-generated challenge and a response that may or may not be a replay; without saving every challenge-response pair, the server cannot know if the response is fresh or not.
 
> 
> The questions at hand are whether the risk is high enough to be of
> serious concern, and whether or not it can be mitigated? 

The risk I mention above has never seemed to bother anyone, at least not enough to fix it; I don't know why we should be obsessing over it now.

...

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, 18 Jul 2006 22:10:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session  summary)
Date: Tue, 18 Jul 2006 18:10:20 -0400
To: <[email-masked]>, <[email-masked]>

Avi Lior writes...
 
> I am having trouble understanding "user that is not actually present".

In the proposed use case, the NAS could request, from a RADIUS server,
authorization information for a user that it asserts is present, but is
not.  The RADIUS server cannot tell, since no user credentials are
presented.  Well behaved NASes won't do this.  One might argue that all
trusted NASes will be well behaved, but that makes certain threat model
assumptions.

Why would a (compromised) NAS want to do this?  Well, leaking
authorization information on various user accounts may help an attacker
select high value target accounts. 

The only standardized scenario for non-authenticated authorization
RADIUS is call check.  The assumption is that the PSTN is a reliable
source of the telephone number(s), the NAS is trusted and
non-compromised, and the user will typically be authenticated once the
session is initiated.  Thus, the risk is relatively low.

For Dynamic RADIUS, RFC 3576 requires a State attribute, which can only
have come from a previous successful authentication.

In this particular ISMS use case, SNMP service is authorized based on
the assertion of identity of the user by the NAS, without the RADIUS
server ever having performed an authentication, and without the benefit
of the resultant State attribute.  Thus, the risk is potentially higher.

The questions at hand are whether the risk is high enough to be of
serious concern, and whether or not it can be mitigated?

--
to unsubscribe send a message 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, 18 Jul 2006 21:29:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary)
Date: Tue, 18 Jul 2006 17:29:29 -0400
From: "Avi Lior" <[email-masked]>
To: <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi

> > 
> > For the SSHSM usage case, the question is whether it is an 
> > unacceptable security risk for a trusted NAS to be able to obtain 
> > authorization information about a user that is not actually 
> "present" at the NAS?
> 
> This probably needs more thought and discussion.
> 
I am having trouble understanding "..user that is not actually present"

Why are we sending authorization attributes to a NAS where the user is
not actually present.

I have seen scenarios where we push authorization attributes to a NAS
and hence that creates a Session for a user using COA for example. 

> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message 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, 15 Jul 2006 19:29:55 +0000
Date: Sat, 15 Jul 2006 21:29:20 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary)
Reply-To: [email-masked]
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

On Thu, Jul 13, 2006 at 04:59:18PM -0400, Nelson, David wrote:
> 
> In an Access-Accept message, the NAS is trusted to have authorization
> information for the user because (a) the NAS is trusted and (b) the user
> is present at the NAS, so the NAS has a "need to know".  The concerns
> with Authorize Only operations, that do not have a previous successful
> RADIUS authentication as a prerequisite, is that when the user is not
> present at the NAS, the NAS does not have a "need to know" the user's
> authorization status.  Information might be leaked to a NAS about users,
> that the NAS would not otherwise be entitled to have.

Thanks, I think I understand this. Now I wonder how other AAA systems
which I have been told to support authorize only deal with this issue.
Can someone please explain?
 
> IN RFC 3576, the requirement for a previous RADIUS authentication is met
> by requiring a server State attribute t be in the Access-Request
> message, which provides that binding for Authorize Only operation.

If I understand this correctly, then you have (a) the NAS is trusted
and (b) the user was previously present at the NAS here. Correct?

> The only form of RADIUS operation that currently provides authorization
> information on a "user" without user credentials is the call check
> operation.  In these cases the actual user is not identified, but rather
> the user's phone number (or similar network address information).
> 
> For the SSHSM usage case, the question is whether it is an unacceptable
> security risk for a trusted NAS to be able to obtain authorization
> information about a user that is not actually "present" at the NAS?

This probably needs more thought and discussion.

Thanks for discussing this issue and writing things up in a way that I
seem to understand.

/js

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

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

Delivery-date: Sat, 15 Jul 2006 17:47:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Is there interest in Radius MIB notifications?
Date: Sat, 15 Jul 2006 10:46:28 -0700
To: "Carl Kalbfleisch" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_00B4_01C6A775.8032C160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I'd be interested in seeing this progress.

MS 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Carl Kalbfleisch
> Sent: Wednesday, July 12, 2006 5:55 AM
> To: [email-masked]
> Subject: Is there interest in Radius MIB notifications?
> 
> 
> Hi,
> 
> Our customers desire SNMP Notifications when the "state" of 
> the radius server that the client is using changes. IE, when 
> timeouts occur send a notification and then when responses 
> are received again send another notification. 
> 
> Is there general interest/demand for this?
> 
> Essentially I am planning an enterprise extension to the 
> Radius Authentication and Accounting Client MIBs which are 
> defined in draft-ietf-radext-rfc2618bis-04.txt  and 
> draft-ietf-radext-rfc2620bis-04.txt
> 
> Carl
> 
> --
> to unsubscribe send 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_000_00B4_01C6A775.8032C160
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00B4_01C6A775.8032C160--

--
to unsubscribe send 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, 14 Jul 2006 18:38:03 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) 
Date: Fri, 14 Jul 2006 14:28:46 -0400
Message-Id: <[email-masked]>

 "Alan DeKok" <[email-masked]> wrote:
>   If the server had some auditing capability for Authorize-Only
> requests, an admin could correlate that information with
> authentication performed by non-RADIUS servers.  That would mitigate
> the concerns over the RADIUS server not performing the authorization.
                                                         ^^^^^^^^^^^^^

  "authentication".

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Jul 2006 18:31:24 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) 
cc: [email-masked], [email-masked]
Date: Fri, 14 Jul 2006 14:22:10 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> For the SSHSM usage case, the question is whether it is an unacceptable
> security risk for a trusted NAS to be able to obtain authorization
> information about a user that is not actually "present" at the NAS?

  i.e. "present" as in "the RADIUS server performed the
authentication, and verified that the user is present".

  Is there any *other* authentication credentials that can be sent to
the RADIUS server, to mitigate the issue?  e.g. A kerberos ticket?

  The RADIUS server could either validate the kerberos ticket itself,
or log the ticket for later auditing.  If it's too hard to send the
ticket, maybe a hash of the ticket, or ticket ID (I'm not sure if this
is available or useful in Kerberos..)

  If the server had some auditing capability for Authorize-Only
requests, an admin could correlate that information with
authentication performed by non-RADIUS servers.  That would mitigate
the concerns over the RADIUS server not performing the authorization.

  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, 14 Jul 2006 18:23:27 +0000
Content-class: urn:content-classes:message
Subject: RE: WGLC comments for draft-ietf-geopriv-radius-lo-07
Date: Fri, 14 Jul 2006 20:22:57 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi,

Thanks Pasi for the detailed review. One comment on the TADIG
codes. See below:
 
[snip]

> I do have a couple of minor and mostly editorial comments, though:
> 
> 1) Section 5.1 says:
> 
>    "GSM (0):
> 
>    This namespace 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 of this type."
> 
> The GSM system uses many different codes to identify operators in
> different contexts; thus, this probably should be called "GSM_TADIG"
> or just "TADIG". Also, we need a reference (any kind of reference is
> better than none), expand the acronym, and specify how the value is
> encoded.
> 
> Suggested text:
> 
>    TADIG (0):
>    
>    This namespace can be used to indicate operator names based on
>    Transferred Account Data Interchange Group (TADIG) codes defined in
>    [NNN]. TADIG codes are assigned by the TADIG Working Group within
>    the GSM Association. The TADIG code consists of five uppercase
>    ASCII characters.

The TADIG code consists of 3 character country code and 2 character
operator/company code. The latter can actually be alphanumeric. E.g.
one of ours is FINV1. So it might be better to state this. For example:

     The TADIG Code consists of two fields, with a total length of five
     ASCII characters consisting of a three-character country code and
     a two-character aplhanumeric operator (or company) ID.

>    [NNN] GSM Association, "TADIG Naming Conventions, Version 4.1", 
>    GSM Association Official Document TD.13, June 2006.
> 
> (The document is not currently on the GSMA web site, but it is
> classified "Unrestricted". I talked with Jouni Korhonen about this and
> he promised to find out if it could be made more easily available.)

[snap]

> Best regards,
> Pasi

Cheers,
	Jouni

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

--
to unsubscribe send a message 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, 14 Jul 2006 13:28:39 +0000
Content-class: urn:content-classes:message
Subject: WGLC comments for draft-ietf-geopriv-radius-lo-07
Date: Fri, 14 Jul 2006 16:25:55 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This document has been around for a long time, and we really should
get it out. I think there are some parts of the document that are
unnecessarily complex and/or inelegant, but I understand that they're
a result of a long process of making the document acceptable to
various constituencies. Since my objections would be of the "it could
be nicer" type rather than "it doesn't work", I won't complain them
now. Let's get this out; it's good enough.

I do have a couple of minor and mostly editorial comments, though:

1) Section 5.1 says:

   "GSM (0):

   This namespace 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 of this type."

The GSM system uses many different codes to identify operators in
different contexts; thus, this probably should be called "GSM_TADIG"
or just "TADIG". Also, we need a reference (any kind of reference is
better than none), expand the acronym, and specify how the value is
encoded.

Suggested text:

   TADIG (0):
   
   This namespace can be used to indicate operator names based on
   Transferred Account Data Interchange Group (TADIG) codes defined in
   [NNN]. TADIG codes are assigned by the TADIG Working Group within
   the GSM Association. The TADIG code consists of five uppercase
   ASCII characters.

   [NNN] GSM Association, "TADIG Naming Conventions, Version 4.1", 
   GSM Association Official Document TD.13, June 2006.

(The document is not currently on the GSMA web site, but it is
classified "Unrestricted". I talked with Jouni Korhonen about this and
he promised to find out if it could be made more easily available.)

2) Another comment about Section 5.1:

   "CDMA (1):

   The CDMA operator namespace can be used to indicate operator names
   based on the Home Network Identifier (HNI).  The HNI is the
   concatenation of the 3-digit Mobile Country Code (MCC) and 3-digit
   Mobile Network Code (MNC).  The IMSI Oversight Council (IOC) is the
   authority responsible for issuing unique Operator-Name values for
   operators of this type."

No no no... the Mobile Country Code (MCC) and Mobile Network Code
(MNC) are defined in E.212, and ITU-T is the authority for MCCs.  IMSI
Oversight Council is the national authority for assigning MNCs within
the US country codes; other countries have their own authorities.  The
E.212 numbering and MCC/MNC are not specific to CDMA; GSM, UMTS and
other systems use them as well. And the text needs to say how they're
encoded in the field (as many protocols use something weird such as
BCD for MCC/MNC).

Suggested rephrasing:

   E212 (1):
 
   The E212 namespace can be used to indicate operator names based on
   the Mobile Country Code (MCC) and Mobile Network Code (MNC) defined
   in [NNN]. The MCC/MCC values are assigned by the Telecommunications
   Standardization Bureau (TSB) within the ITU-T and designated
   administrators in different countries. The E212 value consists of
   three ASCII digits containing the MCC, followed by two or three
   ASCII digits containing the MNC.

   [NNN] ITU-T, "The international identification plan for mobile
   terminals and mobile users", ITU-T Recommendation E.212 (05/2004),
   May 2004.

3) Yet another comment about Section 5.1:

   "ITU (3):

   The ITU operator namespace can be used to indicate operator names
   based on ITU Carrier codes.  The Telecommunication Standardization
   Bureau (TSB) within the ITU-T is the authority responsible for the
   repository.  Each national regulatory authority is responsible for
   issuing unique Operator-Name values for operators of this type."

This is really badly named, because ITU is the authority for so many
different namespaces. There's no reference (M.1400). And because ICC
is unique only within a country, M.1400 uses them together with a
country code (the three-letter alphanumeric code from ISO 3166).

Suggested rephrasing:

   ICC (3):

   The ICC namespace can be used to indicate operator names based on
   ITU Carrier Codes (ICC) defined in [NNN]. ICC values are assigned
   by national regulatory authorities and are coordinated by the
   Telecommunication Standardization Bureau (TSB) within the ITU-T.
   When using the ICC namespace, the attribute consists of three
   uppercase ASCII characters containing a three-letter alphabetic
   country code as defined in [MMM], followed by one to six uppercase
   alphanumeric ASCII characters containing the ICC itself.
 
   [NNN] ITU-T, "Designations for interconnections among operators'
   networks", ITU-T Recommendation M.1400 (01/2004), 2004.
 
   [MMM] ISO, "Codes for the representation of names of countries and
   their subdivisions - Part 1: Country codes", ISO 3166-1:1997.

4) Section 5.3: "The format of the data is described in Section 3.1 of
[4] whereby the first 8 bits (i.e., the code for this DHCP option) are
not included." Hmm... shouldn't we also skip the length and "what"
fields?

5) Section 5.4: "The RFC 3825 Location Configuration Information (LCI)
format defined in Section 2 of RFC 3825 starting with bit 17 (i.e.,
the code for the DHCP option and the length field is not included.)."

RFC 3825 Section 2 numbers bits from 0, so it's really "starting with
bit 16". But "starting with the third octet (i.e. [...])" would be
less ambiguous.

6) Section 5.5 says that

   "The Basic-Policy-Rules attribute MUST be sent in an Access-Accept,
   an Access-Challenge, an Access-Request, an Access-Reject and an
   Accounting-Request message if location information is transmitted
   with this exchange.  If authorization policy rules are available to
   the RADIUS client then the Access-Request MUST carry the Basic-
   Policy-Rules attribute to to the RADIUS server."

This paragraph is very difficult to understand; I'd suggest some
rephrasing (almost the same text appears also in Section 5.6, and
equally unclear).

7) Section 5.6 says "The full ruleset SHOULD be fetched using
Transport Layer Security (TLS)."  Is this trying to say that "The 
URI SHOULD use the "https" scheme?" or something else?

8) Section 5.7: "The Value field is four octets.  Every bit of the two
octets MUST be set to 0." What about the other two of the four octets?
:)

9) Section 5.8: "The Value field is at least 8 octets in length"
Not "at least", since the total attribute length is exactly 10, 
not at least 10.

10) Section 6, the second table suggests that "Location-Info-Required"
is an attribute; isn't it an Error-Cause value?

11) Section 7: Hmm... I wonder if the AVP Flag rules are really
right. For example, is it really necessary to set the "M" bit for
Challenge-Capable? If the NAS is upgraded before the AAA server, the M
bit would cause the AAA server to reject the request (and the NAS has
to re-send the request without this AVP); but in this case, perhaps
just ignoring the AVP might be a better idea? Other attributes
are less clear; at least Operator-Name looks reasonably safe to 
ignore (suggesting that maybe the "M" bit should be in MAY column);
the location information/policies are less clear.

(Although I'm not sure if the word "clear" can really apply to any 
text about Diameter mandatory AVPs :-)

12) Section 8.3, req 1: "The same civic location information format is
used in PIDF-LO [16] and this document." It looks similar, but it's
not exactly the same format, right?

13) Section 11.1: "new values to the Operator-Namespaces will be
assigned after Expert Review by the Geopriv working group or its
designated successor." According to RFC 2434, "Expert Review" means
review by a designated expert, and that's a person (appointed by the
AD), not a working group. But maybe the intent was to say that the
designated expert should consult the Geopriv WG?  Same applies to
Section 11.2 as well.

Best regards,
Pasi

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

Delivery-date: Thu, 13 Jul 2006 21:00:04 +0000
Content-class: urn:content-classes:message
Subject: Follow up on Authorize Only issue (was RE: [Isms] ISMS session  summary)
Date: Thu, 13 Jul 2006 16:59:18 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Juergen Quittek writes...

> Finally, the WG discussed RADIUS integration of the SSH security
model.
> There seems to be different positions in the security community about
> whether or not 'authorization only' requests harmonize or
dis-harmonize
> with the Kerberos architecture.

We had a lunchtime meeting today to discuss this issue, with Jeff
Hutzelman, Bernard Aboba, Russ Housley and myself.  The problem turns
out to be more with the RADIUS architecture and the trust models than an
issue with the Kerberos architecture.  This issue was not brought up in
RADEXT on Monday, and the issues that were brought up in RADEXT on this
point seem to have been addressed.

The remaining issue, in a nutshell, with the desired Authorize Only
usage is as follows.

In RADIUS, Access-Request messages can be authenticated by two means,
the user credentials, e.g. User-Password or CHAP-Password, or
Message-Authenticator.  All of these are based on the RADIUS client and
server sharing a secret.  One major difference between the user
credentials and the Message-Authenticator is that that former provide
proof to the RADIUS server that the given user is "present" at the NAS.
The latter only provides proof to the RADIUS server that the NAS is
trusted.   

In an Access-Accept message, the NAS is trusted to have authorization
information for the user because (a) the NAS is trusted and (b) the user
is present at the NAS, so the NAS has a "need to know".  The concerns
with Authorize Only operations, that do not have a previous successful
RADIUS authentication as a prerequisite, is that when the user is not
present at the NAS, the NAS does not have a "need to know" the user's
authorization status.  Information might be leaked to a NAS about users,
that the NAS would not otherwise be entitled to have.

IN RFC 3576, the requirement for a previous RADIUS authentication is met
by requiring a server State attribute t be in the Access-Request
message, which provides that binding for Authorize Only operation.

The only form of RADIUS operation that currently provides authorization
information on a "user" without user credentials is the call check
operation.  In these cases the actual user is not identified, but rather
the user's phone number (or similar network address information).

For the SSHSM usage case, the question is whether it is an unacceptable
security risk for a trusted NAS to be able to obtain authorization
information about a user that is not actually "present" at the NAS?

--
to unsubscribe send a message 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, 13 Jul 2006 18:22:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66
Date: Thu, 13 Jul 2006 14:22:45 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Emile van Bergen" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Alan,

I am not trying to defend my draft.

But I do not think that RADEXT should be making a choice because
OpenDiameter has implmeneted a particular work.

This is NOT how we should be making decisions.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Wednesday, July 12, 2006 2:26 PM
> To: Emile van Bergen
> Cc: Bernard Aboba; [email-masked]
> Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG 
> meeting at IETF 66
> 
> Emile van Bergen <[email-masked]> wrote:
> > Agreed, however, the inner length field in the Lior proposal seems 
> > redundant, and instead of using attribute 26, vendor 0, I think its 
> > better to allocate a separate attribute
> 
>   I agree.  After seeing this discussion go around in circles 
> for a long time, I think enough is enough.
> 
>   Therefore, I'm happy to announce that FreeRADIUS now has an 
> implementation of the Extended-Attribute from 
> draft-wolff-radext-ext-attribute-00.txt.  For code, see the 
> CVS instructions on www.freeradius.org/development.html
> 
>   We'll reference the "Diameter-Encoded RADIUS Attributes" as 
> DERA's, to distinguish them from RADIUS or proper Diameter AVP's.
> 
>   * Extended-Attribute is attribute 192, because it's in the
>     "Experimental" space from RFC 2865.  Changing this to an IANA
>     allocated number will mean editing 2 lines of text.
>   * The implementation can handle both the Extended-Attribute and
>     Ascend's pseudo-VSA at attribute 192, simultaneously in 
> one packet.
>   * Data types supported include integer, date, IP address, IFID, IPv6
>     address, IPv6 prefix, text and string (limited to 240 bytes or so)
>   * Diameter-style VSA's via the "V" bit are fully supported, and are
>     in a separate attribute space from RADIUS VSA's
>   * no tag, encryption, or grouping is currently supported
>   * no Diameter AVP flags other than "V" are supported
>    (i.e. they're forbidden)
>   * Each DERA must be in it's own Extended-Attribute
>     (i.e. no concatenation, as of yet)
>   * DERA attributes of less than 256 are forbidden, as they should be
>     encoded as RADIUS attributes
>   * DERA attributes of 256..32767 are forbidden, as they have meaning
>     within Diameter, and RADIUS servers cannot properly deal with them
>   * DERA's are arbitrarily assigned the attribute space 32768..65535.
>   * Outside of the RADIUS marshalling/unmarshalling code, nothing else
>     in the server is aware that the attributes are encoded in any
>     special way.
>   * The new attributes are indistinguishable (other than by name) 
>     from existing RADIUS attributes to existing deployments
>   * the RADIUS client included with FreeRADIUS has full support for
>     DERA's in all RADIUS packets, with no code changes to the client.
>   * less than 400 lines of code, limited to a packet handling library
>   * can be easily extended to support multiple Diameter-style AVP's
>     in one or more Extended-Attribute.
>   * with a little more work, can be extended to support text/string
>     DERA's with more than 240 bytes of data.
> 
>   The initial implementation exists.  Let's see if we can 
> have multiple inter-operable implementations.
> 
>   "Rough consensus and running code" has not been making progress.
> Let's try "running code and rough consensus".
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Thu, 13 Jul 2006 16:06:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Consensus Call:  "Sense of the Room" at RADEXT WG meeting at IETF 66
Date: Thu, 13 Jul 2006 12:06:40 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I support this consensus. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, July 10, 2006 5:45 PM
> To: [email-masked]
> Subject: Consensus Call: "Sense of the Room" at RADEXT WG 
> meeting at IETF 66
> 
> At the RADEXT WG meeting at IETF 66, we took a "sense of the 
> room" with respect to what the WG should do with respect to 
> the exhaustion of the 
> RADIUS standard attribute space.   A  consensus appeared to 
> emerge.  We 
> would now like to confirm that consensus on the RADEXT WG 
> mailing list.
> 
> In your reply to this message, please state whether you 
> support the consensus described below, or whether you 
> disagree with it (and if so, how).
> 
> The "sense of the room" in the RADEXT WG meeting at IETF 66 was that:
> 
> * Exhaustion of the RADIUS standard attribute space is a 
> problem that should be solved.
> * RADEXT WG is the place to solve the problem.
> * The attribute exhaustion problem should be the focus -- not 
> adding other capabilities to RADIUS (such as support for the 
> Diameter data types).
> 
> In reviewing the potential solutions to the problem, the 
> people present at the meeting appeared to strongly favor a 
> RADIUS extension approach such as that outlined by Lior & Li 
> (RADIUS attribute extension), over the current proposals for 
> adding Diameter AVP support to RADIUS (Wolff & Weber and 
> Mitton proposals).  Some of the reasoning behind this was 
> that adding support for Diameter AVP parsing and dictionary 
> support would involve a substantial portion of the effort to 
> develop a Diameter server, whereas simply adding support for 
> an extended space vwould involve less effort, and would 
> therefore be more likely to be deployed.
> 
> This consensus, if it is confirmed on the mailing list, has 
> implications for the Design Guidelines document.  If the 
> RADIUS attribute space is extended without changing the 
> RADIUS protocol in other ways, then Design Guidelines 
> document needs only to focus on guidelines for the RADIUS 
> protocol.  Thus, the Design Guidelines effort is considerably 
> simplified.
> 
> 
> 
> --
> to unsubscribe send 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, 13 Jul 2006 15:18:46 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, radext chair <[email-masked]>
Subject: Protocol Action: 'RADIUS Attributes for Virtual LAN and  Priority Support' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Thu, 13 Jul 2006 11:18:17 -0400

The IESG has approved the following document:

- 'RADIUS Attributes for Virtual LAN and Priority Support '
   <draft-ietf-radext-vlan-06.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 This document describes Virtual LAN (VLAN) and re-prioritization
 attributes that may prove useful for provisioning of access to IEEE
 802 local area networks with the Remote Authentication Dialin User
 Service (RADIUS).   The attributes defined in this document provide
 support within RADIUS analogous to the management variables supported
 in IEEE-802.1Q and MIB objects defined in RFC 4363.

Working Group Summary
 
 There have been 3 WGLCs on the document, the initial one was
 part of the IEEE 802 attributes document, and the last two as
 a standalone document.  Discussion on the document related
 to the use of the Tag Indication field, details of the
 User-Priority-Table attribute and per-user vs. per-port
 provisioning.
 
Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

--
to unsubscribe send a message 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, 13 Jul 2006 12:51:32 +0000
Content-class: urn:content-classes:message
Subject: RE: paradox
Date: Thu, 13 Jul 2006 05:51:02 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <> supposedly scribbled:

> On Tue, Jul 11, 2006 at 10:28:52AM -0700, Glen Zorn (gwz) wrote:
>> 
>>>> Just to be clear, I don't think I've claimed that there is a
>>>> document, just that there are known methods that (slightly
>>>> extended) to deal with the problem.  Off the top of my head, RFC
>>>> 2868 specifies an (admittedly unsophisticated) method to group
>>>> related attributes together using "tags".  Although that document
>>>> only uses tags to group attributes of different types, I don't see
>>>> why a similar technique would not work with attributes of the same
>>>> type with the addition of the rule that all instances of the same
>>>> attribute with the same tag be concatenated in order.  A problem
>>>> would arise if you wanted to group long attributes with others but
>>>> I didn't think that we were talking about that...
>>> 
>>> Well yes, I suppose that would work, for long attributes restricted
>>> to ASCII printable strings.
>> 
>> Actually, I'm not sure why that restriction is necessary?
> 
> You need to know whether the first byte is a tag or not.  

I see.  I was actually thinking that we might add an real tag field to the attribute instead of stealing a byte from the payload.  This couldn't be done in RFC 2868 (on the grounds that it would be an "extension" to RADIUS & extensions were prohibited.  OTOH, this is the RADIUS Extensions WG, so maybe it would be possible now.  Perhaps we could even put in _two_ 1 octet fields to eliminate the problem with XL attributes not being allowed as members of other groups (though splitting the single octet into a couple of bit-fields would probably suffice).

> I suppose
> one could instead require that any attribute of length 253 always
> have a tag.  But in that case the actual tag is irrelevant.  

??

> So
> here's an alternative proposal for overcoming the 253 byte limit:   
> 
> If value length <253, entire value in one AVP.
> If value length >=253, first 252 bytes in first AVP, suffixed with
> ignored byte.  Repeat until the entire value has been consumed. 
> In other words, a length field of 255 becomes special, indicating
> both that the last byte of the value is to be ignored and that the
> next instance of the same attribute type is a continuation.  There is
> a backwards compatibility risk, that an old sender will generate an
> AVP with length field 255 for a 253-byte value.    
> 
> --
> Barney Wolff         I never met a computer I didn't like.

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, 12 Jul 2006 19:50:44 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-02.txt 
Date: Wed, 12 Jul 2006 15:50:02 -0400

--NextPart

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

	Title		: RADIUS Delegated-IPv6-Prefix Attribute
	Author(s)	: J. Salowey, R. Droms
	Filename	: draft-ietf-radext-delegated-prefix-02.txt
	Pages		: 7
	Date		: 2006-7-12
	
This document defines a RADIUS (Remote Authentication Dial In User
Service) attribute that carries an IPv6 prefix that is to be
delegated to the user.  This attribute is usable within either RADIUS
or Diameter.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-delegated-prefix-02.txt

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

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

--OtherAccess--

--NextPart--

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

Envelope-to: [email-masked]
Delivery-date: Wed, 12 Jul 2006 18:36:28 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 
cc: Bernard Aboba <[email-masked]>, [email-masked]
Date: Wed, 12 Jul 2006 14:26:21 -0400
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> Agreed, however, the inner length field in the Lior proposal seems
> redundant, and instead of using attribute 26, vendor 0, I think its
> better to allocate a separate attribute

  I agree.  After seeing this discussion go around in circles for a
long time, I think enough is enough.

  Therefore, I'm happy to announce that FreeRADIUS now has an
implementation of the Extended-Attribute from
draft-wolff-radext-ext-attribute-00.txt.  For code, see the CVS
instructions on www.freeradius.org/development.html

  We'll reference the "Diameter-Encoded RADIUS Attributes" as DERA's,
to distinguish them from RADIUS or proper Diameter AVP's.

  * Extended-Attribute is attribute 192, because it's in the
    "Experimental" space from RFC 2865.  Changing this to an IANA
    allocated number will mean editing 2 lines of text.
  * The implementation can handle both the Extended-Attribute and
    Ascend's pseudo-VSA at attribute 192, simultaneously in one packet.
  * Data types supported include integer, date, IP address, IFID, IPv6
    address, IPv6 prefix, text and string (limited to 240 bytes or so)
  * Diameter-style VSA's via the "V" bit are fully supported, and are
    in a separate attribute space from RADIUS VSA's
  * no tag, encryption, or grouping is currently supported
  * no Diameter AVP flags other than "V" are supported
   (i.e. they're forbidden)
  * Each DERA must be in it's own Extended-Attribute
    (i.e. no concatenation, as of yet)
  * DERA attributes of less than 256 are forbidden, as they should be
    encoded as RADIUS attributes
  * DERA attributes of 256..32767 are forbidden, as they have meaning
    within Diameter, and RADIUS servers cannot properly deal with them
  * DERA's are arbitrarily assigned the attribute space 32768..65535.
  * Outside of the RADIUS marshalling/unmarshalling code, nothing else
    in the server is aware that the attributes are encoded in any
    special way.
  * The new attributes are indistinguishable (other than by name) 
    from existing RADIUS attributes to existing deployments
  * the RADIUS client included with FreeRADIUS has full support for
    DERA's in all RADIUS packets, with no code changes to the client.
  * less than 400 lines of code, limited to a packet handling library
  * can be easily extended to support multiple Diameter-style AVP's
    in one or more Extended-Attribute.
  * with a little more work, can be extended to support text/string
    DERA's with more than 240 bytes of data.

  The initial implementation exists.  Let's see if we can have
multiple inter-operable implementations.

  "Rough consensus and running code" has not been making progress.
Let's try "running code and rough consensus".

  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, 12 Jul 2006 13:01:14 +0000
content-class: urn:content-classes:message
Subject: Is there interest in Radius MIB notifications?
Date: Wed, 12 Jul 2006 07:54:57 -0500
From: "Carl Kalbfleisch" <[email-masked]>
To: <[email-masked]>

Hi,

Our customers desire SNMP Notifications when the "state" of the radius server that the client is using changes. IE, when timeouts occur send a notification and then when responses are received again send another notification. 

Is there general interest/demand for this?

Essentially I am planning an enterprise extension to the Radius Authentication and Accounting Client MIBs which are defined in draft-ietf-radext-rfc2618bis-04.txt  and draft-ietf-radext-rfc2620bis-04.txt

Carl

--
to unsubscribe send a message 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, 11 Jul 2006 21:34:17 +0000
Date: Tue, 11 Jul 2006 23:34:06 +0200
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66
Mail-Followup-To: Alan DeKok <[email-masked]>, [email-masked]

Hi,

On Mon, Jul 10, 2006 at 06:10:12PM -0400, Alan DeKok wrote:

>   I support extending the RADIUS attribute space.
> 
>   I also think that the *format* (i.e. encoding) of the extended
> attribute space is a separate issue to extending RADIUS with Diameter
> features.  i.e. TTLS uses the Diameter AVP format, but few to none of
> the features.  A few hundred lines of code are sufficient to implement
> Diameter AVP encoding, which mitigates concerns over parsing &
> dictionary support.
> 
>   To put it another way, we should standardize on the extended format
> first, and explicitely reject any attempt to mingle the work on
> extended attribute space with additional work like grouping and new
> data types.  Once we have a larger attribute space standardized, later
> documents can add features for those applications that need them.

Hear, hear. 

I very much like such a layered approach. 

Incidentally, my earlier suggestion for the extended header format [1]
doesn't necessarily concern itself with data types or grouping; other
than extending the 1 octet attribute type to a 32 bit space/vendor field
and 32 bit type field, it just reserved two byte fields for a tag and
child tag in its header. That's it, it doesn't care about the type or
syntax of the value field at all. That's entirely attribute dependent.

The tag field is there to create compatibility with RFC 2868 sensible
way; the combination of tag and child tag also allows you to put
grouping/nesting on top of any attribute, whenever desireable, by
allowing any tagged or non-tagged attribute to refer to any tagged set
as its children. So the nested tree structure containing A/V pairs is
separate from the contents of the value fields.

A nice effect of creating the grouping tree using two columns is that
you can represent the tree using a flat table, which makes conversion
from and to databases and log files both trivial and lossless. You don't
have to think long and hard about the external representations of
requests or replies containing physically grouped types as is the case
with DIAMETER.

At any rate, no proposed format contains an attribute header field
referring to a data type ID (which is a very good thing, IMHO), so the
data type remains wholly attribute dependent, thus that issue is also on
a layer above the extended format itself.

Cheers,

Emile.

[1] http://www.xs4all.nl/~evbergen/ietf/draft-evbergen-radext-extended-attribute-02.txt

    Note that it should be rewritten; it contains too many ideas and
    solutions in too few sections, but I didn't take the draft further
    so far due to lack of time and apparent lack of interest from the
    group.

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

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

Delivery-date: Tue, 11 Jul 2006 21:20:23 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: WGLC on Geopriv-Radius draft
Date: Tue, 11 Jul 2006 14:20:01 -0700

The GEOPRIV WG is now about to start a WG last call on the GEOPRIV-RADIUS 
draft before sending it on to the IESG for consideration as a Proposed 
Standard:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-07.txt

In order to get all the WG last call comments together relating to all 
aspects (GEOPRIV + RADIUS) at the same time, we are requesting that the 
RADEXT WG review the document.

Please send your comments to [email-masked] as well as 
[email-masked] by  July 28, 2006.

>------- Forwarded Message
>
>Date:    Tue, 11 Jul 2006 11:00:51 -0700
>From:    Allison Mankin <[email-masked]>
>To:      [email-masked]
>cc:      [email-masked]
>Subject: WGLC for Geopriv-Radius draft
>
>Folks,
>
>draft-ietf-geopriv-radius-lo-07.txt completed its significant review
>for RADIUS considerations in the 06->07 revisions.  As we mentioned in
>today's meeting, we will now begin WGLC.  We'll extend it to three weeks
>ending Tuesday, August 1.
>
>Allison for the Chairs
>
>------- End of Forwarded Message

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

Delivery-date: Tue, 11 Jul 2006 19:02:22 +0000
Date: Tue, 11 Jul 2006 15:02:17 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: paradox

On Tue, Jul 11, 2006 at 10:28:52AM -0700, Glen Zorn (gwz) wrote:
> 
> >> Just to be clear, I don't think I've claimed that there is a
> >> document, just that there are known methods that (slightly extended)
> >> to deal with the problem.  Off the top of my head, RFC 2868
> >> specifies an (admittedly unsophisticated) method to group related
> >> attributes together using "tags".  Although that document only uses
> >> tags to group attributes of different types, I don't see why a
> >> similar technique would not work with attributes of the same type
> >> with the addition of the rule that all instances of the same
> >> attribute with the same tag be concatenated in order.  A problem
> >> would arise if you wanted to group long attributes with others but I
> >> didn't think that we were talking about that...          
> > 
> > Well yes, I suppose that would work, for long attributes restricted
> > to ASCII printable strings.  
> 
> Actually, I'm not sure why that restriction is necessary?

You need to know whether the first byte is a tag or not.  I suppose
one could instead require that any attribute of length 253 always
have a tag.  But in that case the actual tag is irrelevant.  So here's
an alternative proposal for overcoming the 253 byte limit:

If value length <253, entire value in one AVP.
If value length >%3, first 252 bytes in first AVP, suffixed with ignored
byte.  Repeat until the entire value has been consumed.
In other words, a length field of 255 becomes special, indicating both
that the last byte of the value is to be ignored and that the next instance
of the same attribute type is a continuation.  There is a backwards
compatibility risk, that an old sender will generate an AVP with length
field 255 for a 253-byte value.

-- 
Barney Wolff         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, 11 Jul 2006 18:59:35 +0000
Date: Tue, 11 Jul 2006 20:59:25 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Consensus Call:  "Sense of the Room" at RADEXT WG meeting at IETF 66
Mail-Followup-To: Bernard Aboba <[email-masked]>, [email-masked]

Hi,

On Mon, Jul 10, 2006 at 02:45:06PM -0700, Bernard Aboba wrote:

> In your reply to this message, please state whether you support the 
> consensus described below, or whether you disagree with it (and if so, how).
> 
> The "sense of the room" in the RADEXT WG meeting at IETF 66 was that:
> 
> * Exhaustion of the RADIUS standard attribute space is a problem that 
> should be solved.

Agreed.

> * RADEXT WG is the place to solve the problem.

Agreed.

> * The attribute exhaustion problem should be the focus -- not adding other 
> capabilities to RADIUS (such as support for the Diameter data types).

Agreed, though my position is that the issue of data types exists on a
layer above the issue of separating and structuring A/V pairs. Further,
I think that we should include RFC2868-style tags in the "existing
capabilities of RADIUS".

> In reviewing the potential solutions to the problem, the people present at 
> the meeting appeared to strongly favor a RADIUS extension approach such as 
> that outlined by Lior & Li (RADIUS attribute extension), over the current 
> proposals for adding Diameter AVP support to RADIUS (Wolff & Weber and 
> Mitton proposals).  

Agreed, however, the inner length field in the Lior proposal seems
redundant, and instead of using attribute 26, vendor 0, I think its
better to allocate a separate attribute, because I don't think the IETF
should create VSAs that don't follow the inner VSA format strongly
suggested in RFC 2865. Otherwise it's OK, but see also my previous mail
to this list (in the 'paradox' thread).

Cheers,

Emile.

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

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

Delivery-date: Tue, 11 Jul 2006 18:42:24 +0000
Date: Tue, 11 Jul 2006 20:41:55 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: "Glen Zorn (gwz)" <[email-masked]>, Barney Wolff <[email-masked]>
Subject: Re: paradox
Mail-Followup-To: [email-masked], "Glen Zorn (gwz)" <[email-masked]>, Barney Wolff <[email-masked]>

Hi,

On Mon, Jul 10, 2006 at 06:56:37PM -0400, Barney Wolff wrote:

> On Mon, Jul 10, 2006 at 01:31:11PM -0700, Glen Zorn (gwz) wrote:
> > Barney Wolff <> supposedly scribbled:
> > 
> > > I find it mildly astonishing, listening to today's radext session,
> > > that the group seemed to feel that the only problem worth fixing is
> > > the 255 limit on AVP type, when just a few minutes before the debate
> > > was over what to do with filter/traffic rules that go over the
> > > 253-byte limit.    
> > > 
> > > Apperently people feel that it's preferable to debate this issue
> > > every time it comes up, rather than solve it once. 
> > 
> > If you alleviate the attribute namespace shortage, aren't there established ways of dealing w/overly long values (up to the message size limit anyway)?
> 
> I'm always willing to be educated - please point me to a document that
> solves the attribute length problem when there can be more than one
> of the attribute in the message.

Ok, ok, kids. It's not /that/ hard to come up with something proper, or
is it? Is bickering all we can do nowadays? 

The issues can really be fixed in a simple and elegant way. We don't
need to make it seem any harder than it is.

I'll do it powerpoint-style:

1. the only sensible way of overcoming the 253-byte limit is
   concatenating all instances into one string. Of course, that means only
   one instance. Let's call this basic facility CONCAT.

2. for some attributes (all the ones allowing just one instance anyway),
   the CONCAT layer above RADIUS is enough. Let's call that class of
   attributes SINGLE LONG.

3. in other cases though, you want multiple instances, because a list of
   values has a meaning different from one single value. So it's
   desireable for the long attribute to be split in parts. 
   
   How to split a string? You have a number of options, as we all know.
   You either need:

   - fixed length subparts, or
   - a delimiter that may not occur (unescaped) in the string, or
   - a length, value structure (see eg. DNS), using a sufficently wide
     length field.

   Depending on the case, any of these mechanisms may be used. They all
   work above CONCAT, which works above RADIUS. No layering violations,
   standard mechanisms, all proven in RADIUS. Let's call this DELIMITED
   LIST. There's the 'document'. That didn't hurt, did it? 

Let's go on a bit:

4. in yet other cases though, you may want to have multiple individually
   identifyable elements in that delimited string, so that you don't
   have to rely on a fixed order, and can leave elements out.

   And how to do that? Well, you simply add a type (AVP code) field to
   the length, value structure given under 3. above. If you make that
   field sufficiently wide, you also solve the attribute number space
   crunch, and can delegate parts of it using smart prefixing (we all
   know about IPv4 classes, don't we?).

   Of course, that the only thing the extended attribute header format
   is: a TLV structure for use inside the single long string attribute.
   There are two contenters for this header format: the DIAMETER format,
   and a RADIUS-like format suggested earlier by yours truly that is
   fully backwards compatible with existing RADIUS features, including
   tags, and allows parts of the space to be delegated, and which, just
   like Barney's proposal incidentally, hardly got any comment about its
   technical merit or substance, as opposed to the amount of abstract
   philosophy, politics and instinctive feelings voiced around IETF-65.

   Anyway, let's call this layer, whichever way it's done, EXTATTR.

5. depending on the type of EXTATTR TLV structure chosen, EXTATTR.
   supports nested trees of attributes using physical parser level
   nesting or an inode-like structure using tags, which also provides
   the functionality of the current DIRTYTAGS we have in RFC 2868 et al.
   (Dirty only because of the the way the first octet of these
   attributes is both a flag, tag and a value in RFC2868). So, above
   EXTRAD you either directly have TREE, or you have TAGSET in between.

It can be summarised in a simple picture:

                                   +-------+
                                   |  ...  |
+-------+                          +-------+----+
|  ...  |                          | TREE  | .. |
+-------+-------+------------------+-------+----+----+
|  EAP  |  ...  |       ... *)     |  [TAGSET]  | .. |
+-------+-------+------------------+------------+----+------+-----+
|  SINGLE LONG  |  DELIMITED LIST  |    EXTATTR      | 2868 | ... |
+---------------+------------------+-----------------+------+-----+-----+
|                      CONCAT                        | DIRTYTAGS  | ... |
+----------------------------------------------------+------------+-----+
|                   Standard RADIUS attribute encoding                  |
+-----------------------------------------------------------------------+

  *) Eg. NAS-Filter

There are no dirty layering violations, implementations can pick and
choose how far they want to go with the newfangled bits, and you don't
have to rewrite any of your lower layers if you later decide you want to
add some or more of the new stuff.

It took me 15 minutes to come up with the above, and another 45 to put
it down. It should not take any more time from any of you.

So, what about it. Can we still /solve/ anything technical here, or has
this just become another slashdot?

Cheers,

Emile.

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

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

Envelope-to: [email-masked]
Delivery-date: Tue, 11 Jul 2006 18:12:05 +0000
To: [email-masked]
Subject: FW: WGLC for Geopriv-Radius draft
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Tue, 11 Jul 2006 11:11:49 -0700
From: Allison Mankin <[email-masked]>
Message-Id: <[email-masked]>

Hi, I think Bernard has left us with a few revs for the final
final draft, but we've asked GEOPRIV to do its WGLC now.

Thanks very much to radiusext for the many reviews and
improvements.

Please post reviews to GEOPRIV for the WGLC if you do
have more!?  [email-masked]

Allison

------- Forwarded Message

Date:    Tue, 11 Jul 2006 11:00:51 -0700
From:    Allison Mankin <[email-masked]>
To:      [email-masked]
cc:      [email-masked]
Subject: WGLC for Geopriv-Radius draft

Folks,

draft-ietf-geopriv-radius-lo-07.txt completed its significant review 
for RADIUS considerations in the 06->07 revisions.  As we mentioned in
today's meeting, we will now begin WGLC.  We'll extend it to three weeks
ending Tuesday, August 1.  

Allison for the Chairs

------- End of Forwarded Message

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

Delivery-date: Tue, 11 Jul 2006 17:29:01 +0000
Content-class: urn:content-classes:message
Subject: RE: paradox
Date: Tue, 11 Jul 2006 10:28:52 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <mailto:[email-masked]> supposedly scribbled:

...

>> Just to be clear, I don't think I've claimed that there is a
>> document, just that there are known methods that (slightly extended)
>> to deal with the problem.  Off the top of my head, RFC 2868
>> specifies an (admittedly unsophisticated) method to group related
>> attributes together using "tags".  Although that document only uses
>> tags to group attributes of different types, I don't see why a
>> similar technique would not work with attributes of the same type
>> with the addition of the rule that all instances of the same
>> attribute with the same tag be concatenated in order.  A problem
>> would arise if you wanted to group long attributes with others but I
>> didn't think that we were talking about that...          
> 
> Well yes, I suppose that would work, for long attributes restricted
> to ASCII printable strings.  

Actually, I'm not sure why that restriction is necessary?

> Anybody favor using this technique for
> filter/traffic rules?  

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, 11 Jul 2006 17:21:58 +0000
Date: Tue, 11 Jul 2006 13:20:25 -0400
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Consensus Call:  "Sense of the Room" at RADEXT WG meeting at IETF 66
From: Yoshihiro Ohba <[email-masked]>

I support the emerging consensus on the all three items below.  
I also support Avi's expired draft to address the last issue.

In addition, if adding other capability is needed, I'd suggest adding
such capabilities inside RADIUS attributes, not RADIUS protocol
itself.  If such "attribute-level remedy" is considered to be
impossible or unreasonably difficult to add some capability, it is
really time to think about using Diameter for that capability, instead
of trying to do cosmetic or whatever surgery to the RADIUS protocol
itself.

Best regards,
Yoshihiro Ohba

On Mon, Jul 10, 2006 at 02:45:06PM -0700, Bernard Aboba wrote:
> At the RADEXT WG meeting at IETF 66, we took a "sense of the room" with 
> respect to what the WG should do with respect to the exhaustion of the 
> RADIUS standard attribute space.   A  consensus appeared to emerge.  We 
> would now like to confirm that consensus on the RADEXT WG mailing list.
> 
> In your reply to this message, please state whether you support the 
> consensus described below, or whether you disagree with it (and if so, how).
> 
> The "sense of the room" in the RADEXT WG meeting at IETF 66 was that:
> 
> * Exhaustion of the RADIUS standard attribute space is a problem that 
> should be solved.
> * RADEXT WG is the place to solve the problem.
> * The attribute exhaustion problem should be the focus -- not adding other 
> capabilities to RADIUS (such as support for the Diameter data types).
> 
> In reviewing the potential solutions to the problem, the people present at 
> the meeting appeared to strongly favor a RADIUS extension approach such as 
> that outlined by Lior & Li (RADIUS attribute extension), over the current 
> proposals for adding Diameter AVP support to RADIUS (Wolff & Weber and 
> Mitton proposals).  Some of the reasoning behind this was that adding 
> support for Diameter AVP parsing and dictionary support would involve a 
> substantial portion of the effort to develop a Diameter server, whereas 
> simply adding support for an extended space vwould involve less effort, and 
> would therefore be more likely to be deployed.
> 
> This consensus, if it is confirmed on the mailing list, has implications 
> for the Design Guidelines document.  If the RADIUS attribute space is 
> extended without changing the RADIUS protocol in other ways, then Design 
> Guidelines document needs only to focus on guidelines for the RADIUS 
> protocol.  Thus, the Design Guidelines effort is considerably simplified.
> 
> 
> 
> --
> to unsubscribe send 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, 11 Jul 2006 17:07:54 +0000
Date: Tue, 11 Jul 2006 13:07:41 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: paradox

On Tue, Jul 11, 2006 at 09:38:17AM -0700, Glen Zorn (gwz) wrote:
> > 
> > I'm always willing to be educated - please point me to a document
> > that solves the attribute length problem when there can be more than
> > one of the attribute in the message. 
> 
> Just to be clear, I don't think I've claimed that there is a document, just that there are known methods that (slightly extended) to deal with the problem.  Off the top of my head, RFC 2868 specifies an (admittedly unsophisticated) method to group related attributes together using "tags".  Although that document only uses tags to group attributes of different types, I don't see why a similar technique would not work with attributes of the same type with the addition of the rule that all instances of the same attribute with the same tag be concatenated in order.  A problem would arise if you wanted to group long attributes with others but I didn't think that we were talking about that...  

Well yes, I suppose that would work, for long attributes restricted to
ASCII printable strings.  Anybody favor using this technique for
filter/traffic rules?

-- 
Barney Wolff         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, 11 Jul 2006 16:38:49 +0000
Content-class: urn:content-classes:message
Subject: RE: paradox
Date: Tue, 11 Jul 2006 09:38:17 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff <mailto:[email-masked]> supposedly scribbled:

...

>> If you alleviate the attribute namespace shortage, aren't there
>> established ways of dealing w/overly long values (up to the message
>> size limit anyway)?  
> 
> I'm always willing to be educated - please point me to a document
> that solves the attribute length problem when there can be more than
> one of the attribute in the message. 

Just to be clear, I don't think I've claimed that there is a document, just that there are known methods that (slightly extended) to deal with the problem.  Off the top of my head, RFC 2868 specifies an (admittedly unsophisticated) method to group related attributes together using "tags".  Although that document only uses tags to group attributes of different types, I don't see why a similar technique would not work with attributes of the same type with the addition of the rule that all instances of the same attribute with the same tag be concatenated in order.  A problem would arise if you wanted to group long attributes with others but I didn't think that we were talking about that...  

Hope this helps,

~gwz

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

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

Delivery-date: Mon, 10 Jul 2006 23:19:08 +0000
Content-class: urn:content-classes:message
Subject: RE: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 
Date: Mon, 10 Jul 2006 16:18:58 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

> "Congdon, Paul T (ProCurve)" <[email-masked]> wrote:
> > I support this consensus position.  In particular I support the 
> > simplified approach proposed by Lior.
> 
>   For those of us not in the room, what was that?
> 

The approached referenced in Bernard's email. I assume this is the
expired draft:

draft-lior-radius-attribute-type-extension-00

View Related Documents (e.g., documents that replaced or were replaced
by the subject I-D, and their derivatives and precursors.) 
I-D Title: Remote Authentication Dial In User Service (RADIUS) Attribute
Type Extension 
I-D Status: Expired 
I-D Intended Status at Publication: None 
RFC Number: 
I-D Tracker State: ID Exists 
Abstract: 
In order for Remote Authentication Dial In User Service (RADIUS)
protocol to continue to support new applications it is required that the
RADIUS attribute space be extended beyond the current limit of 255
possible attribute types. This document defines a mechanism to extend
the base RADIUS attribute types while maintaining backwards
compatibility as well as compatibility with Diameter.  

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

Delivery-date: Mon, 10 Jul 2006 23:17:18 +0000
From: Steigerwaldw <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: Consensus Call:  "Sense of the Room" at RADEXT WG meeting at  IETF 66
Date: Tue, 11 Jul 2006 01:17:00 +0200

> * Exhaustion of the RADIUS standard attribute space is a 
> problem that should be solved.
I think we should NOT spend so much effort on radius and should spent it to diameter (dime)

> * RADEXT WG is the place to solve the problem.
If consensus for the previous question is yes, radext is the right place.

> * The attribute exhaustion problem should be the focus -- not 
> adding other capabilities to RADIUS (such as support for the 
> Diameter data types).
If consensus can be found for the work, I support Lior's proposal.

Regards Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: Bernard Aboba [mailto:[email-masked]] 
> Gesendet: Montag, 10. Juli 2006 23:45
> An: [email-masked]
> Betreff: Consensus Call: "Sense of the Room" at RADEXT WG 
> meeting at IETF 66
> 
> At the RADEXT WG meeting at IETF 66, we took a "sense of the 
> room" with respect to what the WG should do with respect to 
> the exhaustion of the 
> RADIUS standard attribute space.   A  consensus appeared to 
> emerge.  We 
> would now like to confirm that consensus on the RADEXT WG 
> mailing list.
> 

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

Envelope-to: [email-masked]
Delivery-date: Mon, 10 Jul 2006 23:07:53 +0000
From: "Alan DeKok" <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 
cc: [email-masked]
Date: Mon, 10 Jul 2006 18:58:31 -0400
Message-Id: <[email-masked]>

"Congdon, Paul T (ProCurve)" <[email-masked]> wrote:
> I support this consensus position.  In particular I support the
> simplified approach proposed by Lior.

  For those of us not in the room, what was that?

  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, 10 Jul 2006 22:57:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Consensus Call:  "Sense of the Room" at RADEXT WG meeting at IETF 66
Date: Mon, 10 Jul 2006 15:57:42 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

> 
> In your reply to this message, please state whether you 
> support the consensus described below, or whether you 
> disagree with it (and if so, how).
>

I support this consensus position.  In particular I support the
simplified approach proposed by Lior.  

Paul

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

Delivery-date: Mon, 10 Jul 2006 22:57:02 +0000
Date: Mon, 10 Jul 2006 18:56:37 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: Re: paradox

On Mon, Jul 10, 2006 at 01:31:11PM -0700, Glen Zorn (gwz) wrote:
> Barney Wolff <> supposedly scribbled:
> 
> > I find it mildly astonishing, listening to today's radext session,
> > that the group seemed to feel that the only problem worth fixing is
> > the 255 limit on AVP type, when just a few minutes before the debate
> > was over what to do with filter/traffic rules that go over the
> > 253-byte limit.    
> > 
> > Apperently people feel that it's preferable to debate this issue
> > every time it comes up, rather than solve it once. 
> 
> If you alleviate the attribute namespace shortage, aren't there established ways of dealing w/overly long values (up to the message size limit anyway)?

I'm always willing to be educated - please point me to a document that
solves the attribute length problem when there can be more than one
of the attribute in the message.

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

Envelope-to: [email-masked]
Delivery-date: Mon, 10 Jul 2006 22:19:40 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 
Date: Mon, 10 Jul 2006 18:10:12 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> The "sense of the room" in the RADEXT WG meeting at IETF 66 was that:
> 
> * Exhaustion of the RADIUS standard attribute space is a problem that should 
> be solved.
> * RADEXT WG is the place to solve the problem.
> * The attribute exhaustion problem should be the focus -- not adding other 
> capabilities to RADIUS (such as support for the Diameter data types).

  I agree to all three points.

> In reviewing the potential solutions to the problem, the people present at 
> the meeting appeared to strongly favor a RADIUS extension approach such as 
> that outlined by Lior & Li (RADIUS attribute extension), over the current 
> proposals for adding Diameter AVP support to RADIUS (Wolff & Weber and 
> Mitton proposals).  Some of the reasoning behind this was that adding 
> support for Diameter AVP parsing and dictionary support would involve a 
> substantial portion of the effort to develop a Diameter server, whereas 
> simply adding support for an extended space vwould involve less effort, and 
> would therefore be more likely to be deployed.

  I support extending the RADIUS attribute space.

  I also think that the *format* (i.e. encoding) of the extended
attribute space is a separate issue to extending RADIUS with Diameter
features.  i.e. TTLS uses the Diameter AVP format, but few to none of
the features.  A few hundred lines of code are sufficient to implement
Diameter AVP encoding, which mitigates concerns over parsing &
dictionary support.

  To put it another way, we should standardize on the extended format
first, and explicitely reject any attempt to mingle the work on
extended attribute space with additional work like grouping and new
data types.  Once we have a larger attribute space standardized, later
documents can add features for those applications that need them.

  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, 10 Jul 2006 21:46:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Consensus Call:  "Sense of the Room" at RADEXT WG meeting at IETF 66
Date: Mon, 10 Jul 2006 14:45:06 -0700

At the RADEXT WG meeting at IETF 66, we took a "sense of the room" with 
respect to what the WG should do with respect to the exhaustion of the 
RADIUS standard attribute space.   A  consensus appeared to emerge.  We 
would now like to confirm that consensus on the RADEXT WG mailing list.

In your reply to this message, please state whether you support the 
consensus described below, or whether you disagree with it (and if so, how).

The "sense of the room" in the RADEXT WG meeting at IETF 66 was that:

* Exhaustion of the RADIUS standard attribute space is a problem that should 
be solved.
* RADEXT WG is the place to solve the problem.
* The attribute exhaustion problem should be the focus -- not adding other 
capabilities to RADIUS (such as support for the Diameter data types).

In reviewing the potential solutions to the problem, the people present at 
the meeting appeared to strongly favor a RADIUS extension approach such as 
that outlined by Lior & Li (RADIUS attribute extension), over the current 
proposals for adding Diameter AVP support to RADIUS (Wolff & Weber and 
Mitton proposals).  Some of the reasoning behind this was that adding 
support for Diameter AVP parsing and dictionary support would involve a 
substantial portion of the effort to develop a Diameter server, whereas 
simply adding support for an extended space vwould involve less effort, and 
would therefore be more likely to be deployed.

This consensus, if it is confirmed on the mailing list, has implications for 
the Design Guidelines document.  If the RADIUS attribute space is extended 
without changing the RADIUS protocol in other ways, then Design Guidelines 
document needs only to focus on guidelines for the RADIUS protocol.  Thus, 
the Design Guidelines effort is considerably simplified.

--
to unsubscribe send a message 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, 10 Jul 2006 20:31:34 +0000
Content-class: urn:content-classes:message
Subject: RE: paradox
Date: Mon, 10 Jul 2006 13:31:11 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>, <[email-masked]>

Barney Wolff <> supposedly scribbled:

> I find it mildly astonishing, listening to today's radext session,
> that the group seemed to feel that the only problem worth fixing is
> the 255 limit on AVP type, when just a few minutes before the debate
> was over what to do with filter/traffic rules that go over the
> 253-byte limit.    
> 
> Apperently people feel that it's preferable to debate this issue
> every time it comes up, rather than solve it once. 

If you alleviate the attribute namespace shortage, aren't there established ways of dealing w/overly long values (up to the message size limit anyway)?

> 
> --
> Barney Wolff         I never met a computer I didn't like.

Hope this helps,

~gwz

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

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

Envelope-to: [email-masked]
Delivery-date: Mon, 10 Jul 2006 20:14:42 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, radext chair <[email-masked]>
Subject: Document Action: 'RADIUS Accounting Client MIB for IPv6' to  Informational RFC 
Message-Id: <[email-masked]>
Date: Mon, 10 Jul 2006 16:14:08 -0400

The IESG has approved the following documents:

- 'RADIUS Accounting Server MIB for IPv6 '
   <draft-ietf-radext-rfc2621bis-04.txt> as an Informational RFC
- 'RADIUS Accounting Client MIB for IPv6 '
   <draft-ietf-radext-rfc2620bis-04.txt> as an Informational RFC

These documents are products of the RADIUS EXTensions Working Group. 

The IESG contact persons are Dan Romascanu and David Kessens.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-04.txt

Technical Summary
 
The two documents in this set represent a portion of the Management Information
Base (MIB) for use with network management protocols in the Internet community.
The documents cover the RADIUS Accounting protocol [RFC2866] client and server
functions.  The RADIUS Accounting MIB documents are Informational.  The scope
ofthe revisions in the current set of Internet Drafts includes adding
capabilitiesto handle IPv6 address formats, adding UNITS and REFERENCE clauses
to selected
objects, and generally updating the MIB and Internet Draft boilerplate, and the
Security Considerations.  Certain objects have been deprecated and backwards
compatibility with the existing RFCs and MIBs has been maintained, as these
MIBsare widely deployed.  The four Internet Drafts in this set will obsolete
their
respective RFCs when approved.
 
Working Group Summary
 
The Working Group initially took the approach of augmenting the existing MIBs
and updating the existing RFCs.  Early MIB Doctor review indicated that the
MIBsshould be revised and the existing RFCs obsoleted.  There is no significant
technical content in these documents, but rather a straightforward revision to
support IP version neutral address formats.  Most of the discussion on these
drafts was related to MIB design guidelines and "nits".  The only MIB Doctor
comment that was not resolved was a recommendation to root the MODULE-IDENTITY
objects in these four drafts directly under mib-2 OID, but that would break
backwards compatibility with existing OID trees in widely deployed MIBs. This
solution was agreed by the MIB Doctor. 

Protocol Quality
 
The existing two MIB modules are widely deployed.   It is expected that many
vendors will implement the revised MIBs as the systems which contain RADIUS
accounting clients and servers are enhanced to support IPv6.  Several WG
membersresponded to informal polls at IETF meetings indicating their interest
inimplementing these MIBs.  The overall protocol quality of these MIBs has been
enhanced by detailed review by MIB Doctors: Dave Harrington, C.M. Heard and Dan
Romascanu.

Note to RFC Editor
 
 Please make the following change Section 4 of
draft-ietf-radext-rfc2620bis-04.txt

OLD: 

   This document obsoletes RFC 2620 [RFC2620], RADIUS Authentication
   Client MIB, by deprecating the radiusAuthServerTable table and adding
   a new table, radiusAuthServerExtTable, containing
   radiusAuthServerInetAddressType, radiusAuthServerInetAddress, and
   radiusAuthClientServerInetPortNumber.

NEW:
 
    This document obsoletes RFC 2620 [RFC2620], RADIUS Accounting
    Client MIB, by deprecating the radiusAccServerTable table and adding
    a new table, radiusAccServerExtTable, containing
    radiusAccServerInetAddressType, radiusAccServerInetAddress, and
    radiusAccClientServerInetPortNumber.

--
to unsubscribe send 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, 10 Jul 2006 19:58:22 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, radext chair <[email-masked]>
Subject: Document Action: 'Dynamic Authorization Client MIB' to  Informational RFC 
Message-Id: <[email-masked]>
Date: Mon, 10 Jul 2006 15:57:39 -0400

The IESG has approved the following documents:

- 'Dynamic Authorization Client MIB '
   <draft-ietf-radext-dynauth-client-mib-06.txt> as an Informational RFC
- 'Dynamic Authorization Server MIB '
   <draft-ietf-radext-dynauth-server-mib-06.txt> as an Informational RFC

These documents are products of the RADIUS EXTensions Working Group. 

The IESG contact persons are Dan Romascanu and David Kessens.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-06.txt

Technical Summary
 
  Dynamic Authorization Client MIB

    This memo defines a portion of the Management Information Base (MIB)
    for use with network management protocols in the Internet community.
    In particular, it describes the Remote Authentication Dial In User
    Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC)
    functions that support the dynamic authorization extensions as
    defined in RFC 3576.

  Dynamic Authorization Server MIB

    This memo defines a portion of the Management Information Base (MIB)
    for use with network management protocols in the Internet community.
    In particular, it describes the Remote Authentication Dial In User
    Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS)
    functions that support the dynamic authorization extensions as
    defined in RFC 3576.
 
Working Group Summary
 
  The WG has consensus on these documents.
 
Protocol Quality
 
  MIB Doctor review was done by Dan Romascanu.
  The documents are Informational, so no IETF Last Call was issued.
  However, there was call for comment to MIB doctors list.
  Bert Wijnen did review these documents for the IESG.

--
to unsubscribe send 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, 10 Jul 2006 19:41:12 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, radext chair <[email-masked]>
Subject: Protocol Action: 'RADIUS Authentication Client MIB for IPV6'  to Proposed Standard 
Message-Id: <[email-masked]>
Date: Mon, 10 Jul 2006 15:40:48 -0400

The IESG has approved the following documents:

- 'RADIUS Authentication Server MIB for IPv6 '
   <draft-ietf-radext-rfc2619bis-04.txt> as a Proposed Standard
- 'RADIUS Authentication Client MIB for IPV6 '
   <draft-ietf-radext-rfc2618bis-04.txt> as a Proposed Standard

These documents are products of the RADIUS EXTensions Working Group. 

The IESG contact persons are Dan Romascanu and David Kessens.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-04.txt

Technical Summary
 
The two documents in this set represent a portion of the Management Information
Base (MIB) for use with network management protocols in the Internet community.
The documents cover the RADIUS protocol [RFC2865] client and server functions.
The RADIUS MIB documents are Standards Track.  The scope of the revisions in
thecurrent set of Internet Drafts includes adding capabilities to handle IPv6
address formats, adding UNITS and REFERENCE clauses to selected objects, and
generally updating the MIB and Internet Draft boilerplate, and the Security
Considerations.  Certain objects have been deprecated and backwards
compatibility with the existing RFCs and MIBs has been maintained, as these
MIBsare widely deployed.  The two Internet Drafts in this set will obsolete
their
respective RFCs when approved.

Working Group Summary
 
The Working Group initially took the approach of augmenting the existing MIBs
and updating the existing RFCs.  Early MIB Doctor review indicated that the
MIBsshould be revised and the existing RFCs obsoleted.  There is no significant
technical content in these documents, but rather a straightforward revision to
support IP version neutral address formats.  Most of the discussion on these
drafts was related to MIB design guidelines and "nits".  The only MIB Doctor
comment that was not resolved was a recommendation to root the MODULE-IDENTITY
objects in these four drafts directly under mib-2 OID, but that would break
backwards compatibility with existing OID trees in widely deployed MIBs. This
resolution was accepted by the MIB Doctor.

Protocol Quality
 
The existing two MIB modules are widely deployed. It is expected that many
vendors will implement the revised MIBs as the systems which contain RADIUS
[accounting] clients and servers are enhanced to support IPv6.  Several WG
members responded to informal polls at IETF meetings indicating their interest
in implementing these MIBs.  The overall protocol quality of these MIBs has
beenenhanced by detailed review by MIB Doctors: Dave Harrington, C.M. Heard and
Dan
Romascanu.

Note to RFC Editor
 
 Please make the following change in the Abstract:

OLD: 

   This memo defines a set of extensions, which instrument RADIUS
   authentication client functions.  These extensions represent a
   portion of the Management Information Base (MIB) for use with network
   management protocols in the Internet community.  Using these
   extensions IP-based management stations can manage RADIUS
   authentication clients.

NEW: 

   This memo defines a set of extensions, which instrument RADIUS
   authentication client functions.  These extensions represent a
   portion of the Management Information Base (MIB) for use with network
   management protocols in the Internet community.  Using these
   extensions, IP-based management stations can manage RADIUS
   authentication clients.

--
to unsubscribe send a message 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, 10 Jul 2006 19:08:24 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Mon, 10 Jul 2006 15:04:45 -0400
From: "Avi Lior" <[email-masked]>
To: "Sanchez, Mauricio \(ProCurve\)" <[email-masked]>, <[email-masked]>, <[email-masked]>

I agree with that.  Make them the same. 

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, July 09, 2006 8:48 PM
> To: [email-masked]; Avi Lior; [email-masked]
> Subject: RE: Issue: Attribute concatenation/splitting
> 
> 
> Pasi wrote... 
> 
> > Yes, this would work for NAS-Filter-Rule -- but so would any of the 
> > other proposals so far (e.g. rules end with LF; rule ends 
> if attribute 
> > length <253; attributes begin with a tag octet; etc.) I don't think 
> > any of these proposals is a really good one, but at least the same 
> > approach could be reused for NAS-Traffic-Rule (and maybe other 
> > attributes in the future as well).
> 
> The consensus reached for NAS-Traffic-Rule, when this exact 
> issue arose, was to use a LF as a rule delimiter.  As you 
> point out it's not ideal, but is probably the most 
> straightforward option.
> 
> Why not just bite the bullet and add the same LF delimiter to 
> NAS-Filter-Rule?  At least we'd be able to claim then that 
> NAS-Traffic-Rule and NAS-Filter-Rule use common rule 
> delimiters, thereby easing a RADIUS implementers effort to 
> support both attributes.
> 
> MS
> 

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

Delivery-date: Mon, 10 Jul 2006 17:42:25 +0000
Date: Mon, 10 Jul 2006 13:42:02 -0400
From: Barney Wolff <[email-masked]>
To: [email-masked]
Subject: paradox

I find it mildly astonishing, listening to today's radext session,
that the group seemed to feel that the only problem worth fixing
is the 255 limit on AVP type, when just a few minutes before the
debate was over what to do with filter/traffic rules that go over
the 253-byte limit.

Apperently people feel that it's preferable to debate this issue
every time it comes up, rather than solve it once.

-- 
Barney Wolff         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: Mon, 10 Jul 2006 00:47:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Sun, 9 Jul 2006 17:47:48 -0700
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C6A344.16AFEE50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Pasi wrote... 

> Yes, this would work for NAS-Filter-Rule -- but so would any 
> of the other proposals so far (e.g. rules end with LF; rule 
> ends if attribute length <253; attributes begin with a tag 
> octet; etc.) I don't think any of these proposals is a really 
> good one, but at least the same approach could be reused for 
> NAS-Traffic-Rule (and maybe other attributes in the future as well).

The consensus reached for NAS-Traffic-Rule, when this exact issue arose, was
to use a LF as a rule delimiter.  As you point out it's not ideal, but is
probably the most straightforward option.

Why not just bite the bullet and add the same LF delimiter to
NAS-Filter-Rule?  At least we'd be able to claim then that NAS-Traffic-Rule
and NAS-Filter-Rule use common rule delimiters, thereby easing a RADIUS
implementers effort to support both attributes.

MS

------=_NextPart_000_0013_01C6A344.16AFEE50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0013_01C6A344.16AFEE50--

--
to unsubscribe send a message 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, 10 Jul 2006 00:39:18 +0000
Content-class: urn:content-classes:message
Subject: IETF-66: Resources for remote participants
Date: Sun, 9 Jul 2006 20:38:56 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Streaming audio:

  http://videolab.uoregon.edu/events/ietf/

Jabber:

  jabber server = jabber.ietf.org,  room = radext (in general, the WG
name)

Meeting materials (slides, etc.):

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66

RADEXT meets at 9:00 AM EDT, tomorrow (Monday, July 10).

--
to unsubscribe send a message 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, 09 Jul 2006 20:05:39 +0000
Date: Sun, 09 Jul 2006 20:17:52 +0200
From: Hannes Tschofenig <[email-masked]>
To: NSIS <[email-masked]>,  [email-masked],  [email-masked],  tsvwg <[email-masked]>
Subject: [Fwd: [Dime] Diameter QoS Dinner]

Hi all,

please do not forget the QoS dinner Sunday evening, 19:30 at the 
registration desk.

Ciao
Hannes

-------- Original Message --------
Subject: 	[Dime] Diameter QoS Dinner
Date: 	Mon, 19 Jun 2006 14:14:39 +0200
From: 	Tschofenig, Hannes <[email-masked]>
To: 	<[email-masked]>

Hi all,

it would be good to meet Diameter QoS interested folks at the next IETF
for a discussion about possible next steps before the DIME session.

The DIME WG session will be on***** MONDAY, July 10, 2006** *
*1740-1840 Afternoon Session III*
Room 519B       APP     _widex_
<http://www.ietf.org/html.charters/widex-charter.html>   Widget
Description Exchange Service WG
Room 520ABC     INT     _softwire_
<http://www.ietf.org/html.charters/softwire-charter.html>
Softwires WG
Room 519A       IRTF    NMRG    Network Management Research Group
Charter
*Room 513C-F     OPS     **_dime_*
<http://www.ietf.org/html.charters/dime-charter.html>*    Diameter
Maintenance and Extensions WG
*Room 520DEF     RAI     rtpsec  Securing the Real-time Transport
Protocol BOF
Room 513B       SEC     _sasl_
<http://www.ietf.org/html.charters/sasl-charter.html>    Simple
Authentication and Security Layer WG
Room 518AB      TSV     _tsvwg_
<http://www.ietf.org/html.charters/tsvwg-charter.html>   Transport Area
Working Group WG
_https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_numf_ 

Hence, there is only time after the Welcome Reception on Sunday. My
proposal would be to meet  at the registration desk at 19:30.

Please send me a mail if you are interested.

Ciao
Hannes

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

Envelope-to: [email-masked]
Delivery-date: Sun, 09 Jul 2006 18:30:37 +0000
Date: Sun, 9 Jul 2006 11:30:06 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4590 on RADIUS Extension for Digest Authentication
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4590

        Title:      RADIUS Extension for Digest Authentication 
        Author:     B. Sterman, D. Sadolevsky,
                    D. Schwartz, D. Williams,
                    W. Beck
        Status:     Standards Track
        Date:       July 2006
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked], [email-masked], 
                    [email-masked]
        Pages:      32
        Characters: 67181
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-radext-digest-auth-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4590.txt

This document defines an extension to the Remote Authentication
Dial-In User Service (RADIUS) protocol to enable support of Digest
Authentication, for use with HTTP-style protocols like the Session
Initiation Protocol (SIP) and HTTP.  [STANDARDS TRACK]

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

--
to unsubscribe send a message 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, 09 Jul 2006 16:08:03 +0000
Date: Sun, 9 Jul 2006 12:07:31 -0400
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting

On Sun, Jul 09, 2006 at 08:32:20AM -0400, Avi Lior wrote:
> I meant Diameter AVPs in RADIUS (If that initiative is still underway).

So did I; see draft-wolff-radext-ext-attribute-00.txt .  If we adopted
that or anything equivalent, the 253 limit would be removed, among
other benefits.

-- 
Barney Wolff         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: Sun, 09 Jul 2006 14:26:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Sun, 9 Jul 2006 17:25:29 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Avi Lior wrote:
> Are we talking about NAS-Filter-Rule?  That is what I was talking
> about.
>
> NAS-Filter-Rule is IPFilterRule which can only have permit or deny
> in the action position.
> 
> However if you are talking about the Redirection work then you are
> right.

IMHO it would be nice to use the same approach to
concatenation/splitting
for both NAS-Filter-Rule (the one copied from Diameter) and 
NAS-Traffic-Rule (the one including redirection and tunnels). 

Best regards,
Pasi

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

Delivery-date: Sun, 09 Jul 2006 12:33:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Sun, 9 Jul 2006 08:32:20 -0400
From: "Avi Lior" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

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

I meant Diameter AVPs in RADIUS (If that initiative is still underway).

-----Original Message-----
From: Barney Wolff [mailto:[email-masked]]
Sent: Sat 7/8/2006 8:42 PM
To: Avi Lior
Cc: [email-masked]; [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting
 
On Sat, Jul 08, 2006 at 12:14:11PM -0400, Avi Lior wrote:
> 
> If we want to solve fragmentation in general then inserting a value inside the attribute will not work.  I think we have to invent something in the header of the attribute.
> 
> For example, if we were to use Diameter AVP in RADIUS we would add a new flag (where the 'M' 'V' flags are) to indicate that the value of this attribute spans the next attribute.
> 
> Why don't we hold this work until we can agree on the Diameter AVP?

I certainly concur.  But using the Diameter AVP header makes the problem
go away, as Diameter AVPs are not limited to 253 bytes.

-- 
Barney Wolff         I never met a computer I didn't like.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>RE: Issue: Attribute concatenation/splitting</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>I meant Diameter AVPs in RADIUS (If that initiative is still underway).<BR>
<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Barney Wolff [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Sat 7/8/2006 8:42 PM<BR>
To: Avi Lior<BR>
Cc: [email-masked]; [email-masked]<BR>
Subject: Re: Issue: Attribute concatenation/splitting<BR>
<BR>
On Sat, Jul 08, 2006 at 12:14:11PM -0400, Avi Lior wrote:<BR>
&gt;<BR>
&gt; If we want to solve fragmentation in general then inserting a value inside the attribute will not work.&nbsp; I think we have to invent something in the header of the attribute.<BR>
&gt;<BR>
&gt; For example, if we were to use Diameter AVP in RADIUS we would add a new flag (where the 'M' 'V' flags are) to indicate that the value of this attribute spans the next attribute.<BR>
&gt;<BR>
&gt; Why don't we hold this work until we can agree on the Diameter AVP?<BR>
<BR>
I certainly concur.&nbsp; But using the Diameter AVP header makes the problem<BR>
go away, as Diameter AVPs are not limited to 253 bytes.<BR>
<BR>
--<BR>
Barney Wolff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I never met a computer I didn't like.<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6A353.D4CC05A9--

--
to unsubscribe send a message 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, 09 Jul 2006 00:42:38 +0000
Date: Sat, 8 Jul 2006 20:42:08 -0400
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting

On Sat, Jul 08, 2006 at 12:14:11PM -0400, Avi Lior wrote:
> 
> If we want to solve fragmentation in general then inserting a value inside the attribute will not work.  I think we have to invent something in the header of the attribute.
> 
> For example, if we were to use Diameter AVP in RADIUS we would add a new flag (where the 'M' 'V' flags are) to indicate that the value of this attribute spans the next attribute.
> 
> Why don't we hold this work until we can agree on the Diameter AVP?

I certainly concur.  But using the Diameter AVP header makes the problem
go away, as Diameter AVPs are not limited to 253 bytes.

-- 
Barney Wolff         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: Sat, 08 Jul 2006 21:07:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Sat, 8 Jul 2006 17:05:01 -0400
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A2D2.8E1A9CDD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Passi,

Are we talking about NAS-Filter-Rule?  That is what I was talking about.

NAS-Filter-Rule is IPFilterRule which can only have permit or deny in the action position.

However if you are talking about the Redirection work then you are right.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sat 7/8/2006 12:24 PM
To: Avi Lior; [email-masked]
Subject: RE: Issue: Attribute concatenation/splitting
 
Avi Lior wrote:
> I have to read the draft.  Is permit/deny allowed inside the
> attribute because we are allowed to include more then one rule
> inside the packet? If that is the case IMO we should not do that.
> One rule per attribute.

No, it's because there are rule elements (e.g. tunnel-id, org-url
and redir-url) that are more-or-less arbitrary strings. In other
words, you could have a tunnel called "permit" or a URL that
contains the string "deny".

Best regards,
Pasi

------_=_NextPart_001_01C6A2D2.8E1A9CDD
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>RE: Issue: Attribute concatenation/splitting</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Hi Passi,<BR>
<BR>
Are we talking about NAS-Filter-Rule?&nbsp; That is what I was talking about.<BR>
<BR>
NAS-Filter-Rule is IPFilterRule which can only have permit or deny in the action position.<BR>
<BR>
However if you are talking about the Redirection work then you are right.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Sat 7/8/2006 12:24 PM<BR>
To: Avi Lior; [email-masked]<BR>
Subject: RE: Issue: Attribute concatenation/splitting<BR>
<BR>
Avi Lior wrote:<BR>
&gt; I have to read the draft.&nbsp; Is permit/deny allowed inside the<BR>
&gt; attribute because we are allowed to include more then one rule<BR>
&gt; inside the packet? If that is the case IMO we should not do that.<BR>
&gt; One rule per attribute.<BR>
<BR>
No, it's because there are rule elements (e.g. tunnel-id, org-url<BR>
and redir-url) that are more-or-less arbitrary strings. In other<BR>
words, you could have a tunnel called &quot;permit&quot; or a URL that<BR>
contains the string &quot;deny&quot;.<BR>
<BR>
Best regards,<BR>
Pasi<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6A2D2.8E1A9CDD--

--
to unsubscribe send a message 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, 08 Jul 2006 16:25:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Sat, 8 Jul 2006 19:24:43 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Avi Lior wrote:
> I have to read the draft.  Is permit/deny allowed inside the
> attribute because we are allowed to include more then one rule
> inside the packet? If that is the case IMO we should not do that.
> One rule per attribute.

No, it's because there are rule elements (e.g. tunnel-id, org-url
and redir-url) that are more-or-less arbitrary strings. In other
words, you could have a tunnel called "permit" or a URL that
contains the string "deny".

Best regards,
Pasi

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

Delivery-date: Sat, 08 Jul 2006 16:13:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Sat, 8 Jul 2006 12:14:11 -0400
From: "Avi Lior" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A2A9.8C508B1D
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Pasi,

Understood.

Tagging should not be used.  Tagging is for grouping not for fragmentation.

If I use tagging for fragmentation then what will I use for grouping when I want to group things together?

I have to read the draft.  Is permit/deny allowed inside the attribute because we are allowed to include more then one rule inside the packet? If that is the case IMO we should not do that.  One rule per attribute.

If we want to solve fragmentation in general then inserting a value inside the attribute will not work.  I think we have to invent something in the header of the attribute.

For example, if we were to use Diameter AVP in RADIUS we would add a new flag (where the 'M' 'V' flags are) to indicate that the value of this attribute spans the next attribute.

Why don't we hold this work until we can agree on the Diameter AVP?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sat 7/8/2006 11:08 AM
To: Avi Lior; [email-masked]
Subject: RE: Issue: Attribute concatenation/splitting
 
Avi Lior wrote:

> I think we should not allow to pack more then one Filter Rule in a
> single attribute.
> 
> A Filter Rule should be allowed to overflow (span) more then one
> attribute.
> 
> If you have more then one filter rules in a packet with some filter
> rules overflowing, how can you tell when a new one begins?
> 
> A filter rule always starts with an action: permit or deny.  These
> words do not appear anywhere else in the rule.  Therefore a Filter
> Atribute that starts with a permit or deny must be a new filter
> rule.
> 
> What is wrong with that?

It requires code specific to this attribute in RADIUS clients,
servers, and RADIUS<->Diameter translation agents. And that code 
cannot be reused for other attributes: e.g. in the current 
NAS-Traffic-Rule draft, the words "permit"/"deny" can appear in 
the  middle of a rule.

Yes, this would work for NAS-Filter-Rule -- but so would any of the
other proposals so far (e.g. rules end with LF; rule ends if 
attribute length <253; attributes begin with a tag octet; etc.)  
I don't think any of these proposals is a really good one, but at 
least the same approach could be reused for NAS-Traffic-Rule (and 
maybe other attributes in the future as well).

Best regards,
Pasi

------_=_NextPart_001_01C6A2A9.8C508B1D
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>RE: Issue: Attribute concatenation/splitting</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=2>Pasi,<BR>
<BR>
Understood.<BR>
<BR>
Tagging should not be used.&nbsp; Tagging is for grouping not for fragmentation.<BR>
<BR>
If I use tagging for fragmentation then what will I use for grouping when I want to group things together?<BR>
<BR>
I have to read the draft.&nbsp; Is permit/deny allowed inside the attribute because we are allowed to include more then one rule inside the packet? If that is the case IMO we should not do that.&nbsp; One rule per attribute.<BR>
<BR>
If we want to solve fragmentation in general then inserting a value inside the attribute will not work.&nbsp; I think we have to invent something in the header of the attribute.<BR>
<BR>
For example, if we were to use Diameter AVP in RADIUS we would add a new flag (where the 'M' 'V' flags are) to indicate that the value of this attribute spans the next attribute.<BR>
<BR>
Why don't we hold this work until we can agree on the Diameter AVP?<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Sat 7/8/2006 11:08 AM<BR>
To: Avi Lior; [email-masked]<BR>
Subject: RE: Issue: Attribute concatenation/splitting<BR>
<BR>
Avi Lior wrote:<BR>
<BR>
&gt; I think we should not allow to pack more then one Filter Rule in a<BR>
&gt; single attribute.<BR>
&gt;<BR>
&gt; A Filter Rule should be allowed to overflow (span) more then one<BR>
&gt; attribute.<BR>
&gt;<BR>
&gt; If you have more then one filter rules in a packet with some filter<BR>
&gt; rules overflowing, how can you tell when a new one begins?<BR>
&gt;<BR>
&gt; A filter rule always starts with an action: permit or deny.&nbsp; These<BR>
&gt; words do not appear anywhere else in the rule.&nbsp; Therefore a Filter<BR>
&gt; Atribute that starts with a permit or deny must be a new filter<BR>
&gt; rule.<BR>
&gt;<BR>
&gt; What is wrong with that?<BR>
<BR>
It requires code specific to this attribute in RADIUS clients,<BR>
servers, and RADIUS&lt;-&gt;Diameter translation agents. And that code<BR>
cannot be reused for other attributes: e.g. in the current<BR>
NAS-Traffic-Rule draft, the words &quot;permit&quot;/&quot;deny&quot; can appear in<BR>
the&nbsp; middle of a rule.<BR>
<BR>
Yes, this would work for NAS-Filter-Rule -- but so would any of the<BR>
other proposals so far (e.g. rules end with LF; rule ends if<BR>
attribute length &lt;253; attributes begin with a tag octet; etc.)&nbsp;<BR>
I don't think any of these proposals is a really good one, but at<BR>
least the same approach could be reused for NAS-Traffic-Rule (and<BR>
maybe other attributes in the future as well).<BR>
<BR>
Best regards,<BR>
Pasi<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6A2A9.8C508B1D--

--
to unsubscribe send a message 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, 08 Jul 2006 15:09:01 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Sat, 8 Jul 2006 18:08:10 +0300
To: <[email-masked]>, <[email-masked]>

Avi Lior wrote:

> I think we should not allow to pack more then one Filter Rule in a
> single attribute.
> 
> A Filter Rule should be allowed to overflow (span) more then one
> attribute.
> 
> If you have more then one filter rules in a packet with some filter
> rules overflowing, how can you tell when a new one begins?
> 
> A filter rule always starts with an action: permit or deny.  These
> words do not appear anywhere else in the rule.  Therefore a Filter
> Atribute that starts with a permit or deny must be a new filter
> rule.
> 
> What is wrong with that?

It requires code specific to this attribute in RADIUS clients,
servers, and RADIUS<->Diameter translation agents. And that code 
cannot be reused for other attributes: e.g. in the current 
NAS-Traffic-Rule draft, the words "permit"/"deny" can appear in 
the  middle of a rule.

Yes, this would work for NAS-Filter-Rule -- but so would any of the
other proposals so far (e.g. rules end with LF; rule ends if 
attribute length <253; attributes begin with a tag octet; etc.)  
I don't think any of these proposals is a really good one, but at 
least the same approach could be reused for NAS-Traffic-Rule (and 
maybe other attributes in the future as well).

Best regards,
Pasi

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

Delivery-date: Sat, 08 Jul 2006 02:22:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Fri, 7 Jul 2006 22:22:11 -0400
From: "Avi Lior" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Your preaching to the wrong guy.  I think I had a proposal on the table
when RADEXT started to extend the attributes space, and support
attribute segmentation.  Everyone was against it and not for technical
merits but because nobody thought we need to extend or should extend or
enhance etc etc ....

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 10:03 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: Issue: Attribute concatenation/splitting
> 
> On Fri, Jul 07, 2006 at 09:54:06PM -0400, Avi Lior wrote:
> > 
> > I understand what your objections.  You are trying to solve the 
> > problem in general.  Nothing wrong with that.
> > 
> > But as a specific solution to a specific problem what I 
> propose will 
> > work. No?
> 
> Sure, but so would any other technique.  That is, until the 
> filter-rule syntax is "enhanced" in some way.
> 
> Regards,
> Barney
> 
> -- 
> Barney Wolff         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: Sat, 08 Jul 2006 02:02:48 +0000
Date: Fri, 7 Jul 2006 22:02:37 -0400
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting

On Fri, Jul 07, 2006 at 09:54:06PM -0400, Avi Lior wrote:
> 
> I understand what your objections.  You are trying to solve the problem
> in general.  Nothing wrong with that.
> 
> But as a specific solution to a specific problem what I propose will
> work. No? 

Sure, but so would any other technique.  That is, until the filter-rule
syntax is "enhanced" in some way.

Regards,
Barney

-- 
Barney Wolff         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: Sat, 08 Jul 2006 01:53:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Fri, 7 Jul 2006 21:54:06 -0400
From: "Avi Lior" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney,

I understand what your objections.  You are trying to solve the problem
in general.  Nothing wrong with that.

But as a specific solution to a specific problem what I propose will
work. No? 

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 9:48 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: Issue: Attribute concatenation/splitting
> 
> On Fri, Jul 07, 2006 at 08:33:07PM -0400, Avi Lior wrote:
> > I think we should not allow to pack more then one Filter Rule in a 
> > single attribute.
> > 
> > A Filter Rule should be allowed to overflow (span) more then one 
> > attribute.
> > 
> > If you have more then one filter rules in a packet with some filter 
> > rules overflowing, how can you tell when a new one begins?
> > 
> > A filter rule always starts with an action: permit or deny.  These 
> > words do not appear anywhere else in the rule.  Therefore a Filter 
> > Atribute that starts with a permit or deny must be a new 
> filter rule.
> > 
> > What is wrong with that?
> 
> It's a layer violation.
> 
> What will be suggested when the next new attribute runs into 
> the same problem?  Another technique that depends on the 
> syntax of the particular attribute?
> 
> IMHO, Feh!
> 
> Regards,
> Barney
> 
> -- 
> Barney Wolff         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: Sat, 08 Jul 2006 01:47:58 +0000
Date: Fri, 7 Jul 2006 21:47:48 -0400
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting

On Fri, Jul 07, 2006 at 08:33:07PM -0400, Avi Lior wrote:
> I think we should not allow to pack more then one Filter Rule in a
> single attribute.
> 
> A Filter Rule should be allowed to overflow (span) more then one
> attribute.
> 
> If you have more then one filter rules in a packet with some filter
> rules overflowing, how can you tell when a new one begins?
> 
> A filter rule always starts with an action: permit or deny.  These words
> do not appear anywhere else in the rule.  Therefore a Filter Atribute
> that starts with a permit or deny must be a new filter rule.
> 
> What is wrong with that?

It's a layer violation.

What will be suggested when the next new attribute runs into the same
problem?  Another technique that depends on the syntax of the particular
attribute?

IMHO, Feh!

Regards,
Barney

-- 
Barney Wolff         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: Sat, 08 Jul 2006 01:44:43 +0000
Content-class: urn:content-classes:message
Subject: RE: The RADIUS attribute space: an assessment
Date: Fri, 7 Jul 2006 21:44:43 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>
Cc: <[email-masked]>

Some update:

Now that Diameter has been standerdized, 3GPP2 has started to include
Diameter in the Packet Data Network.  RADIUS is still mandatory and now
Vendors are free to deliver products based on Diameter.  Operators will
now have a choice.  Support for NASREQ, Mobile IP, EAP Application and
Credit Control.

WiMAX release 1.0 is based exclusively on RADIUS. However it is
anticipated that Diameter will come in the next release (1.5) I will
certainly try to bring it in.

We all know about the uses of Diameter in 3GPP.

I think that Diameter POs will start to come in the Carrier market.  But
it will take years before Diameter will overtake RADIUS.

When we talk about Diameter vs RADIUS etc we have to consider that there
are different deployement and business drivers to consider.  There is no
right answer except for one:  let the market decide.

I will continue to do work on (extend) RADIUS in the IETF or elsewhere
as long as my customers are willing to pay for that work.

I will also continue to work on Diameter because I belive that customers
will start to want it.

I think that we should extend the RADIUS attribute space in the IETF and
support new features etc...

The work mentioned by Bernard in Mobile IPv4 that requires 31 attributes
is a direct result of the philosophy of some in RADEXT that want flat
attribute space.  If we did the work in MIPv4 using complex attribute
encoding we would probably only need 10 attributes or less.

Therefore I think we should allow more complex attribute encoding. 

I am somewhat puzzled by Glen: on one hand he is yelling "Pull the plug"
on the other hand it seems that he is the RADIUS poster boy judging by
the number of RADIUS drafts he has floating around.

Avi

--
to unsubscribe send a message 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, 08 Jul 2006 00:35:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Fri, 7 Jul 2006 20:33:07 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I think we should not allow to pack more then one Filter Rule in a
single attribute.

A Filter Rule should be allowed to overflow (span) more then one
attribute.

If you have more then one filter rules in a packet with some filter
rules overflowing, how can you tell when a new one begins?

A filter rule always starts with an action: permit or deny.  These words
do not appear anywhere else in the rule.  Therefore a Filter Atribute
that starts with a permit or deny must be a new filter rule.

What is wrong with that?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, July 06, 2006 3:05 PM
> To: [email-masked]
> Subject: Re: Issue: Attribute concatenation/splitting
> 
> Do we have a conclusion from this thread?  If so, can someone 
> state what they think it is?
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Thu, 06 Jul 2006 21:13:56 +0000
Date: Thu, 6 Jul 2006 17:13:22 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting

On Thu, Jul 06, 2006 at 12:05:12PM -0700, Bernard Aboba wrote:
> Do we have a conclusion from this thread?  If so, can someone state what 
> they think it is?

I don't perceive a conclusion, which reinforces the thought that either
we define a standard way of escaping from the 253-byte limit or we get
to debate how to do it each and every time a new attribute might need it.
I'm too old for the latter, but there is a draft which would enable the
former:
http://www.ietf.org/internet-drafts/draft-wolff-radext-ext-attribute-00.txt

I'd be happy to update it based on comments from the list, if people will
express some interest.
Regards,
Barney

-- 
Barney Wolff         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: Thu, 06 Jul 2006 19:05:44 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Issue: Attribute concatenation/splitting
Date: Thu, 06 Jul 2006 12:05:12 -0700

Do we have a conclusion from this thread?  If so, can someone state what 
they think it is?

--
to unsubscribe send 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, 06 Jul 2006 14:44:39 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting 
cc: [email-masked]
Date: Thu, 06 Jul 2006 10:34:47 -0400
Message-Id: <[email-masked]>

[email-masked] wrote:
> It is, by including a long list of ports: E.g. "permit in tcp from 
> any to assigned 12345,22222,24224,27272,33333,..."

  In many of those cases, the list can be split on the *semantic*
level, rather than the RADIUS attribute level.  e.g. assuming there's
a trailing "deny all" filter, your example is entirely equivalent to

  permit in tcp from any to assigned 12345
  permit in tcp from any to assigned 22222
  permit in tcp from any to assigned 24224
  permit in tcp from any to assigned ...

  It's not optimal, but it will work, and it will avoid long RADIUS
attributes.

  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, 06 Jul 2006 07:24:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting 
Date: Thu, 6 Jul 2006 10:23:40 +0300
To: <[email-masked]>, <[email-masked]>

David Nelson wrote:

> It would be an interesting exercise to see if it is possible 
> to specify an instance of the IPFilterRule derived data type that 
> is longer than 253 octets.

It is, by including a long list of ports: E.g. "permit in tcp from 
any to assigned 12345,22222,24224,27272,33333,..."

(But perhaps this is so rare that we could simply say that rules
longer than 253 octets cannot be used with the RADIUS attribute.)

Best regards,
Pasi

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

Delivery-date: Wed, 05 Jul 2006 20:23:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting 
Date: Wed, 5 Jul 2006 16:22:34 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

>   If one rule can span multiple NAS-Filter-Rule attributes, then it
> needs a "terminate this rule" that is independent "terminate this
> attribute".

While the text in RFC 3588 and RFC 4005 could, IMHO, benefit from some
clarification, it appears to me that the Diameter NAS-Filter-Rule AVP
{RFC4005] contains one instance of the derived data type IPFilterRule
[RFC3588], which appears to describe a single rule.  If this is correct,
the only situation in which a rule would span multiple RADIUS
NAS-Filter-Rule Attributes is when the rule text exceeds 253 octets.
While this is theoretically possible, the formal syntax of IPFilterRule
tends to limit the likelihood for this to occur.  Or so it would seem to
me.

>  A CR, LF, or combination can do that, in which case the
> problem of attributes of length 2 doesn't exist, because the packing
> methods prohibit it.

I'm not in favor of ASCII delimiters for sub-strings within strings.
This is effectively "value packing" i.e. encoding multiple values in a
single value field of an RADIUS TLV.

>   If one rule cannot span multiple NAS-Filter-Rule attributes, then
> there is no problem, because an attribute of length 255 has no special
> meaning.

It would be an interesting exercise to see if it is possible to specify
an instance of the IPFilterRule derived data type that is longer than
253 octets.

>   On the other hand, if one rule can span multiple NAS-Filter-Rule
> attributes, then you might as well give up on trying to match rules to
> attributes.  Pack all of the rules together in one long string, and
> then chop the string every 253 bytes to encode it into NAS-Filter-Rule
> attributes.  So there will be no special meaning for attributes of
> length 255, so there will be no problem.

Ugh.

>   With this last method, we would presume that any implementation that
> needs to be able to add/delete rules would know about the packing
> methods, and be able to unpack/add/pack the rules into attributes.
> This would tend to break backwards compatibility with older RADIUS
> servers, so they wouldn't be able to edit the rules, though.

Right.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 05 Jul 2006 06:08:19 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting 
cc: [email-masked], [email-masked]
Date: Wed, 05 Jul 2006 01:58:30 -0400
Message-Id: <[email-masked]>

Rajith R <[email-masked]> wrote:
> In a RADIUS packet, there are 2 successive NAS-Filter-Rule attributes of
> length 255 & 50 respectively. How do you determine they are 2 separate
> attributes or a single attribute split?

  If one rule can span multiple NAS-Filter-Rule attributes, then it
needs a "terminate this rule" that is independent "terminate this
attribute".  A CR, LF, or combination can do that, in which case the
problem of attributes of length 2 doesn't exist, because the packing
methods prohibit it.

  If one rule cannot span multiple NAS-Filter-Rule attributes, then
there is no problem, because an attribute of length 255 has no special
meaning.

  On the other hand, if one rule can span multiple NAS-Filter-Rule
attributes, then you might as well give up on trying to match rules to
attributes.  Pack all of the rules together in one long string, and
then chop the string every 253 bytes to encode it into NAS-Filter-Rule
attributes.  So there will be no special meaning for attributes of
length 255, so there will be no problem.

  With this last method, we would presume that any implementation that
needs to be able to add/delete rules would know about the packing
methods, and be able to unpack/add/pack the rules into attributes.
This would tend to break backwards compatibility with older RADIUS
servers, so they wouldn't be able to edit the rules, though.

  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, 05 Jul 2006 04:41:04 +0000
Date: Wed, 05 Jul 2006 10:10:27 +0530
From: Rajith R <[email-masked]>
Subject: RE: Issue: Attribute concatenation/splitting
To: [email-masked], [email-masked]
Cc: [email-masked]
Reply-to: [email-masked]
Organization: huawei

See comments inline

****************************************************************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, July 04, 2006 10:30 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: Issue: Attribute concatenation/splitting
>
>[email-masked] wrote:
>> Yes, this would work as well: an attribute length 255 would mean that
>> the data item continues to the next attribute;
>
>  If the next attribute exists.
>
>> attribute length less than 255 would indicate the final piece of
>> this data item.
>
>  Or, if there is no next attribute.
>
>> The only catch might be that RFC 2865 prohibits string/text attributes
>> with length 2 (=string length 0).
>
>  Attributes of length 2 are unnecessary if the above conditions are met.

In a RADIUS packet, there are 2 successive NAS-Filter-Rule attributes of
length 255 & 50 respectively. How do you determine they are 2 separate
attributes or a single attribute split?

Rajith

>
>  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: Tue, 04 Jul 2006 17:09:55 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Attribute concatenation/splitting 
cc: [email-masked], [email-masked]
Date: Tue, 04 Jul 2006 12:59:54 -0400
Message-Id: <[email-masked]>

[email-masked] wrote:
> Yes, this would work as well: an attribute length 255 would mean that
> the data item continues to the next attribute; 

  If the next attribute exists.

> attribute length less than 255 would indicate the final piece of
> this data item.

  Or, if there is no next attribute.

> The only catch might be that RFC 2865 prohibits string/text attributes
> with length 2 (=string length 0).

  Attributes of length 2 are unnecessary if the above conditions are met.

  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, 03 Jul 2006 14:37:48 +0000
Content-class: urn:content-classes:message
Subject: RADEXT WG Agenda for IETF-66
Date: Mon, 3 Jul 2006 10:37:34 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C69EAE.38C4ACB6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This agenda is also posted at:

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66

Agenda for the RADEXT WG Meeting at IETF 66

MONDAY, July 10, 2006

0900-1130 Morning Session I Room 519A

WGs meeting at the same time: apparea, ancp, netlmm, enum, ccamp,
krb-wg, tsvwg  

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

B. Agenda Bashing

C. Milestone Status Review (5 minutes)

D. Document Status

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

draft-ietf-radext-rfc2618bis-04.txt

draft-ietf-radext-rfc2618bis-04.txt

draft-ietf-radext-rfc2618bis-04.txt

draft-ietf-radext-rfc2618bis-04.txt

draft-ietf-radext-dynauth-client-mib-06.txt

draft-ietf-radext-dynauth-server-mib-06.txt

draft-ietf-radext-delegated-prefix-01.txt

draft-ietf-radext-vlan-06.txt

D.2  Documents in Pre-WG review

D.3.1  NAS-Traffic-Rule Attributes (Mauricio Sanchez, 10 minutes)

http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-01.tx
t

D.3.2  NAS-Filter-Rule Attributes (Mauricio Sanchez, 10 minutes)

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

D.3.3  WLAN Attributes (Bernard Aboba, 10 minutes)

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

D.3.4  Pre-Authentication AAA Requirements (Yoshihiro Ohba, 10 minutes)

D.3.5  Design Guidelines (TBD proxy for Greg Weber, 30 minutes)

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

D.3.6  Extended RADIUS Attributes (TBD, 30 minutes)

http://www.ietf.org/internet-drafts/draft-wolff-radext-ext-attribute-00.
txt

D.3.7  Issues & Fixes (Bernard Aboba, 10 minutes)

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

D.3.8  NAS-Management (Dave Nelson, 10 minutes)

http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho
rization-03.txt

D.4  Documents requiring cross-WG review

D.4.1  GEOPRIV-RADIUS (TBD, 5 minutes)

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

D.4.2  ISMS Requirements for "Authorize Only"  (Dave Nelson, 5 minutes)

E. Wrap-Up (5 minutes)

------_=_NextPart_001_01C69EAE.38C4ACB6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>This agenda is also posted at:<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Agenda for the RADEXT WG Meeting at IETF 66<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>MONDAY, July 10, 2006<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>0900-1130 Morning Session I Room 519A<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>WGs meeting at the same time: apparea, ancp, netlmm, enum, ccamp,
krb-wg, tsvwg&nbsp; <o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>B. Agenda Bashing<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>C. Milestone Status Review (5 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D. Document Status<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.1 Documents in IESG review (5 minutes):<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>draft-ietf-radext-rfc2618bis-04.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>draft-ietf-radext-rfc2618bis-04.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>draft-ietf-radext-rfc2618bis-04.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>draft-ietf-radext-rfc2618bis-04.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>draft-ietf-radext-dynauth-client-mib-06.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>draft-ietf-radext-dynauth-server-mib-06.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>draft-ietf-radext-delegated-prefix-01.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>draft-ietf-radext-vlan-06.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.2&nbsp; Documents in Pre-WG review<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.3.1&nbsp; NAS-Traffic-Rule Attributes (Mauricio Sanchez, 10 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-01.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.3.2&nbsp; NAS-Filter-Rule Attributes (Mauricio Sanchez, 10 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-00.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.3.3&nbsp; WLAN Attributes (Bernard Aboba, 10 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-03.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.3.4&nbsp; Pre-Authentication AAA Requirements (Yoshihiro Ohba, 10 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.3.5&nbsp; Design Guidelines (TBD proxy for Greg Weber, 30 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-03.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.3.6&nbsp; Extended RADIUS Attributes (TBD, 30 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-wolff-radext-ext-attribute-00.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.3.7&nbsp; Issues &amp; Fixes (Bernard Aboba, 10 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-03.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.3.8&nbsp; NAS-Management (Dave Nelson, 10 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-03.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.4&nbsp; Documents requiring cross-WG review<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.4.1&nbsp; GEOPRIV-RADIUS (TBD, 5 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-07.txt<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>D.4.2&nbsp; ISMS Requirements for &quot;Authorize Only&quot;&nbsp; (Dave Nelson,
5 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>E. Wrap-Up (5 minutes)<o:p></o:p></span></font></p>

<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C69EAE.38C4ACB6--

--
to unsubscribe send a message 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, 03 Jul 2006 14:00:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Mon, 3 Jul 2006 09:59:56 -0400
To: <[email-masked]>

Pasi Eronen writes...

> Yes, this would work as well: an attribute length 255 would mean that
> the data item continues to the next attribute; attribute length less
> than 255 would indicate the final piece of this data item.

Making the RADIUS application layer fragmentation and reassembly
agnostic to specific attribute ID indeed has some attractive properties.

> The only catch might be that RFC 2865 prohibits string/text attributes
> with length 2 (=string length 0). But on the other hand, at least
> draft-aboba-radext-fixes talks about User-Name attributes with string
> length 0, so perhaps this could be used anyway...?

We are documenting this sort of "implementation discrepancies", but IMO,
we ought not to encourage them.  If RFC 2865 says MUST or MUST NOT, I
think we need to honor those requirements.

I'll offer another idea, although I'm not sure it is one that I would
prefer.  We can take advantage for the tagged attribute format used for
the tunnel attributes [RFC 2868].  All RADIUS attributes containing
fragments of a single Diameter rule would have the same tag value.

--
to unsubscribe send a message 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, 03 Jul 2006 12:08:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Mon, 3 Jul 2006 15:07:33 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[email-masked] wrote:
> 
> IMHO, split/concatenate logic for multiple, potentially long data
> items of the same type should be attribute type insensitive. One
> such option could be split at 253th byte boundary of the payload and
> add them successively to the RADIUS message. If the last (split)
> RADIUS attribute also happens to be of attribute length = 255, add a
> delimiter attribute (of the same type) with attribute length as 2.

Yes, this would work as well: an attribute length 255 would mean that
the data item continues to the next attribute; attribute length less
than 255 would indicate the final piece of this data item.

The only catch might be that RFC 2865 prohibits string/text attributes
with length 2 (=string length 0). But on the other hand, at least 
draft-aboba-radext-fixes talks about User-Name attributes with string 
length 0, so perhaps this could be used anyway...?

Best regards,
Pasi

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

Delivery-date: Mon, 03 Jul 2006 12:02:34 +0000
Content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-weber-radius-attr-guidelines-03.txt 
Date: Mon, 3 Jul 2006 08:01:51 -0400
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C69E98.880949F7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI, I updated the RADIUS attribute design guidelines 
draft based on the discussion at IETF-65 [1].  See the
02->03 diff [2] for details.

The three main issues raised were:
 -We do not want to preclude future mechanisms for
  per-attribute encryption (which may result from the
  current 'crypto-agility' work item).  We also want 
  to point at the concerns around the current MD5-based
  mechanism.
 -We want to enable SDOs to work independently (from the
  IETF) by using these guidelines
 -Structured data fall into different categories based
  on which entities consume (or parse) them.  Some of
  these categories are essentially opaque to RADIUS
  entities, and it's fine for these items to be over-
  loaded into existing types (like String).

I tried to address these issues in the current (-03) draft.

This topic will be discussed again at the upcoming IETF, 
so please have a read, file issues, and come with opinions
(or voice them on this list).

Regards,
Greg

[1]
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65tuech7.
mp3
(time index 1:22:40 - 1:58:26)
[2] http://employees.org/~gdweber/02-03-diff.html

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, June 27, 2006 6:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-weber-radius-attr-guidelines-03.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Design Guidelines for RADIUS Attributes
> 	Author(s)	: G. Weber
> 	Filename	: draft-weber-radius-attr-guidelines-03.txt
> 	Pages		: 17
> 	Date		: 2006-6-27
> 	
> This memo explores various issues related to the data model used by
> the Remote Authentication Dial In User Service (RADIUS) protocol.
> Recommendations are made to facilitate internal alignment and
> uniformity.  Attribute design guidelines are provided both as an aid
> to IETF development work, and to facilitate independent work by other
> Standards Development Organizations (SDOs).
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0
3.txt
> 

------_=_NextPart_001_01C69E98.880949F7
Content-Type: application/octet-stream;
	name="draft-weber-radius-attr-guidelines-03.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-weber-radius-attr-guidelines-03.URL
Content-Disposition: attachment;
	filename="draft-weber-radius-attr-guidelines-03.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC13ZWJlci1yYWRpdXMtYXR0ci1ndWlkZWxpbmVzLTAzLnR4dA0K

------_=_NextPart_001_01C69E98.880949F7--

--
to unsubscribe send a message 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, 03 Jul 2006 11:35:01 +0000
Date: Mon, 03 Jul 2006 16:54:20 +0530
From: Rajith R <[email-masked]>
Subject: RE: Issue: Attribute concatenation/splitting
To: [email-masked], [email-masked], [email-masked]
Reply-to: [email-masked]
Organization: huawei

See comments inline

************************************************************************
****
This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient's) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!

>>-----Original Message-----
>>From: [email-masked]
[mailto:[email-masked]]
>>On Behalf Of [email-masked]
>>Sent: Monday, July 03, 2006 4:30 PM
>>To: [email-masked]; [email-masked];
[email-masked]
>>Subject: RE: Issue: Attribute concatenation/splitting
>>
>>[email-masked] wrote:
>>
>>> AFAIK, splitting & concatenation are necessitated by the 255 byte
>>> limit for RADIUS attributes. So it would be better to split at 253
>>> byte (for the attribute payload) boundary rather than LF or some
>>> other attribute specific delimiter, I think this would have the
>>> advantage of
>>> * same & simple logic for concatenation/splitting of any
>>> suitable RADIUS attribute of length > 255
>>> * packing efficiency in the message, though not a principal concern
>>
>>This simple concatenation/splitting works when you need to include a
>>single, potentially long data item (e.g. EAP-Message) in a RADIUS
>>message. But it gets complex if you need to include multiple,
>>potentially long data items of the same type (in this case, individual
>>filter rules) and you need to maintain the boundaries between the
>>individual data items somehow.

IMHO, split/concatenate logic for multiple, potentially long data items
of the same type should be attribute type insensitive. One such option
could be split at 253th byte boundary of the payload and add them
successively to the RADIUS message. If the last (split) RADIUS attribute
also happens to be of attribute length = 255, add a delimiter attribute
(of the same type) with attribute length as 2.

>>
>>In particular, if we decide to support individual filter rules longer
>>than 253 characters, it looks like a RADIUS-to-Diameter translation
>>agent will need code specific to NAS-Filter-Rule no matter how we
>>choose to do the concatenation/splitting on the RADIUS side. The
>>difference is just how complex that code needs to be (e.g., is it
>>sufficient just to recognize "LF", or understand the full filter
>>rule syntax).

To convert a RADIUS NAS Filter rule attribute to Diameter, the Diameter
AVP header data should be generated/translated from RADIUS attribute
header data and the attribute payload could be directly copied to the
AVP payload. Only concatenation considerations need to be applied. 

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

--
to unsubscribe send a message 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, 03 Jul 2006 11:00:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Mon, 3 Jul 2006 14:00:18 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

[email-masked] wrote:

> AFAIK, splitting & concatenation are necessitated by the 255 byte
> limit for RADIUS attributes. So it would be better to split at 253
> byte (for the attribute payload) boundary rather than LF or some
> other attribute specific delimiter, I think this would have the
> advantage of
> * same & simple logic for concatenation/splitting of any 
> suitable RADIUS attribute of length > 255
> * packing efficiency in the message, though not a principal concern

This simple concatenation/splitting works when you need to include a
single, potentially long data item (e.g. EAP-Message) in a RADIUS
message. But it gets complex if you need to include multiple,
potentially long data items of the same type (in this case, individual
filter rules) and you need to maintain the boundaries between the
individual data items somehow.

In particular, if we decide to support individual filter rules longer
than 253 characters, it looks like a RADIUS-to-Diameter translation
agent will need code specific to NAS-Filter-Rule no matter how we
choose to do the concatenation/splitting on the RADIUS side. The
difference is just how complex that code needs to be (e.g., is it
sufficient just to recognize "LF", or understand the full filter
rule syntax).

Best regards,
Pasi

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

Delivery-date: Mon, 03 Jul 2006 10:04:21 +0000
Date: Mon, 03 Jul 2006 15:31:34 +0530
From: Rajith R <[email-masked]>
Subject: RE: Issue: Attribute concatenation/splitting
To: [email-masked], [email-masked], [email-masked]
Reply-to: [email-masked]
Organization: huawei

AFAIK, splitting & concatenation are necessitated by the 255 byte limit
for RADIUS attributes. So it would be better to split at 253 byte (for
the attribute payload) boundary rather than LF or some other attribute
specific delimiter, 
I think this would have the advantage of
* same & simple logic for concatenation/splitting of any suitable RADIUS
attribute of length > 255
* packing efficiency in the message, though not a principal concern

************************************************************************
****
This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient's) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, July 03, 2006 3:09 PM
To: [email-masked]; [email-masked]
Subject: RE: Issue: Attribute concatenation/splitting

Bernard Aboba wrote:
> 
> >I guess this means that a single long rule can be split into multiple
> >NAS-Filter-Rule attributes?
> 
> Yes.
> 
> >And a single NAS-Filter-Rule attribute could contain pieces 
> >of multiple rules?
> 
> Yes.
> 
> BTW, do the same issues also apply to the NAS-Filter-Rule AVP 
> defined in RFC 4005?

As far as I can tell, no: in RFC 4005, a single AVP always contains
one complete rule (long rules are not split into multiple AVPs, and
one AVP never contains multiple rules).

> >If so, I'd recommend separating the individual rules somehow.
> 
> Question: Does introducing a separator into NAS-Filter-Rule
> attribute complicate the translation to and from NAS-Filter-Rule
> AVP?
> 
> For example, can we have multiple filter rules in a NAS-Filter-Rule 
> AVP, and if so, how do we tell when one rule ends and another begins?

Hmm... the translation is going to be messy no matter what, unless
we remove the splitting/concatenation from the RADIUS attribute.
This would make it impossible to translate rules that are longer
than 253 characters... but perhaps this is not a big problem? 

Rules that long are probably extremely rare, and there are already
situations that cannot be translated (if the total length of rules
and other attributes exceeds 4096 bytes).

Best regards,
Pasi

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

--
to unsubscribe send a message 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, 03 Jul 2006 09:42:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Attribute concatenation/splitting
Date: Mon, 3 Jul 2006 12:38:32 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard Aboba wrote:
> 
> >I guess this means that a single long rule can be split into multiple
> >NAS-Filter-Rule attributes?
> 
> Yes.
> 
> >And a single NAS-Filter-Rule attribute could contain pieces 
> >of multiple rules?
> 
> Yes.
> 
> BTW, do the same issues also apply to the NAS-Filter-Rule AVP 
> defined in RFC 4005?

As far as I can tell, no: in RFC 4005, a single AVP always contains
one complete rule (long rules are not split into multiple AVPs, and
one AVP never contains multiple rules).

> >If so, I'd recommend separating the individual rules somehow.
> 
> Question: Does introducing a separator into NAS-Filter-Rule
> attribute complicate the translation to and from NAS-Filter-Rule
> AVP?
> 
> For example, can we have multiple filter rules in a NAS-Filter-Rule 
> AVP, and if so, how do we tell when one rule ends and another begins?

Hmm... the translation is going to be messy no matter what, unless
we remove the splitting/concatenation from the RADIUS attribute.
This would make it impossible to translate rules that are longer
than 253 characters... but perhaps this is not a big problem? 

Rules that long are probably extremely rare, and there are already
situations that cannot be translated (if the total length of rules
and other attributes exceeds 4096 bytes).

Best regards,
Pasi

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