RE: Issue with 3576

[Avi Lior <avi@bridgewatersystems.com>]

Okay I see my confusion:

1) Message-Authenticator SHOULD be included in an Access-Request that does
not contain....EAP-Message,

2) Message-Authenticator MUST be included in an Access-Request that contains
EAP-Message.

I am aware of item 2 but somehow when I read item 1) it seemed to exclude
item 2).  So I am okay now.
  


> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Tuesday, July 27, 2004 10:49 AM
> To: Avi Lior
> Cc: Murtaza Chiba; david@mitton.com; radiusext@ops.ietf.org
> Subject: Re: Issue with 3576
> 
> 
> > I found a minor bug in 3576 ( I don't know if this one was reported 
> > yet)
> >
> > Deep down in Note[6] it says:
> >
> > 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.
> 
> The complete quote is:
> 
>  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.
> 
> Note [6] applied to the Service-Type attribute, in order to 
> remind implementers that Service-Type="Authorize Only" could 
> not be sent in an Access-Request without a 
> Message-Authenticator attribute.
> 
> > The inclusion of EAP-Message in an Access-Request however 
> does require 
> > Message-Authenticator.
> 
> Yes, that is required (in [RFC2869] and [RFC3579]).  Since 
> the quote references those documents, I don't think there is 
> a contradiction.
> 
> > As well, unless I am missing something, 3576 does not say what the 
> > semantics of the Re-authorization Access-Request message.
> 
> Note [6] says:
> 
> "the NAS should attempt reauthorization by sending an Access- 
> Request with a Service-Type Attribute with value "Authorize 
> Only". The (perhaps naive) assumption is that these 
> Access-Request messages would otherwise obey RFC 2865.
> 
> > It just eludes to the fact
> > that it is there to ease interop between RADIUS and 
> DIAMETER.  Reading 
> > between the line then one would conclude that they have to read 
> > diameter to understand the semantics.  In fact NASREQ right?
> 
> NASREQ does contain the discussion on the translation of 
> server-initiated messages between RADIUS and Diameter.  Among 
> other things, we discovered in the process of writing those 
> sections that the RFC 3579 discussion of translation of 
> Disconnect-Request messages is wrong; Diameter supports the 
> Disconnect-Request/ACK model, so that an "Authorize Only" 
> Disconnect-Request is not necessary.  That is a pretty 
> significant error, so an errata is probably needed for that.
> 
> > It should be more explicit what the behavior is.  For example, we 
> > should state what happens when the Access-Accept with an 
> > Authorize-Only is received that doesn't contain attributes 
> that were 
> > previously received in an Access-Accept message.  This is cause for 
> > lots of discussion.
> 
> Yes, I do think we need to be more explicit on this.  This 
> can be put into an errata (or the "implementations and fixes" 
> doc) once we figure this out.
> 

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