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

[Pat R. Calhoun (pcalhoun]

> If the operators want a client-less solution, they can stay with web-based
> login hackery (is there any alternative??). Obviously this is not adequately
> secure, and they will have to move on. Any reasonable wireless security
> requires client support.
> 
> As for IPsec and PANA, one more time, PANA does not mandate you to use the
> keys with IPsec. You can use them with link-layer ciphering. For example,
> you can bootstrap your WEP keys (legacy network) using PANA.

These are PANA discussions and belong in the PANA mailing list. Let's stop this 
please.
 
>> Ah - so change the PANA charter to solve the CAPWAP problem?
>
> Why? We are not going to update the charter each time we realize where PANA
> can be used.

Unfortunately (or fortunately) that's the way things work in the IETF. You 
can't just change your WG direction (or start tackling new problems) without a 
charter change, but again, this is a topic for the PANA WG so let's leave this 
alone.

> If this is the 
> PANA architecture, then it should be clear, because so far, it has not been.

> PANA is a protocol, not an architecture. You can use it in any architecture
> you like, as long as you follow the protocol design. If you want to see
> mention of using keys with L2 ciphers, please read the latest Problem
> Statement and Usage Scenarios draft.

I did (just now) and CAPWAP & PANA are two COMPLETELY different problem spaces. 
So let's let this one die too.


>> How would you coordinate the session keys
>> between the devices? etc, etc, etc.
>
> Please explain what keys, what devices, what is the problem ???

I think it may be a good idea to read the draft.

PatC