Subject: RE: [Capwap] IEEE Review 13 - Protocol security

From: "Darren Loher" <[email-masked]>
Date: Thu, 2 Jun 2005 17:50:52 -0700

Perhaps we can break this up into two parts:
1. day-one install 
2. on going operations 

The desire to have an easy, zero-touch day-one install does not have to
preclude mandatory support for mutual authentication.  Perhaps we should
permit a "null" authentication method of the AC to be used for
installation purposes.   

After the AC and WTP discover each other via whatever method, as part of
the first time configuration process the AC can instruct the WTP to
perform authentication of the AC using a better method of the
administrator's (the AC) choice.  This would allow an automated,
zero-touch installation approach which enables a "good" mutual
authentication method for post-install operations.  This minimizes risk
of rogue AC to the WTP's install process.  

Do we think think mutual auth is still worthy even with an install time
risk like this?

-Darren
ps: Dan, your internet key draft is as funny as a draft about key
exchange can be  :)

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Thursday, June 02, 2005 12:59 PM
> To: Darren Loher
> Cc: Saravanan Govindan; [email-masked]
> Subject: Re: [Capwap] IEEE Review 13 - Protocol security 
> 
>   Darren,
> 
>   The man-in-the-middle attacks you describe would not work 
> if 802.11i was used. If it wasn't then these attacks can 
> still be mounted by configuring a generic cutrate AP, forget 
> CAPWAP. It would not be possible to capture the STA's 
> passwords because the STA authenticates the AS prior to 
> devulging her passwords and she would not authenticate a rogue AS.
> 
>   Regarding the idea of loading a standard pre-shared key at 
> the factory keep in mind that CAPWAP must be interoperable by 
> different vendors so all vendors would have to use the same 
> pre-shared key. Therefore let me refer you to the following 
> (unfortunately now expired) Internet Draft:
> 
> 	http://www.lounge.org/draft-ietf-ipsec-internet-key-00.txt
> 
> I recommend reading the entire draft, it's pretty short, but 
> check out the "Security Considerations" section. Then check 
> out the date. 
> 
>   For what it's worth I know of one company that shipped 
> product that used that for authentication purposes as the 
> "default pre-shared key" so there is precedense!
> 
>   Dan.
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Paul Lambert" <[email-masked]>
Date: Fri, 3 Jun 2005 10:11:32 -0700

I be believe mutual authentication 'must' be a requirement.  It's easy
to change mutual authentication to one-sided, by difficult to do the
reverse. 

Paul 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Clancy
> Sent: Friday, June 03, 2005 8:42 AM
> To: Matt Holdrege
> Cc: Dan Harkins; Darren Loher; Saravanan Govindan; [email-masked]
> Another option might be SSH-style security.  The WTP could be 
> preprogramed with a self-signed cert.  The public key could 
> be saved on the AC. 
> During the first authentication, the WTP saves the AC's public key. 
> During later authentications, the WTP just verifies the AC's 
> public key matches the saved one.
> 
> Maybe we could allow non-mutual authentication during a 
> provisioning phase, but require it afterwards?  Matt brings 
> up a good point -- do we want these mutual authentication 
> requirements to be supported by the protocol, or required by 
> the protocol?
> 
> [ t. charles clancy ]--[ [email-masked] ]--[ 
> www.cs.umd.edu/~clancy ] [ computer science ]-----[ 
> university of maryland | college park ]
> 
> 
> On Thu, 2 Jun 2005, Matt Holdrege wrote:
> 
> > Can I ask a silly question? Why can't the vendors of WTP's 
> include the 
> > ability to input a shared key? The default could be no 
> mutual authentication.
> > And if people want security, they can input a key. Let the 
> AC vendor 
> > also give their customers the choice of accepting trusted 
> or un-trusted WTP's.
> >
> > Remember that we are developing a *protocol* here, rather 
> than a set 
> > of products. So the CAPWAP protocol MUST support mutual 
> > authentication. We are not saying products MUST support this and we 
> > are absolutely not saying that end users MUST use mutual auth.
> >
> > -Matt
> >
> >