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

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Nov 2005 10:42:51 -0800

At the meeting in Vancouver, Sue Hares raised a question regarding
state machine coordination between DTLS and LWAPP. I must confess,
I didn't really understand what the issue was. Sue, do you think
you could explain your concern in a little more detail here?

Thanks,
-Ekr

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

---

From: "Darren Loher" <[email-masked]>
Date: Wed, 23 Nov 2005 08:08:16 -0800

Regarding 802.11r interactions, would it be appropriate at this point to
first finish a satisfactory mapping of DTLS to LWAPP?  

Then LWAPP could be updated with a description of behavior plus changes
(if any) for LWAPP to support 802.11r.  

-Darren

> -----Original Message-----
> From: Mani, Mahalingam (Mahalingam) [mailto:[email-masked]]
> Sent: Tuesday, November 22, 2005 12:18 PM
> To: T. Charles Clancy; Scott G Kelly
> Cc: [email-masked]
> Subject: RE: [Capwap] State machine issues with LWAPP over DTLS
> 
> 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 ]

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 23 Nov 2005 08:34:56 -0800 (GMT-08:00)

> T. Charles Clancy wrote: 
> 
> On Tue, 22 Nov 2005, Mani, Mahalingam (Mahalingam) wrote:
> 
>> Cryptographic strength protecting the channel should be higher or equal 
>> ... 
>> considered - PMK handed down to WTP to engage in 4-way handshake itself.
> 
> 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
>> 3.1?
> 
> 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.
> 

I agree with Charles. I think the best we can do is choose good defaults, have support for algorithms judged "adequate" with respect to key lengths vs cryptographic strength, and add some informative language to the security considerations sections. 

Scott

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Wed, 23 Nov 2005 10:23:34 -0700

Not sure whether it needs to be serialized. Perhaps it does.

-mani
======
-----Original Message-----
From: Darren Loher [mailto:[email-masked]] 
Sent: Wednesday, November 23, 2005 8:08 AM
To: Mani, Mahalingam (Mahalingam); T. Charles Clancy; Scott G Kelly
Cc: [email-masked]
Subject: RE: [Capwap] State machine issues with LWAPP over DTLS

-Darren

equal
itself.
section
in
this
with
we
fine.

---

From: Michael Montemurro <[email-masked]>
Date: Wed, 23 Nov 2005 11:51:11 -0500

I think the draft and presentation were a good start on looking at how to
apply DTLS to a CAPWAP protocol. 

Here is my view on what needs to be done next:
1) The current requirement for CAPWAP encryption on the control channel, not
the data channel. I think a bit more work needs to be done to clarify how
DTLS can be used to encrypt this control channel. In my mind, some of the
issues that need to be resolved are:
	a) What does the Discovery and Join mechanism look like with DTLS?
	b) What do the frame formats look like? Both the encrypted control
channel and unencrypted data channel.

2) Define positive and negative of Discovery/Join use cases and show how
DTLS will hold together.

3) Establish if data encryption on the data channel is necessary. If it is,
how should it be done?

My preference would be to treat the 802.11i and 802.11r issues
independently. There is already a proposed solution for how keys are
exchanged as part of the CAPWAP protocol, provided by LWAPP. We need to
establish that what's defined now is suffient for CAPWAP.

802.11r is in the process of defining requirements for the protocol for
exchanging keys between "key holders". Perhaps we could look at these
requirements to determine what would have to be done to address an 802.11r
solution.

Cheers,

	Mike   

> Sent: November 23, 2005 11:08 AM
> Regarding 802.11r interactions, would it be appropriate at 
> this point to first finish a satisfactory mapping of DTLS to LWAPP?  
> 
> Then LWAPP could be updated with a description of behavior 
> plus changes (if any) for LWAPP to support 802.11r.  
> 
> -Darren
> 
> 
> > 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.
> > 
> > 2. Is the 11i four-way handshake executed over DTLS 3. Are TKs 
> > distributed to APs over DTLS
> > 
> > going over DTLS.  We need to make sure there aren't any security 
> > concerns
> with
> > 
> > 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
> > [ t. charles clancy ]--[ [email-masked] ]--[ 
> www.cs.umd.edu/~clancy ] [ 
> > computer science ]-----[ university of maryland | college park ]