Certficate Extensions and Attributes Supporting Authentication in PPP and Wireless LAN Daniel Schwarz
Overview: 1. Introduction I. PKIX 2. Basics I. PPP II. EAP III. 802.1x IV. X.509 certificate extensions 3. PKIX Internet Draft certificate extensions and attributes supporting authentication in PPP and wireless LAN I. EAP extended key usage values II. WLAN SSID Public Key Certificate Extension III. WLAN SSID Attribute Certificate Attribute 4. EAP & 802.1x I. EAPOL II. EAP-TLS III. Alternatives 5. Conclusion 2/ 35
1.1 PKIX established in 1995 intent of developing Internet standards needed to support an X.509-based PKI the scope of PKIX work has expanded beyond this initial goal PKIX not only profiles ITU (International Telecommunication Union) PKI standards, but also develops new standards apropos to the use of X.509- based PKIs in the Internet. 3/ 35
2. Basics 4/ 35
2.1. PPP standard-method for communication between two hosts most commonly used for dial-up internet access part of the Layer 2 Tunneling Protocol integrated error correction compression of the IP-header LCP (link configuration protocol): responsible for the configuration, for the establishment and the clearing of a PPP-connection 5/ 35
2.2. EAP sits inside of PPP s authentication protocol provides a generalized framework for several different authentication methods does not select a specific authentication mechanism at Link Control Phase (LCP) but rather postpones this until the Authentication phase -> this allows the authenticator to request more information before determining the specific authentication mechanism 6/ 35
2.2. EAP three communication steps: a) after the Link Establishment phase is complete, the authenticator sends one or more Requests to authenticate the peer - examples of Request types: Identity, MD5-challenge, One-Time Passwords, Generic Token Card, b) the peer sends a Response packet in reply to each Request c) the authenticator ends the authentication phase with a Success or Failure packet 7/ 35
2.2. EAP a) Link Establishment LCP-packets peer authenticator b) Request phase 1..n Requests peer authenticator 8/ 35
2.2. EAP c) Response phase 1..n Responses peer authenticator d) End of authentication peer success or failure packet authenticator 9/ 35
2.2. EAP advantages: multiple authentication mechanisms without having to pre-negotiate a particular one during LCP phase certain devices do not necessarily have to understand each request type and may be able to simply act as a passthrough agent for some kind of back-end server on a host disadvantages: PPP implementation needs to be modified focus on authenticating a peer to an authenticator: -> the peer doesn t request any authentication from the authenticator -> EAP-TLS 10 / 35
2.3. 802.1x enables authenticated access to IEEE 802 media (Ethernet, Token Ring, 802.11 WLAN, ) RADIUS support is optional but it is expected that many IEEE 802.1x Authenticators will function as RADIUS clients provides network port authentication for IEEE 802 media (including Ethernet, WLAN, ) -> port-based network access protocol standard for passing EAP messages over LAN or WLAN EAP messages are packed in Ethernet frames without using PPP used in situations where other protocols than TCP/IP are needed or the overhead and complexity of using PPP is undesirable 11 / 35
2.3. 802.1x three important terms: 1.) supplicant: user or client that wants to be authenticated 2.) authentication server: actual server doing the authentication 3.) authenticator: device in between authenticator can be simple and dumb -> ideal for WLAN access points (little memory and processing power) the protocol in 802.1x is called EAP encapsulation over LANs (EAPOL) it is defined for Ethernet-like LAN (802.11 WLAN, Token Ring, ) different modes of operation (the most common one acts as follows) 12 / 35
2.3. 802.1x a) EAP-Request/ Identity-packet authenticator supplicant authentication server b) EAP-Response/ Identity-packet EAP-Response/ Identity-packet authenticator supplicant authentication server 13 / 35
2.3. 802.1x c) challenge challenge authenticator supplicant authentication server d) challenge reply challenge reply authenticator supplicant authentication server 14 / 35
2.3. 802.1x e) success success authenticator supplicant authentication server f) access supplicant 15 / 35
2.4. X.509 X.509 is an ITU standard for PKI (Public Key Infrastructure) X.509 specifies, amongst other things, standard formats for public key certificates X.509 is part of the hierarchical X.500 standard and thus assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates X.509 usually refers to the X.509 v3 certificate specified in RFC2459 16 / 35
2.4. X.509 - certificate extensions the extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys it is also allowed for communities to define private extensions to carry information unique to those communities each extension in a certificate is specified as either critical (system must reject the certificate if it doesn t recognize the extension) or non-critical (system may ignore the extension) 17 / 35
2.4. X.509 - certificate extensions key usage extension: defines the purpose of the key contained in the certificate should be marked critical extended key usage extension: this extension indicates one or more purposes for which the certified public key may be used it is used in addition or in place of the basic purpose indicated in the key usage extension may be marked critical or non-critical 18 / 35
2.4. X.509 - certificate extensions predefined values in RFC 3280: id-kp-serverauth OBJECT IDENTIFIER ::= { id-kp 1 } -- TLS WWW server authentication -- Key usage bits that may be consistent: digitalsignature, -- keyencipherment or keyagreement id-kp-clientauth OBJECT IDENTIFIER ::= { id-kp 2 } -- TLS WWW client authentication -- Key usage bits that may be consistent: digitalsignature -- and/or keyagreement id-kp-codesigning OBJECT IDENTIFIER ::= { id-kp 3 } -- Signing of downloadable executable code -- Key usage bits that may be consistent: digitalsignature 19 / 35
2.4. X.509 - certificate extensions predefined values in RFC 3280: id-kp-emailprotection OBJECT IDENTIFIER ::= { id-kp 4 } -- E-mail protection -- Key usage bits that may be consistent: digitalsignature, -- nonrepudiation, and/or (keyencipherment or keyagreement) id-kp-timestamping OBJECT IDENTIFIER ::= { id-kp 8 } -- Binding the hash of an object to a time -- Key usage bits that may be consistent: digitalsignature -- and/or nonrepudiation id-kp-ocspsigning OBJECT IDENTIFIER ::= { id-kp 9 } -- Signing OCSP responses -- Key usage bits that may be consistent: digitalsignature -- and/or nonrepudiation 20 / 35
3. PKIX Internet Draft certificate extensions and attributes supporting authentication in PPP and wireless LAN 21 / 35
3.1. EAP extended key usage values new values from the Internet Draft: 1) id-kp-eapoverppp OBJECT IDENTIFIER ::= { id-kp 13 } indicates that the certified public key is appropriate for use with EAP in the PPP environment 2) id-kp-eapoverlan OBJECT IDENTIFIER ::= { id-kp 14 } indicates that the certified public key is appropriate for use with EAP in the LAN environment -> inclusion of both values indicates that the certified public key is appropriate for use in either of the environments 22 / 35
3.2. WLAN SSID Public Key Certificate Extension always non-critical contains a list of SSIDs more than one certificate includes an extended key usage extension indicating that the certified public key is appropriate for use with the EAP in LAN environment -> the list of SSIDs MAY be used to select the correct certificate for authentication in a particular WLAN SSIDs are unmanaged -> the same SSID can appear if different certificates that are intended to be used with different WLANs -> user-input or trial-and-error 23 / 35
3.3. WLAN SSID Attribute Certificate Attribute What to do when the PK certificate does not include the WLAN SSID certificate extension? -> use of an attribute certificate acts the same way as the extension contains a list of SSIDs can be used to select the correct certificate 24 / 35
4. EAP & 802.1x 25 / 35
4.1. EAPOL (802.1x) steps c) and d) authentication server challenging the peer c) challenge challenge authenticator supplicant authentication server d) challenge reply challenge reply authenticator supplicant 26 / 35 authentication server
4.2. EAP-TLS - mutual authentication a) EAP-Request/ Identity-packet authenticator peer EAP server b) EAP-Response/ Identity-packet EAP-Response/ Identity-packet authenticator peer EAP server 27 / 35
4.2. EAP-TLS - mutual authentication c) EAP-Request (TLS Start) peer EAP server d) EAP-Response (TLS client_hello) peer EAP server 28 / 35
4.2. EAP-TLS - mutual authentication e) EAP-Request (TLS server_hello, TLS certificate, TLS certificate_request TLS server_hello_done) peer EAP server f) EAP-Response (TLS certificate, TLS client_key_exchange, TLS finished) peer EAP server 29 / 35
4.2. EAP-TLS - mutual authentication g) EAP-Request (TLS finished) peer EAP server h) EAP-Response (TLS) peer EAP server 30 / 35
4.2. EAP-TLS - mutual authentication i) EAP-Success peer EAP server 31 / 35
4.3. EAP-Alternatives EAP-MD5: Lets a RADIUS server authenticate LAN stations by verifying an MD5 hash of each user s password LEAP (Lightweight EAP): Cisco s solutions goes a notch beyond EAP-MD5 by requiring mutual authentication and delivering keys used for WLAN encryption EAP-TTLS and PEAP: Have been proposed to simplify 802.1x development. Both require certificatebased authentication only for the RADIUS server. In addition an extensible set of different user authentication methods is offered 32 / 35
5. Conclusion 33 / 35
5. Conclusion EAP-TTLS and PEAP are not yet finalized (Internet Drafts) EAP-MD5 and LEAP are simple but not that safe EAP & 802.1x has a huge effort with the administration of public keys for the users EAP & 802.1x is currently the best way to protect your WLAN via the EAP protocol 34 / 35
Thank you for your attention! 35 / 35