RE: Issue 79; digest-auth realm validation

["Salowey, Joe" <jsalowey@cisco.com>]

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


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