Subject: RE: [Isms] RE: Follow up on Authorize Only issue

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 26 Jul 2006 08:26:38 -0700

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

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 26 Jul 2006 15:55:43 -0400

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