Subject: RE: [Capwap] State machine issues with LWAPP over DTLS

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Tue, 22 Nov 2005 12:18:19 -0700

Cryptographic strength protecting the channel should be higher or equal
to the cryptographic strength of the transported key material which

1. in one mode will be the PTKs (where AC performs the 4-way handshake
as the NAS)
2. there may be another mode - I am not sure whether it is to be
considered - PMK handed down to WTP to engage in 4-way handshake itself.

Therefore - the recommended/required DTLS ciphersuite subset will need
to be specified accordingly - as per section 3.1 of Scott & Eric's -00
draft. Is that intent going to be elaborated in next revision in section
3.1?

It would also be useful (IMHO necessary) to describe CAPWAP behavior in
the context of the (in-progress) TGr (802.11r) fast BSS-transition
enhancements that impact the (security considerations of) AP-backend
considerably.

-mani
======
-----Original Message-----
From: T. Charles Clancy [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2005 7:45 AM
To: Scott G Kelly
Cc: [email-masked]
Subject: Re: [Capwap] State machine issues with LWAPP over DTLS

>> If you want to support key distribution, please add additional
>> information to the draft. 
>
> I'm not sure I understand which keys you are referring to. The keys 
> distribued in your diagram are for the lwapp session itself, and this
is 
> taken care of entirely by DTLS as part of the handshake.

I think there are a few issues here:

1. Is EAP executed over DTLS
2. Is the 11i four-way handshake executed over DTLS
3. Are TKs distributed to APs over DTLS

IMHO, (1) and (2) are simply data packets, and should go over the 
unencrypted data channels.  These packets already have sufficient 
cryptographic protection, in that they are authentication protocols 
expected to be executed over a plaintext channel.

However (3) is part of the LWAPP control protocol.  Thus, it will be
going 
over DTLS.  We need to make sure there aren't any security concerns with

sending these keys unencrypted (sort of) over DTLS.  First of all, if we

were going to provide additional crypto, we'd need to get 
application-layer keys from somewhere.  DTLS doesn't provide them, so
we'd 
need to drive them (yuck).  Fortunately, I really don't think they're 
necessary.  DTLS provides all the security we need for key transport.
As 
long as we don't treat DTLS as a modular transport layer, we'll be fine.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: "T. Charles Clancy" <[email-masked]>
Date: Wed, 23 Nov 2005 10:58:42 -0500 (EST)

On Tue, 22 Nov 2005, Mani, Mahalingam (Mahalingam) wrote:

> ... 

This is not a good mode.  It prevents secure roaming between APs.  If you 
roam through a compromised AP, that AP would be able to then compromise 
all your past and future sessions that use the same PMK.  You'd have to do 
a new EAP authentication to get a new PMK at every AP to be secure.

> draft. Is that intent going to be elaborated in next revision in section

Equating ciphersuite security can be a little tricky.  For example, the 
PMK provided by EAP is 256 bits long.  It's used to generate either a 
128-bit AES key or 256-bit TKIP key.  Should the DTLS ciphersuite then be 
256-bit secure to cover the TKIP case?  If EAP-TLS with 1024-bit RSA certs 
is used to generate the PMK, the security can be quantified somwhere 
around 80 bits, so 256 bits is overkill.

I guess my suggestion is that we pick a key strength that we thing is 
sufficient, because we have no way of controlling whether people use 
512-bit RSA keys or 8096-bit RSA keys underneath.  IMHO, 128-bit security 
seems reasonable.  Supporting 256-bit security would probably be a good 
thing.  Supporting FIPS 140-2 certified ciphersuites would probably also 
be a good thing.