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

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

Alan DeKok <> supposedly scribbled:

> "Glen Zorn (gwz)" <gwz@cisco.com> wrote:
>> FYI, general-purpose scheme for
encrypting/transmitting/decrypting
>> arbitrary RADIUS attributes.
> 
>   Nice.  

Thank you!

> Minor nit: It references keywrap-03, which isn't in the I-D
> archive yet. 

Sequencing problem: it will be, shortly.

> 
>   Have you considered using a HMAC header as part of the
> Encrypted-Attribute, rather than a separate attribute? 
> 
>   e.g.    Encrypted-Attribute[s] = HMAC(encrypted_data) +
> encrypted_data 
> 
>   This allows the Encrypted-Attribute to be "stand-alone", and
avoids
> having the HMAC calculation depend on other, non-encrypted data.  

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.

> 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.
   
> 
>   Having the Encrypted-Attribute contain its own HMAC ensures that
> it's calculation can be done with only "local" information about
the
> attributes to be encrypted, and not require any "outside" data
like
> authentication vectors or other attributes.   
> 
>   Alan DeKok.

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