Re: [HOKEY] RE: Need advise on advancing draft-gaonkar-radext-erp-attrs

  Hi,

  MPPE is just wrong; IPsec has issues, as Glen notes. But RFC3394 has
it's own problems. It doesn't have a security proof behind it and it
doesn't allow for the inclusion of additional authenticated, but not
wrapped, data. draft-zorn-radius-keywrap-13.txt uses a separate and
additonal MAC on the RADIUS response to get around that latter issue.
RFC3394 also imposes unnatural restrictions on the data being wrapped
which might not be an issue in this case but it's still sub-optimal.

  So let me take this opportunity to tell everyone about
draft-dharkins-siv-aes-00 which describes a new AES cipher mode for
authenticated encryption. It can be used in the traditional nonce-based
authenticated encryption mode and also in a deterministic, nonce-less
key wrap mode. It has a security proof (in "Deterministic Authenticated
Encryption" by Rogaway and Shrimpton, which defines SIV) and allow for
additional authenticated, but not encrypted, data to be input. It also
doesn't impose any unnatural restrictions on the length of the data to be
wrapped. It would be ideal for this sort of problem!

  Also note that when SIV is used in the traditional nonce-based
authenticated encryption mode it provides a level of resistance to
nonce reuse whereas the security of other authenticated encryption schemes
are voided when the nonce gets reused (e.g. GCM, CCM).

  Dan.

On Sun, July 15, 2007 2:18 pm, Glen Zorn (gwz) wrote:
> Lakshminath Dondeti <mailto:ldondeti@qualcomm.com> allegedly scribbled
> on Sunday, July 15, 2007 1:27 PM:
>
>> Glen,
>>
>> I am definitely open to ideas.  At the moment, the model we used is
>> the MSK delivery mechanism (actually my understanding of the commonly
>> used MSK delivery mechanism) of RADIUS.
>
> OK, but I don't know what MSK is delivered this way (certainly not
> 802.11i, which I think is the most common).
>
>> It is the simplest, but as
>> you note has issues.
>
> Well, yes it does, in that it uses the MS MPPE keying attributes but it
> doesn't have the issue I was referring to (the use of IPsec).
>
>> Please send your review to the list and propose
>> alternatives; we can discuss and go with whatever solution we have
>> consensus for, as usual.
>>
>> thanks,
>> Lakshminath
>>
>> On 7/15/2007 10:55 AM, Glen Zorn (gwz) wrote:
>>> David B. Nelson <mailto:d.b.nelson@comcast.net> allegedly scribbled
>>> on Thursday, July 12, 2007 4:30 AM:
>>>
>>> ...
>>>
>>>> Having said all of that, I will note that the RADIUS Crypto-Agility
>>>> work item in RADEXT addresses RADIUS key-wrap and key delivery, and
>>>> this seems to have significant overlap with the
>>>> draft-gaonkar-radext-erp-attrs draft.  We should address that issue.
>>>
>>> Well, it _could_ (probably should) use key wrap, but at the moment it
>>> doesn't specifying instead the use of IPsec (A Really Bad Idea (TM)
>>> IMHO BTW) so in its present state I don't really see much overlap
>>> w/the crypto-agility work.  What am I missing?
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey