Capwap Mailing List: Re: Certificates, Discovery Request/Reply, and validation.

[Alper Yegin (alper]

>>>         For phase2:
>>>               PANA seems to be defining physical/link layer independent
>>> authentication mechanism.
>>>               That might be suitable here. Comments?
>> 
>> In the current deployments the security between the AP and AR relies on
>> physical measures. As I understand, we don't want to make this assumption in
>> here. In that case, yes, PANA can be used for authentication and
>> authorization between the APs and ARs. By using an appropriate EAP method
>> (e.g., EAP-TLS) cryptographic keys can be produced that are used to
>> establish a protected channel between AP and AR. This ensures all the
>> signaling and data traffic is secured.
> 
> So how does the AP know that 802.1x will be required for a given mobile? How
> does the AP get the 802.1x keys that it must use with the mobile? How does the
> AR handle load balancing? How does the AR handle 802.11e and 802.11i, or
> should the AP do it? What about 802.11h? What about 802.11k?

What does any of these have to do with what we are talking about here:
establishing trust and a secure channel between the AP and AR.


> 
> You see, the PANA architecture really only touches the tip of the iceberg.
> Moving towards a LWAPP architecture solves these issues, and significantly
> reduces the amount of protocol work required between the AP and the AR
> (because 802.11 terminates in the AR, so 802.11 *is* the protocol).

I'm not comparing PANA with LWAPP. This does not make sense. LWAPP is more
like an architecture that tackles several problems. I'm trying to understand
what each one of these problems are and see if there are alternative
solutions that should be considered.

PANA comes into the picture when we talk about the AAA between hosts and AR,
and AA_ between the AP and AR. I don't see PANA's relevance to all the other
bells and whistles LWAPP provides.

> 
> We seem to be focused on EAP only, but again, I think the problem is much
> greater in scope - hence CAPWAP.
> 

Is there a documented list of problems, like a problem statement? It is
really hard to reverse engineer the LWAPP to undertsand the problems we are
solving here.

Alper