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

From: Pat Calhoun <[email-masked]>
Date: Mon, 27 Aug 2001 15:07:15 -0700

Bernard,

You implied new issues in the following statement:

"I also believe that the following issues need to be re-opened:
 
 nasreq-07: Issue #29 (need to substitute RFC 3162 attribute #s for 
            TBD)
            Issue #36 (need to remove AES/OCB from list, change "WEP2"
            to WEP-128"). "

I will create two new issues (easier to track than re-opening the old ones).
As far as the second issue, is the following the correct reference for WEP?

[22] Information technology - Telecommunications and information
     exchange between systems - Local and metropolitan area networks -
     Specific Requirements Part 11:  Wireless LAN Medium Access Control
     (MAC) and Physical Layer (PHY) Specifications, IEEE Std.
     802.11-1999, 1999.

Thanks,

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Aug 2001 21:17:36 -0700 (PDT)

WEP reference is correct. Will try to find reference for WEP-128 (there is
no IEEE standard for this). RFC 3162 will issue soon.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 28 Aug 2001 06:48:17 -0700

> no IEEE standard for this). RFC 3162 will issue soon. 

If we cannot find such a reference (because the work is in progress), we
have two options:

1. Leave it as-is with no reference, or
2. Remove it from the spec, and request a number from IANA in the future.

Your call.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Aug 2001 09:38:08 -0700 (PDT)

The reference exists (it's already been implemented by several
vendors). The question is where it is documented (since it's not an IEEE
standard, it might be a WECA document).

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 30 Aug 2001 14:37:25 -0700

Bernard Aboba [mailto:[email-masked]] writes:

> no IEEE standard for this).

AFAIK, aqll existing 128-bit WEP implementations are proprietary, so maybe
we don't want to enshrine it in a standard...

> RFC 3162 will issue soon.
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Aug 2001 15:06:25 -0700 (PDT)

> AFAIK, all existing 128-bit WEP implementations are proprietary, so maybe

The idea of this was to enable sending of keys from AAA server to
NAS, as a way to provide standard versions of the key attributes defined
in RFC 2548, which defines separate Send-Key and Receive-Key attributes,
which include a Salt and String, and can be of arbritrary length. 

Note that EAP methods derive a single master-key and so must provide a 
specification for how auth and encryption keys are derived from that
master key in each direction. The keys send via AAA must match that
derivation. Since the NAS is assumed EAP agnostic, rather than just
sending the master key (and requiring the NAS to implement the logic to
derive the other keys from that), the actual derived keys are sent. 

The Diameter Nasreq NAS-Session-Key Grouped AVP does contain  
NAS-Key,  NAS-Key-Type, and NAS-Key-Direction AVPs. So far, so good.
However, it also includes a NAS-Key-Binding AVP, which is what this
discussion is about. 

The question is why NAS-Key-Binding AVP is needed at all. If we assume
that the EAP method derives the same key regardless of ciphersuite, and 
that the ciphersuite defines the method in which the EAP key is translated
to auth/encryption keys in each direction, then the ciphersuite is needed
by the AAA server to send the right key set. However, if the EAP method
determines the derivation (as RFC 2716 does), then the ciphersuite does
not need to be known by the AAA server, and the NAS needs to build in the
logic to derive ciphersuite-adjusted keys from those sent in the
NAS-Session-Key Grouped AVP. 

In designing this Grouped AVP, we assumed that the ciphersuite might need
to be known to do the right thing. That implies that the length and format
of the NAS-Key AVP might differ depending on the ciphersuite, and also
that the NAS-Key-Binding AVP is present in Requests, not just Responses
(to serve as a guide). 

If the above is true, then I think we need to specify those ciphersuites
that are in use, regardless of whether they are standard. Otherwise, those
ciphersuites couldn't be made to work with Diameter.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 30 Aug 2001 15:12:08 -0700

> ciphersuites couldn't be made to work with Diameter. 

ok, but I still need something to reference, or just leave WEP-128
with no reference.

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 31 Aug 2001 07:38:17 +0300

> ciphersuites couldn't be made to work with Diameter. 

It's also possible for the vendors to get a new IANA number allocation,
when they need it for their ciphersuite. Will that help? Will they need
their own informational RFC, or just the IANA allocation?

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Aug 2001 00:16:35 -0700 (PDT)

> their own informational RFC, or just the IANA allocation?

IANA allocation should be fine.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 31 Aug 2001 08:09:54 -0700

> IANA allocation should be fine. 

So are you stating that I should remove WEP-128 from the spec?

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Aug 2001 08:56:20 -0700 (PDT)

> Should I remove WEP-128 from the spec? 

Ys, you can go ahead and do that.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 31 Aug 2001 14:42:16 -0700

> ciphersuites couldn't be made to work with Diameter.

No argument there; I would dispute that WEP constitutes a ciphersuite
however.  Perhaps just RC4-128?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Aug 2001 16:48:49 -0700 (PDT)

>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: "Glen Zorn" <[email-masked]>
Date: Fri, 31 Aug 2001 17:19:33 -0700

> two-octet fields, one for auth, one for encryption:

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 ;-)?

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 31 Aug 2001 20:22:51 -0700

> no IEEE standard for this). RFC 3162 will issue soon.

FYI, it is available now: ftp://ftp.isi.edu/in-notes/rfc3162.txt

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 31 Aug 2001 20:17:45 -0700

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'm not sure I'm too crazy on this. I MUCH prefer keeping
the draft as-is.

PatC