1. IP Security – Session 3 – AAA
IIT681 – WLAN Standards & Operation
© Institut international des télécommunications., 2005
© International Institute of Telecommunications inc., 2003
November 2003

2. Authentication, Authorization and Accounting
Critical to any security solution
Separates the “good guys” from the “bad guys”
Authorization:
Once authenticated, what resources are available for this user?
Database, files, services, hosts, etc.
Often (mistakenly) confused with Authentication
All or nothing policy
Accounting:
Logging of user activity
Can be used for:
Keeping a trace for security audits
Charging customers for resources usage (ISP)

3. Generic Authentication Scenario
Client
I need access
Server
Authenticate yourself
I am “A”
Query “A” ?
Yes / No
Access granted / denied
Database
(local or
remote)
Shared secret

4. Authentication Methods
Name-based
Verification of basic, available information
IP address, MAC address, DNS domain, etc.
Difficult to implement
Not very secure
Password-based
Works on a challenge-response scheme
Username prompts a challenge from a server
Password is rarely sent over the network
Secure, but still susceptible to dictionary attacks
Token-based
User carries a hardware token device with a changing key
The key, in conjunction with a password, is used to provide a response to a challenge

5. Authentication Methods (cont)
Cryptographic
Based on known crypto and hashing methods
Users are issued a certificate to prove their identity
Certificate is signed by a trusted third-party
Biometric
Bio: life; Metric: measure
Uses body properties to authenticate a user
Fingerprint
Retina and iris scan
DNA?
Biometric data is used as a token, similar to token-based

6. Authentication Factors
User IS
Biometric data
User HAS
Token
ID card
Cell Phone (SIM)
User KNOWS
Password
Passphrase
PIN
Best authentication systems are multi-factor
Password + Token: two-factor authentication
PIN + ID card + Biometric data: three-factor authentication

7. Password Authentication Scenario 1
Client
I need access
Server
Authenticate yourself
I am “A”, password “QWERTY”
“A” password “QWERTY”?
Yes / No
Access granted / denied
Shared secret: password
This scenario is not secure: password is sent in plaintext
Used by PAP (Password Authentication Protocol)

8. PAP: Password Authentication Protocol
RFC 1334
Password must be protected on both systems
Susceptible to eavesdropping and replay attacks
Serves as client authentication only: server could be an impostor
PAP was developed for the Point-to-Point Protocol PPP
Served well when connection was established on a dial-up line
PPP connections can now be established over shared networks (such as Ethernet using PPPoE)
PAP is no longer used because considered not secure

9. PAP (cont.) Alice IIT NAS ID = Alice, Password = ???
Authenticate-Ack or Authenticate-Nak
Information
Padding
Protocol
0XC023=PAP
Identifier
Length
Code
1 byte
Data
Host ID
Password Size
Host ID Size
Password

10. Password Authentication Scenario 2
Client
I am “A”, I need access
Server
CHAP Challenge:
Compute Response
CHAP Response: Answer: 89it%-QkL
Query “A”’s password
Compute response
Match?
CHAP Access granted / denied
Shared secret: password
Challenge by B: randomly generated number
Response by A: Hash of (Password + Random Challenge)
Used by CHAP (Challenge Handshake Authentication Protocol)
The challenge is random to prevent replay attacks

11. Challenge Handshake Authentication Protocol (CHAP)
RFC 1994
CHAP protects against eavesdropping since password is never sent
It also protects against replay attacks because a random number is used
It is however vulnerable to dictionary and brute force attacks
Both the challenge and the response are visible
Hash method used by CHAP is MD5
RFC 1321

12. CHAP (cont.) CHAP challenge: CHAP response:
ID number (different with every challenge)
Random number (different with each challenge)
A name, for example identifying the domain on which the user is challenged
CHAP response:
ID number (same as the one in challenge)
Response value = MD5 (ID + Password + Random value provided in challenge)
Username of user requesting access

13. CHAP (cont.) Alice Information Padding Protocol Identifier Length Code
IIT NAS
Alice
ID, Random Number, IIT
Success or Failure
ID, Pwd, Random No.
MD5
Hash response
ID, Hash response, Alice
Hash Value, match?
Information
Padding
Protocol
0xC223=CHAP
Identifier
Length
Code
Data
Value
Name
Value-Size

14. Authentication Server (central user database)
About CHAP and PAP
Both CHAP and PAP protocols were created to manage remote access users
Low-level authentication: controls access to network resources
First iteration: dial-up networking using Point-to-Point Protocol (PPP)
New uses:
Wi-Fi using WEP security (Wired-Equivalent Privacy)
PPPoE (PPP over Ethernet, used for ADSL user authentication)
Because of the decentralized nature of dial-up networks, a technology for central authentication is often required
IP Network
Remote Access
Server
Authentication Server
(central user database)
Remote Access
Server

15. Authentication Server
RADIUS
RFC 2865
Remote Authentication Dial-In User Service
Three-party authentication
Client (supplicant), request access to the network
Authenticator is the supplicant’s first contact to the network
Ethernet switch
Wi-Fi Access point
PPP end-point
Authentication Server contains the user database and grants or denies access
RADIUS
IP Network
Authenticator
Client
(Supplicant)
Authentication Server

16. RADIUS Scenario 1 Client (Requestor) Authenticator
Authentication Server
I am “A”, I need access
CHAP Challenge
CHAP Response
RADIUS Access-Request
RADIUS Access-Accept / Reject
CHAP Success / Failure

17. RADIUS Scenario 1 (cont.)
The Authenticator challenges the client upon request and collects the Client’s response to the CHAP challenge
The Authenticator sends to the Authentication Server the username, ID, random number and client response (CHAP MD5 hash) in the Access- Request packet
The Authentication Server computes the MD5 hash using the ID, client’s password and random number and replies with an Access-Accept or an Access-Failure packet
The Authenticator forwards the information to the client in the form of a CHAP Success or CHAP Failure packet

18. RADIUS Scenario 2 Client (Requestor) Authenticator
Authentication Server
I am “A”, I need access
RADIUS Access-Request
RADIUS Access-Challenge
CHAP Challenge
CHAP Response
RADIUS Access-Request
RADIUS Access-Accept / Reject
CHAP Success / Failure

19. RADIUS Scenario 2 (cont.)
The Authenticator, upon request, sends to the Authentication Server a RADIUS Access-Request.
The password is set to a knowingly wrong value such as the string “empty” or “void” to prompt a challenge from the server
The Authentication Server sends a RADIUS Access-Challenge packet which is forwarded to the client in the form of a CHAP Challenge
The client responds using the normal CHAP method
The rest of the procedure follows Scenario 1

20. Notes on RADIUS Scenarios 1 and 2
Why use one method or the other?
In some cases, the Authenticator is programmed to take a load off the Authentication Server and will provide the CHAP Challenge itself
In some other cases, it is better to have the Authentication Server provide challenges from a central location to assure uniqueness of challenges and prevent replay attacks
It is the case when the Authenticator is a wireless Access Point
In both scenarios, the Authenticator and Authentication Server share a secret key that is used to further encrypt the information and prevent replay attacks on that segment

21. RADIUS successor: DIAMETER
RFC 3588
Named as a pun: DIAMETER is twice the RADIUS
Natural evolution of RADIUS to circumvent problems:
Better integration with upper-layer security protocols (e.g. TLS)
Better failover scenarios (for carrier environments for example)
Better audit support
Support for Mobile IP
This was a key determinant in choosing DIAMETER over RADIUS in 3G wireless networks

22. The evolution of PAP and CHAP: EAP
Because network access may be requested by other means than the aging CHAP, it was necessary to evolve
A new protocol was created: Extensible Authentication Protocol
Offers easier implementation since it allows regrouping many authentication techniques into one protocol

23. Authentication Server
EAP
RFC 3748
Extensible Authentication Protocol
Designed for network access purposes
Extensible means is will support many past and future authentication techniques:
PAP & CHAP
Token methods (covered later)
Upper Layer authentication such as TLS and Kerberos (covered later)
Native EAP
PAP in EAP
EAP in RADIUS
CHAP in EAP
IP Network
Authenticator
Token in EAP
Kerberos in EAP
Authentication Server
EAP in RADIUS
TLS in EAP

24. Token Authentication Scenario 1
Client
Server
I am “A”, Password: 89it%-QkL
Token Card
Access granted / denied
Password is encrypted using a shared secret key between A and B, provided by the token
The value on A’s token card’s screen changes periodically, in synch with B’s internal clock

25. Token Authentication Scenario 1
The server (B) maintains an internal clock upon which is derived a secret key
This token method is known as synchronous
The key changes periodically, generally every 30 seconds
The client (A) HAS a token card with the same internal clock
The token card displays the current token value
When access is requested, the client’s password and the token value are encrypted (hashed) using the token key
Upon receipt, the server computes the same hash using the clients password from its own database and the current token key
Problems with synchronous token systems:
Clock drift, server must compensate
Battery life in token card: token must be replaced when battery is dead

26. Token Authentication Scenario 2
I am “A”
Client
Server
Challenge: 654B21A
Response: 89it%-QkL
Access granted / denied
Token Card
Password is encrypted using a shared secret key between A and B, provided by the token
The response value on A’s token card’s screen is displayed when the user enters the challenge value

27. Token Authentication Scenario 2
No clocks in A or B
This token method is known as asynchronous
The token card is used to compute the response to the challenge
Problems with asynchronous token system:
Less practical, requires multiple steps

28. Upper-Layer Authentication
In many cases, authentication is not required for access to low-level network resources but rather for other applications
Example:
Secure Web site for e-commerce
Access to a remote database
Access to a file or print server
To allow authentication to happen, upper-layer authentication exists:
IPSec (Layer 3 – IP)
SSL and TLS (Layer 4 – Transport)
Kerberos
The upper-layer protocols rely on Cryptographic Authentication Methods

29. IPSec Authentication RFC 2401 and 2406
IPSec works at layer 3 of the OSI model to create secure tunnels
Each encrypted packet in the tunnel contains authentication data to prove its origin
End-to-end
Node-to-node
| Security Parameters Index (SPI) |
| Sequence Number |
| Payload Data* (variable) |
~ ~
| |
| | Padding (0-255 bytes) |
| | Pad Length | Next Header |
| Authentication Data (variable) |

30. SSL and TLS RFC 2246 SSL is Secure Socket Layer
Developed by Netscape for secure web transactions
TLS is Transport Layer Security
Developed by IETF to have an open standard similar to SSL
They are essentially the same, with minor differences
Both rely on use of digital certificates and PKI

31. Request client Certificate Change connection state
TLS/SSL Scenario 1
Hello
Client
Server
Hello
Server Certificate
Request client Certificate
Client Certificate
Client Key Exchange
Certificate Verify
Change connection state

32. TLS/SSL Scenario 1 Both the Server and the Client use certificates
Examples:
Secure exchange of electronic data between two servers
Very secure organizational network where each user gets issued a certificate

33. TLS/SSL Scenario 1
A Hello message is sent by the Client to notify the Server. The Hello message contains information about the protocols to be used for encryption and authentication.
The Server replies with its own Hello message confirming that it supports the protocols asked by the Client
Hello messages contain randomly-generated numbers to assure liveness
The Server Hello message contains an ID which will be used to match the responses to the requests
The Server sends its certificate to the Client, signed by a CA
The Server also sends a certificate request to obtain the Client’s certificate
After confirming that the Server certificate is valid, the Client sends its own certificate to the Server
A Key Exchange value is sent by the Client. This value is encrypted using the Server’s public key to prevent eavesdropping.
This value will be used by both sides as a seed to compute a symmetric secret key between Client and Server
The Certificate Verify message is sent by the Client to further prove its identity
It consists of a hash of all the messages sent and received so far, signed with the client’s secret key

34. Change connection state
TLS/SSL Scenario 2
Hello
Client
Server
Hello
Server
Authentication
Server Certificate
Client Key Exchange
Change connection state
Server Challenge
Client
Authentication
Client Response

35. TLS/SSL Scenario 2 Only the Server uses a certificate
The Client is authenticated by the server using an encrypted password technique
Examples:
Web e-commerce transactions
Web banking

36. Kerberos Scenario part 1
Key
Distribution
Centre (KDC)
Request Ticket, I am “A”, encrypted password
Client
Encrypted Ticket-Granting Ticket
Authentication
Service (AS)
Client and server share a secret key
The user enters a password which is encrypted using the secret key
The ticket-granting ticket (TGT) is an encrypted document similar to a certificate
It is encrypted using the secret key
It contains data to establish a session key for later communications with the KDC

37. Kerberos Scenario part 2
Key
Distribution
Centre (KDC)
Request Ticket for C, this is my TGT
Client
Encrypted Ticket for C
Ticket
Granting
Service (TGS)
Ticket for C
File or print
service
Client request a ticket to use C services
The ticket-granting service (TGS) verifies the validity of the TGT and issues a ticket for C
The ticket is encrypted using the session key derived in step 1
It contains a part only decipherable by C
A will now present the ticket to C which will grant access to resources

38. Notes on Kerberos
The method is widely used and supported by manufacturers such as Microsoft
The method can be susceptible to a dictionary attack since every subsequent step relies on the user entering the password in the first place
Kerberos is not only Authentication but also Authorization
A request for a resource may be denied, even if a user is valid
Based on policies in place

39. Conclusion Authentication is another critical step in security
Separates the “good guys” from the “bad guys”
If authentication is performed or bypassed by an attacker, the attacker will be considered by the system as a “good guy”
Very difficult to identify and expel
Must be performed at the beginning of a transaction and subsequently at regular intervals
Has mechanisms to prevent attacks:
Replay attacks
Password attacks (dictionary, brute-force)
As security administrators, NEVER rely on authentication alone
Part of a greater security policy
Use authorization and intrusion detection