[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: I-D ACTION:draft-zorn-radius-encattr-00.txt
"Glen Zorn (gwz)" <email@example.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.
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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.