doc.: ieee 802.11-02/401r0 submission july 2002 t. hardjono, verisignslide 1 certificate hierarchy...
Post on 19-Dec-2015
218 views
TRANSCRIPT
July 2002
T. Hardjono, VeriSignSlide 1
doc.: IEEE 802.11-02/401r0
Submission
Certificate Hierarchyfor the WLAN Industry
Thomas HardjonoVeriSign
July 2002
T. Hardjono, VeriSignSlide 2
doc.: IEEE 802.11-02/401r0
Submission
Introduction• Informational presentation• Topics:
– Uses of certificates in WLAN context– Certificate-based roaming across WISPs
• Not a new idea, but WLAN-specific details need to be worked-out
– Possible certificate hierarchy for WLAN industry
• Non-topics:– “…PKI does not exist…”– Trust models
• hierarchical, flat, web-of-trust, bridges, etc.
– Certificate structures: • X509, PGP, SPKI, etc.
July 2002
T. Hardjono, VeriSignSlide 3
doc.: IEEE 802.11-02/401r0
Submission
Some Context• WISPr
– Best Common Practice (BCP) document– Universal Access Method (UAM)
• Recent TGi discussion on Side Channels• Recent WLAN certificate extensions idea:
– draft-ietf-pkix-wlan-extns-00.txt (Housley/Moore, 2002)
• Cert-based roaming in the IETF RoamOps WG:– draft-ietf-roamops-cert-02.txt (Aboba, 1999)
• Increasing public interest:– EAP-TLS in WinXP & Radius servers
• “What’s a EAP-TLS certificate”
– SSL-certs for UAM & other browser-based– IPsec VPNs
• since “WLANs are insecure”
July 2002
T. Hardjono, VeriSignSlide 4
doc.: IEEE 802.11-02/401r0
Submission
Motivations & Questions• Certificates needed/useful in various scenarios:
– Server-certs for UAM and for cert-based EAP methods– Client and server certs for cross WISP roaming– Enterprise WLAN access– Side Channels– Device certificates (e.g. laptops, NICs, APs)– AP-to-AP authentication (future?)
• If public key cryptography is used for authentication:– then for scalability, certificates will be needed– Some initial questions:
• Who is going to issue them (i.e. who will be the CAs)• How do certificates get distributed (client & server side)• How do certificates get validated and revoked
• Authentication vs. Trust
July 2002
T. Hardjono, VeriSignSlide 5
doc.: IEEE 802.11-02/401r0
Submission
Precedence
• CableModem industry under CableLabs– All DOCSIS1.2 compliant CableModems carry an
embedded device certificate:• SubjectName is device-ID/serial-number• Used by Head-End (i.e. operator) to authenticate modem• Allows user to buy/own & move modem to new residence
• CableLabs is Root Certificate Authority (CA):– Two subordinate CAs under CableLabs
• Manufacturer CA and Operator/MSO CA
– Each manufacturer obtains:• Code-signing cert and Certificate-Issuance cert
– Manufacturer is the device-cert issuer:• Unique device-cert for each of its modems
July 2002
T. Hardjono, VeriSignSlide 6
doc.: IEEE 802.11-02/401r0
Submission
Certificates: Benefits & Drawbacks• Benefits:
– Can be associated with users or laptops/devices– Extensible:
• Can add WLAN-specific extensions• Can carry NAI information• Can carry authorization information
– e.g. for authorization query to corporate AAA server
– Strength• Builds on strength of public key crypto (e.g. RSA)
– Can be used to sign transactions – for billing
• Drawbacks:– PKI management
• Not difficult for PKI-enabled enterprises• Else can outsource
July 2002
T. Hardjono, VeriSignSlide 7
doc.: IEEE 802.11-02/401r0
Submission
WLAN Roaming: Cert Example• Scenario:
– WISP1 issues certificate to its User1– User1 roams to HotSpot of WISP2 running AAA2
server (e.g. EAP-TLS)
• Some basic questions:– How does WISP2 verify User1’s certificate
• Status checking
– How does WISP2 know how to route authorization request
– How does User1 know its truly AAA2, not some bogus AAA-server
– How does WISP1 revoke User1’s certificate
July 2002
T. Hardjono, VeriSignSlide 8
doc.: IEEE 802.11-02/401r0
Submission
WLAN Roaming
WISPs CA
Internet
WISP1Domain
WISP2Domain
Trust-chain f romUser1 certif icateup to WISPs CA
WISP2 PAC/AAA serv eraccepts User1 certif icate
since they hav ea common root of trust(namely the WISPs CA)
RoamingUser-1
of WISP-1
AP #2
PAC#2(AAA #2)
AP #1
PAC#1(AAA #1)
CRL
CRL CRL
ConsortiumRoot CA
CRL
July 2002
T. Hardjono, VeriSignSlide 9
doc.: IEEE 802.11-02/401r0
Submission
Roaming Consortium• One-to-one roaming agreements don’t scale• Common organization needed to:
– Set basic operational standards in public places• Based on Wi-Fi certified equipment & technology• Provide common user-interface to users
– Provide billing resolution and presentation• Based on sound and expandable business model• Broker special agreements among W-ISPs, if desired
– Set clearinghouse standards for members• Be a clearinghouse or choose some existing ones
– Be the Root Certificate Authority (CA)• Build a “community of trust” for players in the industry• Facilitate cert-status checking (e.g. via OCSP or XKMS)
July 2002
T. Hardjono, VeriSignSlide 10
doc.: IEEE 802.11-02/401r0
Submission
WECA as a possible Root CAWECA
Root CA
Wi-Fi CA
Dev iceVendor #1
Dev iceVendor #2
Dev iceVendor #N
W-ISP#1 W-ISP#2 W-ISP#n
WISPr CA
July 2002
T. Hardjono, VeriSignSlide 11
doc.: IEEE 802.11-02/401r0
Submission
Example of Full Hierarchy
Wi-Fi CA
Dev iceVendor #1
Dev iceVendor #2
Dev iceVendor #N
NIC/STASerial#1pqr...
NIC/STASerial#1stv ...
APSerial#2xy z...
APSerial#2abc...
AAASerial#5cde...
AAASerial#5f gh...
WISPr CA
W-ISP #1 W-ISP #2 W-ISP #n
User#1-456AP
#1-678 PAC#1-765
User#2-456 AP#2-123 AAA
#2-897
User#n-123
User#n-456
WECARoot CA
July 2002
T. Hardjono, VeriSignSlide 12
doc.: IEEE 802.11-02/401r0
Submission
Certificate Enrollment/Distribution• Server-side:
– Issued by W-ISP as member of consortium• Server owned by W-ISP (e.g. server1.greatwisp.com)• Copies of all certs up the chain provided to client at client
cert enrollment/download
• Client-side:– Issued by WISP to individual subscribers or
corporate customers• Off-line (wireline) certificate enrollment preferred• First-timers at hotspot can be provided temporary IP
connectivity (similar to UAM) to cert enrollment pages• May be downloaded with SmartClient s/w download• W-ISP is the issuer of the client-cert• W-ISP can run internal PKI or outsource
July 2002
T. Hardjono, VeriSignSlide 13
doc.: IEEE 802.11-02/401r0
Submission
Certificate Verification• Certs exchanged as part of TLS handshake
– In EAP-TLS/TTLS, or other TLS-based
• By server:– Server assumed to have wireline connection– Remote server at HotSpot Verifies user cert by:
• Performing usual format & signature checking• Verify client-cert status by querying CRL at user’s home
WISP or at Consortium (via standard protocols)
• By client:– Has copy of WISP-CA cert & Consortium-CA cert
• Can verify that visited HotSpot W-ISP is member• But cannot immediately verify status of at server-cert
– Can verify once client has IP connectivity or via UAM
July 2002
T. Hardjono, VeriSignSlide 14
doc.: IEEE 802.11-02/401r0
Submission
Open Issues• Currently no global roaming consortium
– WECA/Wi-Fi performs compliance certification• WISPr is not a roaming consortium, though may be a seed for
one in the future
– PassOne model and direction still uncertain
• Lack of understanding of trust in the Internet– Lay users don’t understand the notion of “security”– Catchphrase “SSL protected” meaningless to many users
• Interface to certificate management and PKI:– Client-side: mainly browser-based
• Cert must then be exported out of browser
– Server-side: too many protocols (CMP, CMC, etc):• Convergence of PKI industry on XKMS for both client & server
• Other issues