Subject: RE: [AAA-WG]: Bernard's implied issues

From: Bernard Aboba <[email-masked]>
Date: Sat, 1 Sep 2001 09:56:10 -0700 (PDT)

> Yes; I suppose that algorithms that do both auth& encryption (e.g. AES-OCB)
> could just use the same value in both fields, right?  BTW, while we're here
> I wonder if it would be a good idea to add an (optional) IV to the group,
> for block ciphers (and the misbegotten WEP ;-)?
> 
So the AAA server would provide the starting IV?

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 1 Sep 2001 10:22:51 -0700

> So the AAA server would provide the starting IV?

Possibly, yes.  This would seem to make sense at least in the EAP-TLS case,
since the IVs are derived on the EAP server and presumably returned to the
NAS (although I just noticed that RFC 2716 says "The peer encryption key
(the one used for encrypting data from peer to EAP server)" when I

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
can't see any reason why the peer would need to encrypt EAP server-bound
data in the protocol).

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 1 Sep 2001 10:51:56 -0700 (PDT)

> (the one used for encrypting data from peer to EAP server)" when I

Couldn't the IV be returned as part of the key? For example, in WEP-128,
there is a 24-bit IV and 104-bit key. 

The RFC 2716 quote above is a typo. Encryption only occurs between the
peer and the NAS.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 1 Sep 2001 11:19:55 -0700

> there is a 24-bit IV and 104-bit key.

I suppose so, though they really are logically separate entities...