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

From: "Glen Zorn" <[email-masked]>
Date: Fri, 31 Aug 2001 21:03:45 -0700

Pat Calhoun [mailto:[email-masked]] writes:

> So folks feel comfortable with straight auth and encr transforms being
> encoded, with no actual implied usage?
>
> Should 3DES-CBC be used with IPSec, WEP, ???
>
> Maybe RC4-128 could be used with TLS??

I think a better question is, "What is the difference between the keys used
with the same algorithm in different protocols?"  Is there some fundamental
difference between 3DES keys for PPP and 3DES keys for IPSEC?  Or 128-bit
RC4 keys for MPPE or TLS?  I don't think so.

>
> I'm not sure I'm too crazy on this. I MUCH prefer keeping
> the draft as-is.

BTW, I'm not too thrilled w/making the key lifetime dependant on the
authorization lifetime:  I can think of many situations in which a user
might be authorized for unlimited service, but encryption keys need to be
chamged at a regular interval.  Also, the current language seems to assume
that the NAS will go back to the AAA server whenever new keys are needed,
which is certainly not the case.

>
> PatC
> On Fri, Aug 31, 2001 at 04:48:49PM -0700, Bernard Aboba wrote:
> > >I dispute that WEP constitues a ciphersuite. Perhaps RC4-128?
> >
> > This does make more sense. So instead of MPPE and WEP, we'd have:
> >
> > RC4-40   [MPPE, WEP]
> > RC4-128 [MPPE, WEP-128]
> > 3DES-CBC [PPP 3DES]
> > DES-CBC [PPP DES]
> >
> > I'd suggest that the ciphersuite code be structured as two
> > two-octet fields, one for auth, one for encryption:
> >
> > Auth                       Encryption
> > ====                       ==========
> > None                       None
> > HMAC-MD5                   RC4-40
> > HMAC-SHA1                  RC4-128
> > AES-CBC-MAC                DES-CBC
> >                            3DES-CBC
> >                            AES-CBC
> >                            AES-CTR
> >
> >
> > So PPP DES would be DES-CBC with NONE, MPPE would be RC4-40 with NONE,
> > etc.
> >
>

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 1 Sep 2001 07:42:56 +0300

> > Maybe RC4-128 could be used with TLS??

I seem to like the pure algorithm approach more, because
it would be better usable in new contexts. However, the
issue with straight algorithms is that a NAS might not
know what it needs to do, say if it has ESP DES and PPP-DES,
which one will it choose? Also, protocols like ESP have more
options than just the algorithms.

One way to deal with this is to just bundle everything
with the usage, e.g. PPP-CBC-DES-NO-AUTH.
Another way to deal with this is to have a set of
AVPs now that enables us to express our known
combinations now (Usage, Encryption Alg, Integrity
Alg), with the expectation that if somebody wants to
define how this works for IPsec, he needs to add new
AVPs -- later.

I would perhaps like the latter approach more.

Jari

---

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

> RC4 keys for MPPE or TLS?  I don't think so.
Yes, the existing draft language will cause an explosion of ciphersuites,
for no useful purpose.

> which is certainly not the case.

Yes, this is broken.

---

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

> options than just the algorithms.

That is handled by other AVPs. ESP DES can only be provided 
if there are Tunnel AVPs present. PPP encryption algorithms are negotiated
later, in ECP. So you would need to provide the NAS with a list of
acceptable algorithms to be negotiated within ECP. Right now the Grouped
AVP isn't structured correctly for this. You'd have to provide a separate
key for each algorithm you could negotiate. It makes more sense to provide
the key, and list of potential algorithms separately.

---

From: Pat Calhoun <[email-masked]>
Date: Sat, 1 Sep 2001 12:26:34 -0700

> the key, and list of potential algorithms separately. 

Then open issue, and propose text, please.

PatC