Architectural Model and PKI Entities

Figure 1 shows a simplified view of the architectural model assumed by the PKI specification. This model is analogous to the credit card infrastructure. Even though the data is encrypted differently, the ways in which the entities in the two structures interact with each other are conceptually similar. Each PKI entity is like an entity in the credit card infrastructure.

 
Figure 1: PKI Entities and Their Relationships

We’ll now define the following PKI entities:

• End Entity User of PKI certificates and/or end-user system that is the subject of a certificate. Like a credit card reader in a retail store or restaurant, it reads a user certificate (credit card number) and queries the credit card company for the card holder’s legitimacy and credit limits.
• Certification Authority (CA) A system that issues PKI certificates. Think of credit card application processing, which checks an applicant’s credit history and issues a credit card.
• Registration Authority (RA) An optional system to which a CA delegates certain management functions.
• CRL issuer An optional system to which a CA delegates the publication of certificate revocation lists. This entity manages the equivalent of a stolen or lost credit card report and distributes certificate revocation information.
• Repository A system or collection of distributed systems that stores certificates and CRLs and that serves as a means of distributing these certificates and CRLs to end entities. An analogy would be a credit card holder database.

Operational protocols deliver certificates and CRLs (or status information) to client systems that use certificates. A variety of different ways to deliver certificates and CRLs are needed, including distribution procedures based on Lightweight Directory Access Protocol (LDAP), HTTP, File Transfer Protocol (FTP), and X.500.

Management protocols support online interactions between PKI user and management entities. For example, a management protocol might be used between a CA and a client system with which a key pair is associated, or between two CAs that cross-certify each other. The set of functions potentially needing to be supported by management protocols include user registration, client initialization, user certification, periodic key pair update, revocation request, and cross-certification.

Public Key Cryptography Concepts

Within the PKI framework, who you are is defined by the private keys you possess. From the point-of-view of PKI authentication authorities, you are your private key. In order to understand PKI, you will first have to understand some basic cryptological concepts. In Figure 1 the concept of a secret key is presented. Alice and Bob often are used as examples of the two parties engaged in a secure communications channel, and we will use them here. In this case, Alice and Bob both possess the same secret key. This can be a password, a token, or some other form of secret. Alice encrypts the plaintext that she wishes to send to Bob using her secret key. After Bob receives the ciphertext, he decrypts it using the same secret. The fact that the same key is used for both encryption and decryption determines that this is a symmetric exchange.

 
Figure 1: Symmetric Key Cryptography

PKI relies on a public/private key combination. The public and private keys are mathematical entities that are related. One key is used to encrypt information and only the related key can decrypt that same information; however, if you know one of the keys, it is computationally unfeasible to calculate the other. Your public key is something that you make public. It is freely distributed and can be accessed by everyone. A corresponding (and unique) private key is something that you keep secret. It is not shared with anyone. Your private key enables you to prove, unequivocally, that you are who you claim to be.

In Figure 2, Alice uses public key cryptography to send a ciphertext to Bob. She first locates Bob’s public key (normally from some type of directory service or from a previous secured document that Bob has sent to her) and encrypts the plaintext with Bob’s public key. She sends the encrypted text to Bob. Only Bob has the corresponding private key that can be used to decode the ciphertext.

 
Figure 2: Public Key Cryptography

Note that in normal practice, for performance reasons, the actual ciphertext is encrypted using a secret key algorithm as shown in Figure 1. Symmetric algorithms are much faster than public/private key algorithms (asymmetric cryptography). A random key (the session key) is generated, and it is used with the symmetric algorithm to encrypt the information. The public key is then used to encrypt that key and both are sent to the recipient. The private key is then used to decrypt the session key, and the resulting session key is used to decrypt the actual data.

The developers of public key cryptography were economical with keys. Both the public and private key are used for more than just encrypting and decrypting data or session keys. The private key also is used to digitally sign the sent message so that the sender’s identity is guaranteed. If the sender wishes to prove to a recipient that they are the source of the information (perhaps they accept legal responsibility for it), the sender uses his or her (or its) private key to digitally sign a message (a digital signature). Unlike a handwritten signature, a digital signature is different every time it is created. To create the digital signature, a hash of the message is signed (encrypted) with the sender’s private key The encrypted value either is attached to the end of the message or is sent as a separate file together with the message. The sender’s public key that corresponds to this private key may also be sent with the message, either on its own or as part of a certificate.

The receiver uses the sender’s public key to verify that the message hash calculated by the receiver (when certificates are used, the type of hashing algorithm will be included in the public key certificate sent with the message) is the same as the original hash. If the values match, the receiver is reasonably assured that the sender (the individual or device that owns the private key that corresponds with the public key) sent the information. The receiver also is reasonably assured that the information has not been altered since it was signed. This exchange forms the basis for two key security principles: nonrepudiation (the identity of the sender is verified) and message integrity (the contents of the message have not been altered in transit). Table 1 summarizes the intended use and owner of both public and private keys in public key cryptography.

Table 1: Key Usage in Public Key Cryptography 

Function	Key Type	Key Owner
Encrypt Data	Public Key	Bob (Receiver)
Sign Data	Private Key	Alice (Sender)
Decrypt Data	Private Key	Bob (Receiver)
Verify Data Integrity	Public Key	Alice (Sender)

MS-CHAPv2

MS-CHAP v2 is a one-way encrypted password, two-way authentication process that provides mutual authentication between peers (see Figure 1). It differs from MS-CHAP-V1 because it piggybacks an additional peer challenge (PCS) on the Response packet and an additional authenticator response on the Success packet. Both the authenticating server and the client challenge and authenticate each other. The message flow is as follows:

1. Authenticator sends a challenge consisting of a Session ID and random authenticator challenge string (ACS).
2. Client (peer) sends a response containing an encrypted one-way hash of the session ID, username, a peer challenge string (PCS), the peer response (PR), and the user password (secret).
3. Authenticator responds with another one-way hash (based on the client response) of a success/failure code, the authenticator response (AR), and the user’s password (secret).
4. The peer verifies the authenticator response and begins communications if the response is successful. It disconnects on failure.
   
   

 
Figure 1: MS-CHAP-V2

This authentication method depends upon a secret (password) known only to the authenticator and the peer. The secret is not sent over the link. A one-way hash function, also known as a message digest, is a mathematical function that takes a variable-length input string and converts it into a fixed-length binary sequence that is computationally difficult to invert—that is, generate the original string from the hash.

CHAP and MS-CHAP

CHAP was defined in RFC1994: PPP Challenge Handshake Authentication Protocol. CHAP (Challenge-Handshake Authentication Protocol) was initially used to verify client identity on PPP links using a three-way handshake. The handshake begins with the authenticator issuing a challenge to the client. The client responds with a digest calculated using a hashing function. The authenticator then verifies the response and acknowledges the connection if the match is successful, otherwise it terminates the connection. CHAP depends upon a secret known only to the authenticator and the client. The secret is not sent over the link.

MS-CHAP differs from CHAP in that MS-CHAP does not require that the shared secret be stored in cleartext at both ends of the link. The Microsoft client knows the hash method used by the server so it can reproduce it, effectively creating a “matching” password on both ends. The client proves its identity based on the fact that it can reproduce the hashed value of the password.

PAP

PAP (Password Authentication Protocol) is described in RFC1334. PAP provides a simple method for the peer to establish its identity using a two-way handshake. PAP is not a strong authentication method. Passwords are sent over the connection in cleartext and there is no protection from playback or repeated trial and error attacks.

MD5

MD5 (Message-Digest algorithm 5) is a widely used cryptographic hash function that results in a 128-bit hash value. The 128-bit (16-byte) MD5 hashes (also termed message digests) typically are represented as 32-digit hexadecimal numbers (for example, ec55d3e698d289f2afd663725127bace). EAP-MD-5 typically is not recommended for wireless LAN implementations because it may expose the user’s password, and because several collision-based weaknesses have been demonstrated. It provides for only one way authentication—there is no mutual authentication of wireless client and the network. And very importantly it does not provide a means to derive dynamic, per-session wired equivalent privacy (WEP) keys.

GTC

Typically, password (PIN) information is read by a user from a token card device and entered as ASCII text into the client. GTC is similar to PAP in that passwords are sent in the clear.

Notes from the Underground…—Dictionary Attacks

---

Passwords can be broken in real-time (active) and offline (passive) modes. The premise of a dictionary attack is that by trying every possible combination or words (or tokens), an attacker ultimately will succeed in discovering user secret passwords. A dictionary attack relies on the fact that d. password is often a common word, name, or concatenation of words or names with a minor modification such as a trailing digit or two, Longer passwords with a variety of characters (such as ^Y2o4uEA16r3-2e64A12EFing!) offer the greatest protection against dictionary attacks.

During an online dictionary attack, an attacker tries to actively gain network access by trying many possible combinations of passwords for a specific user. Online dic-tionary attacks can be prevented using password lockout mechanisms that lock out the user account after a certain number of invalid login attempts. Online attacks also generally show up in logs, which can indicate that this type of “loud” hacking activity occurred or is occurring. Offline attacks rely on the attacker’s ability to capture and record data from the datastream usually by using a sniffer such as tcpdump or ethereal. These captured data can then be compared at leisure against tables of hashes until a password ‘s discovered or the attacker gives up, The offline attacks can be thwarted by changing passwords regularly and limiting attackers’ access to the datastream.

EAP Authentication Types

Most of the more recent EAP types are made up of two components: an outer and an inner authentication type, separated by a forward slash—such as PEAPv0/EAP-MSCHAPv2. The outer type defines the method used to establish an encrypted channel between the client (peer) and the Authentication Server.

Note

The primary goal of the Transport Level Security (TLS) Protocol is to provide privacy and data integrity between two communicating applications. TLS is based on the Netscape SSL 3.0 Protocol Specification, although they are not interoperable. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol, and is situated between ISO layers 3 and 4. Symmetric cryptography is used for data encryption (e.g., DES, RC4, AES, etc). The keys for this symmetric encryption are generated uniquely for each connection. Message transport includes a message integrity check using a keyed MAC (SHA, MD5). These two elements ensure data confidentiality and integrity for each connection.

In Figure 1 an outer authentication method, PEAP, is negotiated between a client such as an IP phone or a workstation and a RADIUS authentication server. The intermediate NAS proxies the first several exchanges and then serves to passively mediate traffic in both directions. The NAS does not have knowledge of the keys used to instantiate the TLS tunnel, and thus, cannot be used to snoop on the encrypted traffic passing through it.

 
Figure 1: EAP Part I Outer Tunnel

This outer tunnel verifies the server to the client using digital certificates.

Once the outer channel is established, the inner authentication type passes the user’s credentials to the Authentication Server over this TLS encrypted tunnel for additional authentication of, typically, user credentials. Passing user credentials through the TLS encrypted tunnel protects them from exposure (see Figure 2).

One of EAP’s potential security vulnerabilities is that data exchanged as part of some of the outer authentication types, such as identity data, and the results of parameter negotiations are sent in the clear. This can result in a Denial-of-Service (DoS) condition since an attacker, for example, can flood the connection with different types of EAP notification messages.

 
Figure 2: EAP Part II Inner Tunnel

In Table 1some of the characteristics for the different types are summarized. In the last two fields more plus signs (&) equals greater difficulty and more strength, respectively.

Most of the newer EAP types defined by the Wi-Fi Alliance (those with the forward slash and EAP-SIM) are derived from this EAP type. EAP-PEAP and PEAPv0/EAP-MSCHAPv2 are the same thing. PEAPv1/EAP-GTC is a Cisco invention.

EAP-TLS

EAP-TLS (Extensible Authentication Protocol—Transport Layer Security) provides for certificate-based and mutual authentication of the client and the network. EAP-TLS is the most secure of the common EAP types, but requires a PKI (public key infrastructure) to manage and distribute client certificates. The TLS protocol has its roots in the Netscape SSL protocol, which was originally intended to secure HTTP. It provides either one-way or mutual authentication of client and server based on certificates. In its most typical use in HTTP, the client authenticates the server based on the server’s certificate and establishes a tunnel through which HTTP traffic is passed. Username and password management in this scheme is irrelevant as identity is based upon possession of the appropriate private key. The obligatory overhead of a certificate management infrastructure normally precludes use of this EAP type.

Table 1: EAP Types Summary 

EAP Type	Server Authentication	Client Authentication	Native Windows 2003 Support	Confidentiality	Integrity	Deployment Difficulty	Security Strength
EAP-TLS	Certificate	Certificate	Yes	TLS	+	+++++	+++++
EAP-PEAP	Certificate	Certificate, Smartcard, MS-CHAP-V2	Yes	TLS	+	++	++++
PEAPv0/ EAP-MS CHAPv2	Certificate	Certificate, Smartcard, MS-CHAP-V2	Yes	TLS	+	++	++++
EAP-TTLS	Certificate	PAP, CHAP, EAP, MS-CHAP-V2, Certificate	No	TLS	+	+++	++++
PEAPv1/ EAP-GTC	Password hash	Password hash (Token)	No	No	+	???	+++
EAP-SIM	128-bit secret	SIM secret	No	+/−	+/−	+++	++
EAP-FAST	Optional (PAC) password	Password (PAC)	No	+	+	+++	+++
LEAP	Password	Password	No	+	+	+++	+
MD5	None	None	Yes	−	−	+	+

EAP-PEAP

EAP-PEAP (Extensible Authentication Protocol-Protected Extensible Authentication Protocol) provides a method to transport secure authentication data, including legacy pass-word-based protocols. PEAP accomplishes this by tunneling user credentials over a TLS tunnel between PEAP clients and an authentication server. EAP-PEAP is the best combination of security and ease of deployment in Windows environments today. EAP-PEAP requires only a server certificate (which is simple enough to create for testing using the native MS Certification Authority) and client side username/password combinations. EAP-PEAP is natively supported on Windows XP and Windows 2000 SP4 and above client platforms and IAS (Internet Authentication server). PEAPvO/EAP-MSCHAPv2 is the same thing as EAP-PEAP.

EAP-TTLS

EAP-TTLS (Extensible Authentication Protocol-Tunneled Transport Layer Security) is supported primarily by the Funk RADIUS people. EAP-TTLS, like PEAP, is also relatively easy to deploy (it requires only a server-side certificate) and quite secure since it tunnels user credentials inside of a TLS tunnel; however, this Funk Software invention has not been supported by Microsoft on clients or IAS server. Thus, EAP-TTLS requires the use of an additional software. TTLS and PEAP are similar in other ways, but there are differences: TTLS supports other EAP authentication methods and also supports inner authentication methods, PAP, CHAP, MS-CHAP, and MS-CHAPv2; whereas PEAP can tunnel only EAP-type protocols such as EAP-TLS, EAP-MS-CHAPv2, and EAP-SIM.

PEAPv1/EAP-GTC

PEAPv1/EAP-GTC (Extensible Authentication Protocol-Generic Token Card) was defined in RFC2284 along with one-time passwords, and MD5 was one of the initial set of EAP Types used in Request/Response exchanges. Cisco supports this type of PEAP (v1 vs. v0) and Microsoft supports only PEAPv0.

EAP-FAST

EAP-FAST (Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling) was developed by Cisco. EAP-FAST authenticates both the client and the authentication server using a preshared secret known as the Protected Access Credential (PAC). EAP-FAST is a certificate-free replacement for LEAP EAP-FAST is easy to implement in Windows/Cisco mixed environments, but this method is vulnerable to MITM (man in the middle) attacks in which an attacker can acquire the MS-CHAPv2 hash of the user’s passwords, which can then be subjected to off-line dictionary attacks.

LEAP

LEAP (Lightweight Extensible Authentication Protocol) is an EAP authentication type used primarily in Cisco Aironet WLANs. LEAP supports strong mutual authentication, based upon a modified MS-CHAPv2 challenge/response, between the client and a RADIUS server using a logon password as the shared secret. It provides dynamic per-user, per-session WEP encryption keys. LEAP has been superseded by EAP-FAST due to the public availability of LEAP hash cracking tools such as ASLEAP. There is some disagreement regarding the value of complex password enforcement when using LEAP. When in doubt, use the longest, most complicated passwords that your userbase will agree to.

EAP-MD-5

EAP-MD-5 (Extensible Authentication Protocol-Message Digest) is an EAP authentication type that provides base-level EAP support. EAP-MD5-Tunneled is an EAP protocol designed for use as an inner authentication protocol within a tunneling protocol such as EAP- TTLS or EAP-PEAP. This has additional security features, but has not been widely deployed.

Notes from the Underground…—RainbowCrack

---

Passwords are the most common form of computer authentication today. Password encryption is done using a one-way hashing algorithm such as MD5 or SHA-1. A one-way hash function, also known as a message digest, is a mathematical function that takes a variable-length input string and converts it into a f ixed-length binary sequence that is computationally difficult to invert—that is, generate the original string from the hash. Conventional password crackers grab a word or string of wordlike tokens and run it though the hash algorithm. It then compares its generated hash with the target password hash. If they match, then the password has been discovered. The computationally expensive part of this process is the hash generation preceding the hash comparison, not the actual comparison process itself.

RainbowCrack is a general-purpose implementation of Philippe Oechslin’s faster time-memory trade-off technique. In short, the RainbowCrack tool is an extremely fast and effective hash cracker The simple but brilliant idea of time-memory trade-off is to do all the hash generation computation in advance and store the result in chains of files called “rainbow tables.” It does take a long time to precompute the tables (it takes 2–3 days to generate the rainbow tables necessary to crack a lowercase-letters-only Windows (LM hash) password that’s between 1 and 7 characters in length), but after this one-time computation is finished, a time-memory trade off crarker can crack passwords hundreds or thousands of times faster than a brute force cracker.

---

Inner Authentication Types

A number of inner authentication methods exist. The most commonly used is MS-CHAP-V2 because it is relatively secure and it is supported natively on all recent Microsoft clients. Additionally, PAP, CHAP, MD5, GTC, and other inner authentication methods exist but are not nearly as commonly used. Interestingly, even EAP itself can be tunneled within EAP.

802.1x/EAP Authentication

Now we’ll define the terms associated with 802.1x/EAP authentication.

Supplicant (Peer)

This is the other end of the point-to-point link; the end that is being authenticated by the authenticator. Generally this term refers to the client in an EAP exchange.

Authenticator

Authenticator is a wireless access point (AP) or switch (NAS—Network Access Server). The authenticator maintains the network (WLAN or LAN) in closed state to all unauthenticated traffic. It does not do authentication directly, but instead tunnels the extensible authentication protocol (EAP) to an authentication server.

Authentication Server

The authentication server performs the actual client authentication and instructs the authenticator to allow or reject the supplicants traffic. The authentication server is typically a RADIUS server.

Figure 1 illustrates the basic message flow in an 802.1x/EAP authentication scenario. This is an example of the most common 802.1x/EAP model —a Full/Pass-Through state machine, which allows an NAS (network access server) or edge device to pass EAP Response messages to an Authentication Server where the authentication method resides. The NAS does not have to understand the request type and must be able to simply act as a passthrough agent for a back-end server. The NAS need look only for the success/failure code from the Authentication Server to terminate the authentication phase.

 
Figure 1: Generic EAP Authentication

---

Tools & Traps…—AAA, RADIUS, and DIAMETER

RADIUS (Remote Authentication Dial In User Service) is an AAA (authentication, authorizaticm, and accounting) protocol for applications such as network access or IP mobility, AAA is a term for a framework that allows methods to intelligently control access to computer resources, enforce policies, audit usage, and provide information necessary to bill for services. Because AAA services often are used to authenticate remote system administrators, availability is critical, and should always be provided by at least a pair of physically separated, dedicated AAA servers that serve as master and backup.

DIAMETER is a new extended AAA protocol that is designed to replace RADIUS, DIAMETER {a play on words, since diameter is twice the radius of a circle) is designed to enhance RADIUS functions and to fix several security problems (such as unencrypted CHAP response) that have plagued RADIUS in recent years.

---

In step 1, the supplicant (a workstation, wireless access point, IP phone, etc.) sends one or more requests to the NAS petitioning for access to the network. The NAS (step 2) passes the EAP message to the Authentication Server, which is almost always a RADIUS server. In step 3, the Authentication Server requests the credentials of the supplicant and specifies the type of credentials required to confirm the supplicant’s identity. (Note here that the arrows between the RADIUS server and the client indicate logical, not physical, connectivity. All traffic between the two passes through the NAS.) The Authentication Server makes its decision to grant or deny access based upon Native RADIUS credentials. In step 4, the supplicant sends its credentials to the RADIUS server. Upon validating the supplicant’s credentials, the Authentication Server transmits a success/failure message to the NAS (step 5). In step 6, if access is granted, the NAS opens the port to all traffic (as opposed to just EAPOL traffic) and data exchange between the authenticated LAN device and the LAN is allowed. If access is granted, then (step 7) the supplicant is able to access network resources.

You will notice that after access is approved, the supplicant has unrestricted access to network resources. Only the device identity has been authenticated. No authorization has been performed, nor has the user of the device been authenticated.

Figure 2 illustrates a more typical generic 802.1x transaction. The first several steps in this scenario are similar to the scenario we just described. In step 1, the supplicant (a workstation, wireless access point, IP phone, etc) sends one or more requests to the NAS petitioning for access to the network. The NAS (Step 2) passes the EAP message to the Authentication Server, which is almost always a RADIUS server. In step 3, The Authentication Server requests the credentials of the supplicant and specifies the type of credentials required to confirm the supplicant’s identity. (Note here that the arrows between the RADIUS server and the client indicate logical, not physical, connectivity. All traffic between the two passes through the NAS.)

 
Figure 2: EAP Authentication with Authorization

In step 5 the Authentication Server (RADIUS) forwards the access request to the AD server. The AD server responds with a success or failure message, and if successful, also forwards the client’s AD domain credentials in step 6. Upon validating the supplicant’s credentials, the Authentication Server transmits a success/failure message to the NAS (step 7). In step 8, if access is granted, the NAS opens the port to all traffic. If access is granted, then (step 9) the supplicant is able to access authorized network resources.

In this scenario, administrators can limit user access to specific VLANs, and via Windows permissions, to most network resources. The specifics of authentication and authorization depend upon the type of EAP policy chosen. 

802.1x and 802.11i (WPA2)

The 802.1x protocol defines port-based, network access control that is used to provide authenticated network access (see Figure 1). Although this standard is designed for wired Ethernet networks, it has been adapted for use on 802.11 WLANs. It is simply a standard for passing EAP over a wired or wireless LAN.

 
Figure 1: EAPOL

802.1x restricts unauthorized clients from connecting to a LAN. The client must first authenticate with an Authentication server, typically a RADIUS server, before the switch port is made available and the network can be accessed. EAP (Extensible Authentication Protocol) is a general authentication protocol that provides a framework for multiple authentication methods, including traditional passwords, token cards, Kerberos, Digital Certificates, and public-key authentication.

WEP (Wireless Equivalent Privacy) has famously been shown to be insecure (Anton Rager’s wepcrack was the first publicly available tool for this—http://wepcrack.source-forge.net/); however WEP protection of wireless connections is still better than no encryption at all. The Wi-Fi Alliance (a consortium of major vendors—http://wi-fi.org/) is responsible for drafting both the WPA (Wi-Fi Protected Access) and WPA2 standards. The Wi-Fi alliance also formed a VoWLAN (Voice over Wireless LAN) working group tasked with developing WMM (Wi-Fi Multimedia) QoS standards for VoIP and other multimedia over wireless networks.

WPA implements a subset of IEEE802.11i, and differs from WEP mainly in that it utilizes TKIP (Temporal Key Integrity protocol) and the EAP framework for authentication. 802.11i is a draft IEEE standard for 802.11 wireless network security. 802.11i, also known as WPA2, uses 802.1x as the authentication mechanism and the Advanced Encryption Standard (AES) block cipher for encryption. WEP and WPA use the RC4 stream cipher. Table 1 shows some of the key features of these three security standards.

Table 1: Security Standard Features 

Protocol	Authentication	Cipher	Key Length	Key Management
WEP	None	RC-4	40/104	None
WPA	802.1x/EAP	RC-4	128	802.1x/EAP
WPA2	802.1x/EAP	AES	128	802.1x/EAP

It is helpful to think of 802.1x not as a single protocol but rather as a security frame-work using existing, and proven security standards that serves two critical security func-tions—authentication (PSK or PKI, for example) and encryption (TLS or AES, for example). Note that 802.1x does not define either authentication or encryption methods (in fact 802.1x can be used without encryption); rather these are defined largely through this choice of an EAP type.

Until the client is authenticated via 802.1x/EAP access control, the only protocol allowed through the port to which the client is connected is Extensible Authentication Protocol traffic. After authentication is successful, traffic can pass through the port.