Re: Issue with 3576

[Bernard Aboba <aboba@internaut.com>]

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