Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation

From: Inderpreet Singh <[email-masked]>
Date: Thu, 18 Aug 2005 12:16:29 -0400

Charles,

Thanks for the clarification. That was exactly my point of view.  However,
during the meeting when I asked for a clarification of the following two
bullets in the Eval Team's presentation, I was explained that it means the
ability for one side to authenticate the other, but not necessarily
vice-versa.  Which is hybrid or non-mutual.  

Taken from slide 8 (CTP Evaluation Summary)of the CAPWAP eval team
presentation at IETF63:

"Compliance notes
- Only one authentication and encryption method without ability to extend
methods
- Precludes ability to perform asymmetric authentication"

In essence it was our understanding that mutual is REQUIRED, public-key or
pre-shared SHOULD be supported.  We (CTP) chose to support mutual
authentication through public-key crypto.  So why did we not meet the
objective?

---
Inderpreet Singh

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Thursday, August 18, 2005 11:58 AM
To: Inderpreet Singh
Cc: [email-masked]
Subject: Re: [Capwap] CAPWAP eval team - CTP evaluation

> 5.1.8 Protocol Security
>               
> The support for asymmetric authentication within the CAPWAP protocol was
> deemed mandatory by the evaluation team in order to receive a Compliant
> indication.  In the context of the CAPWAP protocol, asymmetric
> authentication refers to the presence of a mechanism, within the protocol,
> to allow the WTP and the AC to conduct different types of authentication. 
> For example, the WTP can authenticate the AC by the presence of a duly
> signed digital certificate, whereas the AC would authenticate the WTP
based
> on the presence of a pre-shared key. 

Asymmetric authentication simply means public-key authentication.  What 
you are refering to is hybrid authentication.  The term derives as the 
antithesis of "symmetric-key crypto".  It's symmetric because both people 
use the same key -- i.e. PSK.  Not using shared key implies asymmetric, or 
public-key authentication.

The CAPWAP requirements are that a shared-key and a public-key mode should 
both be supported, although the verbage is a bit awkward.

> This also implies that the authentication may not necessarily be 
> mutual.  That is, both sides don't necessarily have to authenticate each 
> other. 

No it doesn't.  Mutual authentication is orthogonal to public vs private 
key.

> For example, LWAPP provides for mutual certificate based authentication 
> OR mutual pre-shared key based authentication.  It does not provide for 
> the ability for a non-mutual authentication where one side does not 
> authenticate the other.

As it should.  The group has already agreed that mutual authentication is 
REQUIRED.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Michael Montemurro <[email-masked]>
Date: Thu, 18 Aug 2005 15:30:08 -0400

Behcet,

> With my eval team member hat off,
> can I ask how appropriate/feasible/good SNMP would be for 
> Split MAC WTPs?
> CTP's use of SNMP stems originally from managing legacy Local 
> MAC WTPs. 
> Can one easily extend it to Split MAC WTPs?
> The use of SNMP versus CAPWAP had been discussed earlier in 
> this mailing list but I forgot what was the conclusion, if any?
> Regards,
> --behcet

Since the split MAC functions are simply a subset of the entire MAC
functions, SNMP OID's can still be used to configure WTP's operating in
split MAC modes.

CTP specifies using SNMP OID's for configuration to improve the
extensibility of the protocol. Each IEEE 802 MAC standard includes SNMP OIDs
for configuration. CTP uses SNMP in its configuration message payload to
configure the WTP's.  Therefore IEEE standards already define the
configuration interface.

The only downside to using SNMP OID's is that you need to deal with ASN.1
encoding.

As new amendments to IEEE 802 standards become available, the CTP protocol
remains the same and picks up new OID's that are specified as part of the
amendment.

Personaly, I would not in favour of using the SNMP protocol for
configuration because it makes the state management of the AC and WTP much
too complex. It would mean that you would require a separate channel for
configuration versus control.

Cheers,

	Mike