Understanding the concepts behind RSN/TSN

Understanding the concepts behind RSN/TSN

Security Context: Context created after successful acceptance of the security checks. This shall be specific to a particular period and each time authentication needs to provided.

Keys:
During the authentication phase, you have to prove your identity by demonstrating that you have knowledge of a secret. Passing this test entitles you to receive the other keys  those that open doors and start engines, for example. In the case of RSN, correctly authenticating enables you to receive or create the keys that are used for encryption and data protection.
These useful keys are sometimes called the temporal or session keys because they work only so long as the security context is in place.

In principle, temporal keys can be created out of thin air. For example, when encrypting messages between two parties, you simply require that both parties (and only these parties) have the same key value. You don't care what that value is, so if you have a way that two parties can separately generate the same "random" number at roughly the same time, you can use that as the key. When you have finished communicating, you can just throw away the key.
Authentication is based on some shared secret information that cannot be created automatically. An authentication key must be created by someone trusted and attached to the holder in such a way that it can't easily be copied or stolen. And, of course, the trusted key giver has to be certain of the identity of the key receiver. The basis of all authentication methods, therefore, is that the entity that is to be authenticated possesses some special information in advance, which is called the master key. Using the master key in a way that
protects it from discovery is very important. As a general rule, the master key is rarely, if ever, used directly; instead, it is used to create temporal keys. (WEP, of course, rode through his rule by using the master key both in authentication and encryption.)

In summary, there are two types of keys: a fixed or master key that provides proof of identity, and any number of temporal keys that are created or derived from the master key for use in the security protocol

Access Control: IEEE 802.1X,EAP, and RADIUS

Before EAP was introduced, PPP protocol was used for dial-up connections. It has two methods.

1. PAP, which is still used by many ISPs, actually sends the user name and password in clear text so any snooper on the link can steal it. 
2. CHAP, uses a challenge response mechanism, somewhat similar to the original WEP method. This is much better than PAP but still not considered very strong.

To solve this problem, IETF members decided that a more extensible method was needed for PPP. Therefore, the option of EAP was added alongside PAP and CHAP. EAP allows full authentication to be delayed until after the preliminary PPP link is established. RFC2284 "PPP Extensible Authentication Protocol (EAP)"
The intent of EAP is to enable the use of an authentication algorithmbetween the supplicant and the authorizer. EAP is designed to allow different types of authentication methods to be used   that is why it is called extensible. The object is to enable the supplicant to prove his identity to the authorizer. Many methods allow mutual authentication so both parties prove their true identity to the other.
It is common in dial-up networks to have a modem pool in each local phone area to provide cheap access, often called a point of presence(POP). However, the service provider doesn't want to keep a copy of their user database at every POP; they want a central database. This creates a three-party situation that is very similar to that of a corporate Wi-Fi LAN. Using the terminology in our introduction, the user is the supplicant, the POP is the authenticator, and
the central database is the authorizer. The protocol used between the POP and the central database to get permission to allow a dial-in user access to the network is called RADIUS(Remote Access Dial-In User Service).

IEEE 802.1X

IEEE 802.1X is very simple in concept. Its purpose is to implement access control at the point at which a user joins the network. It divides the network universe into three entities along the lines we discussed in the previous section: It came as alternative to PPP (Point to Point Protocol) which  converts the unstructured modem link into a packet-based environment suitable for transporting the IP packets.

1. Supplicant, which wants to join the network
2. Authenticator, which controls access
3. Authentication server, which makes authorization decisions

The EAP protocol is used by the various parties to communicate with each other. EAP messages go between the supplicant and the authenticator. The authenticator may also forward them to the authentication server as part of the process of authorization.  If the authentication server is in a remote location, these messages need to be sent over a network using some higher-layer protocol. This is where RADIUS can be called into action to transfer the requests over an IP network. RADIUS was designed to perform this job in the dial-up user case, and it also extended for IEEE 802.1X.

One of the differences between dial-in networks and IEEE 802.1X is that, with IEEE 802.1X, there is no need to use PPP because IEEE 802 LANs are designed to send data packets. However, it is still necessary to have some sort of protocol so the receiver can identify the information, and that protocol is called EAPOL (EAP over LAN). EAPOL has several types of messages. Apart from the one that delivers the EAP messages, there are several additional ones that are useful for actions like attracting the attention of the authenticator (the doorbell analogy). Also there is a message for transferring key-related information.

EAP MESSAGE FORMAT:

CODE

EAP specifies that four types of message can be sent. Code is 1 byte and has following values
1. Request (01): Used to send messages from the authenticator to the supplicant.
2. Response (02): Used to send messages from the supplicant to the authenticator.
3. Success (03): Sent by the authenticator to indicate access is granted.
4. Failure (04): Sent by the authenticator to indicate access is refused.

IDENTIFIER

Is a value in the range 0  255 and IEEE 802.1X indicates that it should be
incremented for each message sent. When a response is sent, the identifier is set equal to that in the request. This helps for checking which response goes with which request.

LENGTH

Is the total number of bytes in the EAP message (including Code and so on). It is a 16-bit value. 

DATA

Is the actual request or response data being sent.

Success and Failure packets: 

These messages are short and contain no data. One of these messages is used at the end of the authentication process to signal the result. Because the Success and Failure are common across all authentication protocols, intermediate devices (such as the access point) can detect when an authentication completes without understanding all the details of the authentication method. The access point should wait for the RADIUS Accept message before making any decision about access rights.

Request and response packets:

 

The details of the authentication method are sent in the request and response messages. These have an extra field called Type. These messages are further subdivided using the EAP Type field. 

TYPE

The Type field indicates what information is being carried in the EAP message. The use of the Type field is a bit inconsistent. For the most part, it indicates the authentication method. But in a few cases, it defines a special-purpose message.

Type value 1 - IDENTITY

The most important predefined type is Identity (type value 1).
Typically, this is used as part of the EAP introduction phase:
The message EAP-Request/Identity is sent by the authenticator to a new supplicant. The supplicant replies with the message EAP-Response/Identity containing its user name or some other identifier that will be understood by the authentication server.

Type value 2 - Notification message is used to send some user-displayable text.

Type value 3 - NAK
A message with a type value of 3 is called a NAK and is used when a request is made for an authentication method that is not supported. If an EAP request with type TLS is sent to a peer that doesn't support TLS, it can respond with a Type field of NAK.

EAPOL

EAP is not a LAN protocol at all because EAP was originally designed for use with dial-up authentication via a modem. The EAP RFC does not specify how messages should be passed around. It does not, for example, specify transport over the Internet using IP. IEEE 802.1X defines a protocol called EAP over LAN to get EAP messages passed between the supplicant and the authenticator. IEEE 802.1X provides the description for EAPOL.
If you just wanted to encapsulate the EAP message, you could prepend an Ethernet MAC header on an EAP message and send it over the LAN. But the IEEE 802.1X committee decided to add a few more useful messages and fields while it was defining EAPOL. Not all EAPOL frames actually carry EAP messages; some are used to perform administrative tasks. The five types of EAPOL messages are:

1. EAPOL-Start
2. EAPOL-Key
3. EAPOL-Packet
4. EAPOL-Logoff
5. EAPOL-Encapsulated-ASF-Alert (This message is not used by WPA/RSN.)

EAPOL-START:

By sending this message to a special group-multicast MAC address reserved for IEEE 802.1X authenticators, a supplicant can find out whether an authenticator is present and let it know that the supplicant is ready. In many cases the authenticator will already be notified that a new device has connected from some hardware notification. For example, a hub knows that a cable is plugged in before the device sends any data.

EAPOL-Key: 

Using this message type, the authenticator sends encryption (and other) keys to the supplicant once it has decided to admit it to the network. Of course it is necessary to encrypt the keys themselves before sending them, and IEEE 802.1X does not specify how this is done.

EAPOL-Packet:

EAPOL Packet is used for sending the actual EAP messages. It is simply a container for transporting an EAP message across the LAN, which was the original objective of the EAPOL protocol.

EAPOL-LogOff:

This Message type indicates that the supplicant wishes to be disconnected from the network.

EAPOL Format:

1. The protocol version is always 1 (this could change in the future).
2. The packet type number indicates start, key, and so on.
3. For some message types, no further information is needed and the packet body length is set to 0 (and the body is omitted). However, if there is a packet body, such as an EAP message, its length and data are added on as appropriate.

Upper Layer Authentication Methods:

Keys in Upper layer authentication

Two main classes of solution:
symmetric keys and asymmetric keys, sometimes known as secret and public keys,
respectively.

Symmetric Keys:

Authentication occurs when each party proves to the other that they know the
secret. This is like the child's method, "You can't come in unless you tell me the password." When each party has proved itself, they can both create matching session keys for use in the security context. Such keys are derived from the secret master key but may also incorporate other information, such as the time and arbitrary numbers created for the session (called nonces). The purpose of these extra items is to ensure that the session keys are usable only
in the current session and cannot be reused later.

Asymmetric Keys:

To deal with the situation in which you can't easily distribute the secret key, the idea of asymmetric key encryption was invented, leading to the use of public keys. Public key encryption is supported by a set of components often referred to as PKI (public key infrastructure). Public key encryption actually has two keys. One key is made public and the other must be kept private. Furthermore, these are not any two keys; the public and the private copies are a mathematically connected pair.
Many encryption systems are symmetric in that the same key is used to encrypt and then decrypt the message. However, public key systems use an asymmetrical method in which different keys are used for encryption and decryption. You
encrypt with key E and decrypt with key D. Furthermore, you can't decrypt with key E, and knowing E doesn't enable you to compute D.
When you want to use public key encryption through programs such as PGP (Pretty Good Privacy), you first use a key-generating utility. You run this utility and usually enter some personal information to help ensure your keys are unique to you. The utility then generates two key values, a public key and a private key. The public key can be given to anyone. And the key can be used to encrypt a message using your public key and send it to you. Only you can decrypt the message because only you know the private key.
Signing a message is like signing a document: It is intended to prove that the message came from a particular person. Message signing works in the reverse way from encryption. You use a private key to create a signature and a public key to check the signature.

Certificates and Certification Authorities

Essentially, a certificate authorityis a trusted independent organization that certifies a set of public and private keys for use with PKI transactions. The authority handles this task by generating certificates in a standard format. A certificate is just a bunch of data. It has no physical form. However, when another party sends you a certificate, it contains enough information for you to validate who they are and establish a secure context. With most Web purchases, this is a one-way context that protects the consumer. The vendor gets protection through your credit card details!

Scenario:

User tries to open a website which is secure. How security works?
Web site owner buys certificate form CA that binds your company and its Web site into your public and private key pair. When someone logs into your website, website sends its certificate to the user. Assuming you
went to a well-known certificate authority, the browser will likely accept the certificate as trusted (you can control this in the advanced options of the browser). If not, it notifies the user that an untrusted certificate has arrived and prompts her to decide whether to proceed. The certificate contains the public key for your site, so now the browser can start encrypting all the messages. Your Web server is able to decrypt the messages with your private key, and so the transaction is protected. The customer can feel confident that the credit card details and order information are going to the right place and not being snooped along the way.
How does the browser know that certificate is real ?
Because the entire certificate is signed by the certificate
authority using its private key, and therefore it can be proved authentic because its validity can be tested by checking the signature with the authority's public key, which is also in the certificate.

TLS:

Full TLS provides authentication, encryption, and, in principle, data compression functions.
TLS is divided into two layers: the record protocol and the handshake protocol. The record protocol is responsible for shifting data between the two ends of the link using the parameters agreed via the handshake protocol.

How PMK is secured behind AP ?

Microsoft helped create an RFC covering their proprietary extensions to RADIUS (RFC2548: Microsoft Vendor-Specific RADIUS Attributes).
These extensions contain an attribute called MS-MPPE-Recv-Key, which is specifically
intended to deliver key information to the NAS. In fact the description in the RFC says:
The MS-MPPE-Recv-Key Attribute contains a session key for use by the Microsoft
Point-to-Point Encryption Protocol (MPPE). As the name implies, this key is intended for
encrypting packets received by the NAS fromthe remote host. This attribute is only included
in Access-Accept packets.

How liveliness is acheived for the 4 way hand shake ?

Liveness is achieved by including a couple of special values called nonces in the computation. The value of the nonce is quite arbitrary except in one respect: a nonce value is never used twice with the same key. The word "nonce" can be thought of as "N   once"  in other words, a value (N) only used once.

WPA-RSN Key Heirarchy

Four separate keys are needed to do the job because there are two
layers to protect  the EAPOL handshake and the user's data  and two cryptographic
functions at each layer: encryption and integrity.

1. Data Encryption key (128 bits)
2. Data Integrity key (128 bits)
3. EAPOL-Key Encryption key (128 bits)
4. EAPOL-Key Integrity key (128 bits)

These are referred to as the temporal keysbecause they are recomputed every time a
mobile device associates to the access point. The collection of all four keys together is
referred to as the pairwise transient key (PTK). For RSN/TKIP and WPA, each of these keys
must be 128 bits long so that the PTK is a total of 512 bits long.

MS-CHAP

Microsoft has developed a specific version of CHAP, called MS-CHAP (Microsoft Challenge Handshake Authentication Protocol version 1, sometimes denoted as MS-CHAP-v1), improving the overall security. Indeed, CHAP requires that passwords are transferred in plain text over the network, which is a potential vulnerability. MS-CHAP provides a hash function to store (via a hash) the password on the server. When the remote machine responds to the challenge, and it has to hash the password using the proprietary algorithm.

Unfortunately the MS-CHAP-v1 protocol suffers from security vulnerabilities related to weaknesses in the proprietary hash function.

MS-CHAP v2

Version 2 of MS-CHAP, MS-CHAP-called V2 was set in January 2000 (RFC 2759). This new version of the protocol defines a so-called "mutual authentication" method, allowing the authentication server and the remote machine to verify their identities. The process is as follows:

• The authentication server sends a verification request (session identifier and a random string) to the remote client.

The remote client responds with:

• its user name,
• a hash containing arbitrary string provided by the authentication server, the session ID and password,
• a random string.

The authentication server checks the response from the remote client and in turn send:

• a notification of success or failure of the authentication
• an encrypted response based on the random string provided by the remote client.

The remote client then in turn verifies the response and if successful, establishes the connection.