Re: FW: I-D ACTION:draft-zorn-radius-encattr-00.txt

["Alan DeKok" <aland@ox.org>]

"Glen Zorn (gwz)" <gwz@cisco.com> wrote:
> >   This allows the Encrypted-Attribute to be "stand-alone", and
...
> 
> Yes, but the semantic validity of the encrypted data may, in fact,
> depend upon the integrity of unencrypted data, so it just seemed
> better make sure the whole message arrived intact.

  Hmm... OK.

  Is there a security issue, then, with the clear-text data being
related to the encrypted data?  Are there potential attacks?

> > In
> > addition, the Message-Authentication-Code has different algorithms
> > for different kinds of packets, which makes implementation a
> > little  more awkward. 
> 
> I don't understand.

  Sorry, not "different algorithms", but "different treatments".

  i.e. In order to to calculate the Message-Authentication-Code for
Access-Accept, you need the Request Authenticator, and the attributes
from the Access-Accept.  So the Message-Authentication-Code
calculation requires access to information from multiple packets.

  My feeling is that a MAC in the Encrypted-Attribute feels better to
me, but I can see your arguments.

  Just my $0.02.

  Alan DeKok.

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