[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Issue] RFC 3576 Usage of Message-Authenticator
Bernard Aboba <> supposedly scribbled:
> In looking through the Attribute table in RFC 3576, Section 3.2,
> there appears to be two attributes that depend on the Request
> 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
> to send a CoA-Request with Service-Type="Authorize Only". The
> encrypted attribute would not need to be present in the
> 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.
This discussion has brought to light something that doesn't make
sense to me. The Request Authenticators calculated differently in
Access-Requests and Accounting-Requests, but I don't understand why
(& I can't believe I didn't notice this before). RFC 2866 says "Note
that the Request Authenticator of an Accounting-Request can not be
done the same way as the Request Authenticator of a RADIUS
Access-Request, because there is no User-Password attribute in an
Accounting-Request." The problem is, while the "encryption"
technique used for the User-Password Attribute depends upon the
Request Authenticator, the dependency is not, as far as I can tell,
mutual. Maybe someone can explain this?
> On Sun, 30 Jan 2005, Murtaza Chiba wrote:
>> Sounds good. Somewhat related, there are Vendor attributes
>> encrypted, although we want to discourage per attribute
>> the fact of the matter is that Customers are using it. So I
>> like to request a new attribute Initialization-Vector that can be
>> used for all encrypted attributes in CoA and Disconnect Messages.
>> firstname.lastname@example.org wrote:
>>> I agree with your proposal.
Hope this helps,
Why is it that most of the world's problems can't be solved by
listening to John Coltrane? -- Henry Gabriel
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.