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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

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

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

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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