[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue with 3576
Okay I see my confusion:
1) Message-Authenticator SHOULD be included in an Access-Request that does
2) Message-Authenticator MUST be included in an Access-Request that contains
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:email@example.com]
> Sent: Tuesday, July 27, 2004 10:49 AM
> To: Avi Lior
> Cc: Murtaza Chiba; firstname.lastname@example.org; email@example.com
> 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 it says:
> > a Message-Authenticator attribute SHOULD be included in an
> > Access-Request that does not contain a User-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  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  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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.