40 likes | 158 Vues
This document explores the need for effective authorization and authentication mechanisms for both PKI and PSK ciphersuites within the CAPWAP protocol. It highlights the inherent differences between certificates and pre-shared keys (PSKs) regarding identity handling, emphasizing the need for a unified approach that associates a MAC address with a domain for CAPWAP identities. While the pros include flexibility for ACLs and the ability to specify NULL domains, challenges arise from non-standard certificate handling and the necessity for a complex backend service to manage diverse identities.
E N D
DTLS Identities Charles Clancy 25 January 2007 CAPWAP Interim
Problem • Need to authorize and authenticate both PKI and PSK ciphersuites • Certificates by default have identites • PSKs do not • Need identity to do authorization • During PSK auth: • AC sends PSK_Hint • WTP sends PSK_Identity
Unified Approach • Approach: • CAPWAP_Identity = MAC @ DOMAIN • CN = CAPWAP_Identity (AC or WTP) • PSK_Hint = CAPWAP_Identity (AC) • PSK_Identity = CAPWAP_Identity (WTP) • Pros: • Can do ACLs like (* @ DOMAIN) • Can specify NULL domain (mfgr provisioned certs) • Problem: • Not normal cert handling (O/OU specify domain) • Network-wide PSKs – need mapping on AC for all WTPs
Split Approach • Certs • CN = MAC • O/OU = Administrative Domain • PSKs Identity and Hint • Some preformatted key name • Maybe KeyName = Hash(PSK || “CAPWAP PSK”) • Leave unspecified • Provision key name with the PSK • Drawback • Need more complex back-end authorization service to handle multiple different types of identities