Subject: [Capwap] Response to LWAPP Security Review

From: "Pat Calhoun" <[email-masked]>
Date: Fri, 13 May 2005 06:03:15 -0700

The co-authors of the LWAPP draft believe that security is of the utmost
importance for the working group, and therefore asked Charles to perform a
review of the draft-ohara-capwap-lwapp-02.txt specification. I would like to
personally thank Charles for his detailed analysis of the LWAPP protocol, as
well as the associated review document. I believe that his review further
strengthens the fact that the LWAPP protocol meets the security objectives
the co-authors had laid out for ourselves.
 
Charles mentioned that the PSK mode is cryptographically secure. On the
other hand, while the certificate based approach is practically secure,
Charles had some recommendations to also make it cryptographically secure. I
would like to respond to these recommended changes.
 
1. Add an additional round to perform explicit key validation.

LWAPP introduced an additional round in the join phase in the -02 draft, but
it is currently only used for the pre-shared key approach. We will modify
the certificate approach within the protocol to make use of this new round
to perform explicit key validation.

2. Increase size of SID to 128 bits to prevent replay attacks.

The Session Identifier is actually used in two ways. First, it is used to
uniquely identify a session during the key exchange. Second, the data
tunneling component of LWAPP uses the session id in its headers.
Unfortunately, increasing the session id size to 128 bits will unnecessarily
increase the overhead associated with the tunneling header. Therefore, after
careful consideration, we believe that the best approach is to in fact
increase the session id size during the key exchange, but clearly state
within the specification that only the least significant 32 bits are used in
the LWAPP data tunnel header.

3. Require AC certificates to contain an extended usage authorizing them to
provide AC services.

The authors have considered including a proposed X.509 certificate profile
in the specification for some time, but opted to leave it out until a future
version. However, Charles' comment makes it clear that including it within
the LWAPP specification is required in order to address this concern. In the
X.509 certificates we use today, we require that both the AP and the AC
include their LWAPP mode of operation (e.g., AC, WTP) to order to bind the
certificate to a role.

Charles also had the suggested change for encryption purposes:
4. Secure derivation of the initialization vector, at least by the AC, but
preferably by both the AC and WTP

Today, the WTP implicitely choses the IV through the Session Identifier. We
will make a change to allow the AC to select the most significant 64 bits of
the IV during the join phase.

Chales also mentioned the following suggestions to mitigate future attacks:
5. Perform key derivation based on exchanged entropy, rather than having the
AC push a key to the WTP

This is the mode of operation used for pre-shared key, and we will extend
this mechanism to the certificate based approach.

Finally, Charles recommends adding the following text:
6. Normatively RECOMMEND that LWAPP not be used with 802.11 WEP

There is nothing about LWAPP that causes WEP to be more vulnerable, but
Charles is recommending that a statement be included stating that WEP not be
supported on LWAPP ACs/WTPs. This is a note for implementers with the
understanding that there are many legacy devices in the field that only
support WEP and cannot be upgraded. Therefore, it may not be practical for
vendors to stop supporting WEP.

7. Add text stating that handoffs must be authenticated, for example by
requiring a successful 802.11 rekey before moving a session from one WTP to
another.

Again, this is an implementation issue, and the LWAPP document does not
include sufficient text in the delete mobile on when this to be issued
during a handoff. While the authors know how to implement this in a secure
fashion, Charles is right that a third party may not consider the
implications of sending the delete mobile prior to an authenticated handoff,
and therefore some additional text is warranted.

Once more, thanks to Charles for the great review.
 
I have a question for the chairs. Given that we initiated this review, I
would like to know if it would be possible to address these issues and
repost an updated version of the draft for consideration. I believe that it
is in the best interest of the Working Group, and the Internet Community, to
be working off a protocol that has had a security review.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

---

From: "Darren Loher" <[email-masked]>
Date: Mon, 16 May 2005 09:44:06 -0700

Agreed, we should leverage an existing protocol for authentication.  TLS
with a limited, minimum set (1 or 2?) of required ciphers sounds like a
good idea.  Additional ciphers should be optional.  Given the emergence
of WPA and 802.11i, it seems to make sense to leverage one/some of these
methods for the WTP <-> AC authentication.  

I also support that authentication be a requirement (MUST) of both the
WTP and AC.  Asymmetric ciphers should be allowed. 

--
Darren Loher
Senior Architect
Roving Planet  
http://www.rovingplanet.com
+1.303.996.7578

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Charles Clancy
> Sent: Monday, May 16, 2005 6:31 AM
> To: Agcaoili, Philip
> Cc: [email-masked]
> Subject: RE: [Capwap] Response to LWAPP Security Review
> 
> One problem with many of the standards-based authentication protocols
is
> that they often strive for flexibility rather than simplicity, making
them
> suboptimal for smaller devices, such as a thin AP.  Of course, that's
not
> to say they should all be disqualified.  IMHO, something like TLS
> authentication (similar to RFC 2716) would be good, with an
application
> profile limiting the ciphersuites to the following:
> 
>   * TLS_RSA_WITH_AES_128_CBC_SHA
>   * TLS_PSK_WITH_AES_128_CBC_SHA
> 
> This would allow for both PSK and public-key authentication, using
> standard protocols.
> 
> [ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
> [ computer science ]-----[ university of maryland | college park ]
> 
> 
> On Sun, 15 May 2005, Agcaoili, Philip wrote:
> 
> > This is great to hear.
> >
> > It also seems like we're adding complexity to this working group by
> > reinventing the wheel. Why bother fixing something that's been
solved
> many
> > times already? This working group should reusing other
standards-based,
> well
> > understood, and battle-proven methods such as IKE with IPSec or TLS
with
> > certificates?
> >
> > Thanks,
> >
> > Philip Agcaoili
> > Chief Security Architect
> > Enterprise Information Protection
> > Scientific-Atlanta, Inc.
> >
> > -----Original Message-----
> > From: Pat Calhoun
> > To: 'Agcaoili, Philip'; [email-masked]
> > Sent: 5/14/2005 12:12 AM
> > Subject: RE: [Capwap] Response to LWAPP Security Review
> >
> > Actually, I agree, and the issues raised in the review state that
the
> > specification needs to have clarifying text to ensure that other
> > implementations do things right. As I mentioned below, we will be
adding
> > such text to ensure that the document is very clear, minimizing the
> > possibility of 3rd party implementors being vulnerable to the issues
> > mentioned.
> >
> > Your voice is heard.
> >
> > Pat Calhoun
> >  _____
> > From: [email-masked] [mailto:[email-masked]]
On
> > Behalf Of Agcaoili, Philip
> > Sent: Friday, May 13, 2005 4:34 PM
> > To: [email-masked]'
> > Subject: Re: [Capwap] Response to LWAPP Security Review
> >
> >
> >
> > So to summarize, you appear to be saying that LWAPP security depends
> > from implementation to implementation of the draft.
> >
> > I'd like to be the voice of reason here and ask as a customer that
the
> > IETF specification is explicit enough to reasonably ensure that
every
> > implementation of the spec is secure.
> >
> > Thanks,
> >
> > Philip Agcaoili
> > Chief Security Architect
> > Enterprise Information Protection
> > Scientific-Atlanta, Inc.
> >
> >
> >
> > - - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
> > This e-mail and any attachments may contain information which is
> > confidential, proprietary, privileged or otherwise protected by law.
The
> > information is solely intended for the named addressee (or a person
> > responsible for delivering it to the addressee). If you are not the
> > intended recipient of this message, you are not authorized to read,
> > print, retain, copy or disseminate this message or any part of it.
If
> > you have received this e-mail in error, please notify the sender
> > immediately by return e-mail and delete it from your computer.
> >
> >
> >
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap