Re: [Issue] RFC 3576 Usage of Message-Authenticator

[Bernard Aboba <aboba@internaut.com>]

In looking through the Attribute table in RFC 3576, Section 3.2, there
appears to be two attributes that depend on the Request Authenticator:
Message-Authenticator (80), and Tunnel-Password (69).

If the desire were to change the value of the Tunnel-Password attribute or
any other attribute depending on the Request Authenticator, one way to
get around the chicken-egg problem would be to send a CoA-Request
with Service-Type="Authorize Only".  The encrypted attribute would not need to
be present in the CoA-Request, but could then be present in a subsequent
Access-Accept, using the existing attribute definitions.

It would therefore appear to me that the Tunnel-Password attribute should
probably also have a "0" for its entries in the table in Section 3.2,
instead of "0-1".

Defining a new Nonce attribute, and then re-defining existing
IETF standard attributes to use it when present in a CoA-Request seems
somewhat problematic to me.


On Sun, 30 Jan 2005, Murtaza Chiba wrote:

> Bernard,
> 	Sounds good.  Somewhat related, there are Vendor attributes that are
> encrypted, although we want to discourage per attribute encryption, the
> fact of the matter is that Customers are using it.  So I would like to
> request a new attribute Initialization-Vector that can be used for all
> encrypted attributes in CoA and Disconnect Messages.
>
> Regards,
> Murtaza
>
> john.loughney@nokia.com wrote:
> > Bernard,
> >
> > I agree with your proposal.
> >
> > John

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