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

["Avi Lior" <avi@bridgewatersystems.com>]

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: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz)
> Sent: Wednesday, July 26, 2006 11:27 AM
> To: Nelson, David
> Cc: isms@ietf.org; radiusext@ops.ietf.org
> Subject: RE: [Isms] RE: Follow up on Authorize Only issue
> 
> Nelson, David <mailto:dnelson@enterasys.com> 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
> > Isms@lists.ietf.org
> > 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 
> radiusext-request@ops.ietf.org 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>