Subject: [AAA-WG]: [Issue] proposed text for NASREQ KDC

From: Pat Calhoun <[email-masked]>
Date: Fri, 1 Jun 2001 15:40:25 -0700

All,

Below is my proposed (slightly modified) text that discusses the KDC proposal.
I did remove the SPI field, since this is really a Mobile IP thing, and the
original author had stated that he wasn't sure it would be needed in PPP.

Note, however, that I sent an e-mail earlier about how this should be used,
as it really isn't clear, and perhaps what is needed is an additional AVP that
informs the NAS what to do with the key. Without this, the NAS would have to
guess whether it should use the key for 802.11 over the air security, securing
the phone line, etc.

Ideas?

PatC
----
2.1.3  NAS-Session-Key AVP

Calhoun et al.            expires October 2001                  [Page 9]

Internet-Draft                                                  May 2001

   The NAS-Session-Key AVP (AVP Code TBD) is of type Grouped, and
   contains a session key distributed from Diameter servers to clients.
   The keys MAY be used for integrity and/or confidentiality protection
   between the NAS and the user. The keys MAY be distributed to the user
   as part of an EAP authentication exchange. Its Data field has the
   following ABNF grammar:

      NAS-Session-Key ::= < AVP Header: TBD >
                          { NAS-Key-Direction }
                          { NAS-Key-Type }
                          { NAS-Key }
                        * [ AVP ]

   NAS session keys are the keys created by a Diameter server, which it
   distributes to the NAS, acting as a Diameter client. The keys can be
   used for integrity and confidentiality protection between the NAS and
   the user. The keys can be distributed to the user for example as part
   of the EAP authentication procedure.

   If strong authentication and confidentiality of the session keys is
   required, it is recommended that the CMS security application [13] be
   used to protect the NAS-Session-Key AVP.

   The NAS-Session-Key AVP MAY appear zero or more times in the AAA and
   DEA messages. When more than one NAS-Session-Key AVP is present in a
   message, either the NAS-Key-Type or the NAS-Key-Direction AVPs MUST
   have different values. Otherwise, the AVPs would conflict with each
   other.

   The lifetime of the NAS-Session-Key AVP is found in the
   Authorization-Lifetime AVP. If a re-authorization request is received
   prior to the expiration of the lifetime, new keys will need to be
   distributed.

2.1.4  NAS-Key-Direction

   The NAS-Key-Direction AVP (AVP Code TBD) is of type Unsigned32, and
   specifies the direction that the traffic is to be protected with the
   key. The following values are supported:

      BIDIRECTIONAL              0
         The key is used in both directions

      UPLINK                     1
         The key is used for traffic from the user

      DOWNLINK                   2

Calhoun et al.            expires October 2001                 [Page 10]

Internet-Draft                                                  May 2001

         The key is used for traffic sent to user

2.1.5  NAS-Key-Type

   The NAS-Key-Type AVP (AVP Code TBD) is of type Unsigned32, and
   specifies how the key is to be used. The following values are
   supported:

      CIPHER_KEY                 1
         The key is used to encrypt data

      INTEGRITY_KEY              2
         The key is used to authenticate the data

2.1.6  NAS-Key-Data

   The NAS-Key-Data AVP (AVP Code TBD) is of type OctetString and
   contains the session key to be used between the user and the access
   device.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Jun 2001 14:59:59 -0700 (PDT)

> guess whether it should use the key for 802.11 over the air security, securing

The NAS-Port-Type has been traditionally used by the AAA server in order
to determine what keying material to provide. However, this may not be
granular enough. For example, a NAS-Port-Type=802.11 can today do only WEP
v1.0, but in the future might also be capable of doing WEP2, AES/OCB, etc. 

So I think it might make sense to have a NAS-Ciphersuite AVP that could
encode the various security mechanisms the NAS is capable of implementing:

          PPP DES
          PPP 3DES
          PPP MPPE
          802.11 WEP
          802.11 WEP2
          802.11 AES/OCB

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 3 Jun 2001 23:53:03 +0300

> v1.0, but in the future might also be capable of doing WEP2, AES/OCB, etc. 

I think we need to separate three issues clearly here. One, several
authentication methods provide session keys as a side effect in
their operation. Second, home aaa servers may wish to dictate
policy that some (or specific) sort of crytographic protection shall
be applied. Third, user devices and e.g. NASes have certain
capabilities which generally aren't the same in all the devices.

As we discuss the AVPs necessary for the KDC to operate, we need
to decide which of the above three aspects we are really looking at.
Are we making the home aaa server the ultimate policy server? In
that case it needs to deliver a lot of information regarding how the
desired protection scheme is run, and with which parameters. This
may not be easy in all cases. If the home AAA server delivers keys
and dictates that WEP2 shall be applied, the particular NAS the
user is on today might not support that. For this reason it is necessary
to do what Bernard suggests, either look at the NAS-Port-Type or
the NAS-Ciphersuite AVP, and therefore have the aaa server get
more information on this. However, even this may not be enough, as
the user device might also have some limitations in this respect.
In some cases such information would be available, such as in the
following: I think the 3GPP intends to use a new header field in SIP
to deliver protection scheme capability information in the REGISTER
messages. On some other cases this might not be available, such
as in PPP we can't easily (?) ask the peer if they can do encryption without
turning it on at the same time.

Another way to look at this is to consider the home AAA server
just as a provider of the keying material, and leaving the actual
selection of schemes to the NAS and the user device. For instance,
on PPP links we can negotiate the use of PPP encryption. Or on
802.1x systems Key Descriptor Frame contains an indication of
which scheme should be run. Specific application protocols may
have their own schemes, such as in the SIP example I gave above.
How the actual selection is done, what the alternatives are and so
forth would be left to the particular access type or application definitions,
such as the 802.1x documents. Benefits of this approach include
simplicity and the main drawback is the possibility that weaker security
than desired by the home aaa server could be applied (but that could
be dealt with by having the clients require a certain level by themselves).

What shall we do, then? I would say this depends on how much
we are required to do. I personally feel that the just-keying-material
approach is sufficient, and the user/NAS can handle the rest. But
I'm willing to be convinced otherwise...

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Jun 2001 07:23:30 -0700 (PDT)

> Are we making the home aaa server the ultimate policy server? 

In most cases, the client and NAS negotiate the level of cryptographic
protection. For example, in PPP we have ECP; in 802.11 we have beacon and
association messages. There are cases where the NAS may
not be aware of what ciphersuite has been negotiated --  when the
negotiation occurs between the client and AAA server, such as in RFC
2716. 

In this case, the AAA server informs the NAS as to what
ciphersuite has been negotiated with the client. Similarly with keying --
the AAA server informs the NAS of the key that has already been negotiated
with the client via an EAP key deriving method. Calling the AAA server
"KDC" can be confusing -- because such a KDC may exist somewhere else in
the system  (as when Kerberos is being used within EAP). In all of this it
is really the EAP method that is doing the keying, and ciphersuite
negotiation, not the AAA server. 
 
I think that it would be helpful if this architecture could be
explained somewhere. Otherwise, people are likely to get confused by the
terminology.  

> If the home AAA server delivers keys
> and dictates that WEP2 shall be applied

WEP2 would probably  be negotiated between client and NAS, in which case
the AAA server would be *told* what was negotiated. If for some reason it
did not like this (e.g. a better level of protection is required), then it
would send a REJECT message.  About the only time when the AAA server
would need to tell the NAS what to do would be if protected ciphersuite
negotiation is supported within the EAP method, as it is in RFC 2716. In
that case, the AAA server and client negotiate a method, and then this
method is reflected in subsequent negotiations between client and NAS
(e.g. ECP). Typically the NAS supports the right method because the AAA
server took this into account during the negotiation. 

> turning it on at the same time.

Doesn't ECP negotiation handle this? 

> which scheme should be run. 

The Key descriptor frame is used mostly for conveyance of multicast
keys, *after* the session key has been derived and is available to both
client and AP. So it is not used for ciphersuite negotiation. I believe
that the latest proposal is that this information be placed in Beacon and
Association frames. 

> I'm willing to be convinced otherwise...

Typically we will expect an unprotected ciphersuite negotiation
between client and NAS, in which case the AAA server only needs to be
informed of what has happened. However, there are cases in which protected
ciphersuite negotiation occurs between client and AAA server, in which
case the AAA server needs to tell the NAS what has been negotiated.

Note that since this architecture has been in use for several years now,
we have some prototypes of how this can be done. See RFC 2548 for
examples.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 10:32:24 -0700

OK, I think that I have a good handle on what is needed, and am proposing the following
text. I believe this addresses the issues that were raised (sorry, I couldn't come up
with a better name :(

PatC
----

2.1.7  NAS-Key-Binding AVP

   The NAS-Key-Binding AVP (AVP Code TBD) is of type Unsigned32, and
   specifies the purpose for the key. A Diameter client MAY include this
   AVP in a request to specify to the Diameter server the type of key it
   desires. This AVP MAY be present in a response from the Diameter
   server to inform the client of the type of key found in the NAS-
   Session-Key AVP. The following values are supported:

      PPP DES
         The key created is used to secure PPP links using DES [36]

      PPP 3DES
         The key created is used to secure PPP links using Triple DES
         [37]

      PPP MPPE
         The key created is used to secure PPP links using MPPE [38]

      802.11 WEP
         The key created is used to secure 802.11 links using WEP [x]

      802.11 WEP2
         The key created is used to secure 802.11 links using WEP/2 [x]

      802.11 AES/OCB
         The key created is used to secure 802.11 links using AES/OCB
         [x]

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 10:20:54 -0700

>           802.11 AES/OCB

Do you have references for these?

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 6 Jun 2001 00:43:47 +0300

>    Session-Key AVP. The following values are supported:

Looks good, just wanted to make sure we have a way to add new
enumerated values _when_ new protection schemes arrive. Do we?

Jari

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 4 Jun 2001 16:31:26 -0700

> enumerated values _when_ new protection schemes arrive. Do we?

ok, I should also have included the following:

11.5  NAS-Key-Binding AVP Values

   As defined in Section 2.1.7, the NAS-Key-Binding AVP (AVP Code TBD)
   defines the values 1-6. All remaining values, other than zero, are
   available for assignment via a Designated Expert [12].

PatC