Doc.: IEEE 802.11-02/401r0 Submission July 2002 T. Hardjono, VeriSignSlide 1 Certificate Hierarchy...

July 2002

T. Hardjono, VeriSignSlide 1

doc.: IEEE 802.11-02/401r0

Submission

Certificate Hierarchyfor the WLAN Industry

Thomas HardjonoVeriSign

[email protected]

July 2002


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


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


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


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


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


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


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


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


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


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


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


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


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

July 2002


doc.: IEEE 802.11-02/401r0

Submission

END+

Questions

Doc.: IEEE 802.11-02/401r0 Submission July 2002 T. Hardjono, VeriSignSlide 1 Certificate Hierarchy...

Documents

Transcript of Doc.: IEEE 802.11-02/401r0 Submission July 2002 T. Hardjono, VeriSignSlide 1 Certificate Hierarchy...