Transcript Session 3

IP Security – Session 3 – AAA
[email protected]
www.iitelecom.com
© Institut international des télécommunications., 2005
Authentication, Authorization and Accounting
Authentication:


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:
–
–
2
© IITelecom,
2005
Keeping a trace for security audits
Charging customers for resources usage (ISP)
Generic Authentication Scenario
Client
I need access
Server
Authenticate yourself
I am “A”
Query “A” ?
Yes / No
Access granted / denied
Shared secret
3
© IITelecom,
2005
Database
(local or
remote)
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


4
© IITelecom,
2005
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
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
–
–
–

5
© IITelecom,
2005
Fingerprint
Retina and iris scan
DNA?
Biometric data is used as a token, similar to token-based
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


6
© IITelecom,
2005
Password + Token: two-factor authentication
PIN + ID card + Biometric data: three-factor authentication
Password Authentication Scenario 1
Client
I need access
Server
Authenticate yourself
I am “A”, password “QWERTY”
“A” password “QWERTY”?
Yes / No
Access granted / denied



7
© IITelecom,
2005
Shared secret: password
This scenario is not secure: password is sent in plaintext
Used by PAP (Password Authentication Protocol)
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)
–
8
© IITelecom,
2005
PAP is no longer used because considered not secure
PAP (cont.)
IIT
NAS
Alice
Protocol
0XC023=PAP
Code
1 byte
Information
Identifier
Length
Host ID Size
9
© IITelecom,
2005
Padding
ID = Alice, Password = ???
Authenticate-Ack or Authenticate-Nak
Data
Host ID
Password Size
Password
Password Authentication Scenario 2
Client
I am “A”, I need access
Server
CHAP Challenge: H6ty”1@!p
Compute Response
CHAP Response: Answer: 89it%-QkL
Query “A”’s password
Compute response
CHAP Access granted / denied




10
© IITelecom,
2005
Match?
Shared secret: password
Challenge by B: randomly generated number
Response by A: Hash of (Password + Random Challenge)
Used by CHAP (Challenge Handshake Authentication Protocol)
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
–

Hash method used by CHAP is MD5
–
11
© IITelecom,
2005
Both the challenge and the response are visible
RFC 1321
CHAP (cont.)

CHAP challenge:
–
–
–

CHAP response:
–
–
–
12
© IITelecom,
2005
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
ID number (same as the one in challenge)
Response value = MD5 (ID + Password + Random value provided in
challenge)
Username of user requesting access
CHAP (cont.)
IIT
NAS
Alice
ID, Random Number, IIT
ID, Pwd, Random No.
MD5
Hash response
ID, Hash response, Alice
Protocol
0xC223=CHAP
Information
ID, Pwd, Random No.
Padding
MD5
Hash Value, match?
Code
Identifier
Length
Value-Size
13
© IITelecom,
2005
Success or Failure
Data
Value
Name
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
Remote Access
Server
Remote Access
Server
14
© IITelecom,
2005
IP Network
Authentication Server
(central user database)
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
Authenticator
Client
(Supplicant)
IP Network
Authentication Server
15
© IITelecom,
2005
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
16
© IITelecom,
2005
RADIUS Scenario 1 (cont.)




17
© IITelecom,
2005
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 AccessRequest 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
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
18
© IITelecom,
2005
RADIUS Scenario 2 (cont.)

The Authenticator, upon request, sends to the Authentication Server a
RADIUS Access-Request.
–



19
© IITelecom,
2005
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
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
–

20
© IITelecom,
2005
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
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

21
© IITelecom,
2005
The evolution of PAP and CHAP: EAP



22
© IITelecom,
2005
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
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
Authenticator
Token in EAP
Kerberos in EAP
TLS in EAP
23
© IITelecom,
2005
IP Network
EAP in RADIUS
Authentication Server
Token Authentication Scenario 1
Client
Server
I am “A”, Password: 89it%-QkL
Token Card


24
© IITelecom,
2005
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
Token Authentication Scenario 1

The server (B) maintains an internal clock upon which is derived a secret
key
–






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:
–
–
25
© IITelecom,
2005
This token method is known as synchronous
Clock drift, server must compensate
Battery life in token card: token must be replaced when battery is dead
Token Authentication Scenario 2
I am “A”
Client
Server
Challenge: 654B21A
Response: 89it%-QkL
Access granted / denied
Token Card


26
© IITelecom,
2005
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
Token Authentication Scenario 2

No clocks in A or B
–


The token card is used to compute the response to the challenge
Problems with asynchronous token system:
–
27
© IITelecom,
2005
This token method is known as asynchronous
Less practical, requires multiple steps
Upper-Layer Authentication


In many cases, authentication is not required for access to low-level
network resources but rather for other applications
Example:
–
–
–

To allow authentication to happen, upper-layer authentication exists:
–
–
–

28
© IITelecom,
2005
Secure Web site for e-commerce
Access to a remote database
Access to a file or print server
IPSec (Layer 3 – IP)
SSL and TLS (Layer 4 – Transport)
Kerberos
The upper-layer protocols rely on Cryptographic Authentication Methods
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
29
© IITelecom,
2005
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Security Parameters Index (SPI)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Payload Data* (variable)
|
~
~
|
|
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
Padding (0-255 bytes)
|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| Pad Length
| Next Header
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication Data (variable)
|
~
~
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SSL and TLS


RFC 2246
SSL is Secure Socket Layer
–

TLS is Transport Layer Security
–


30
© IITelecom,
2005
Developed by Netscape for secure web transactions
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
TLS/SSL Scenario 1
Hello
Client
Server
Hello
Server Certificate
Request client Certificate
Client Certificate
Client Key Exchange
Certificate Verify
Change connection state
31
© IITelecom,
2005
TLS/SSL Scenario 1


Both the Server and the Client use certificates
Examples:
–
–
32
© IITelecom,
2005
Secure exchange of electronic data between two servers
Very secure organizational network where each user gets issued a certificate
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
–
–




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.
–

© IITelecom,
2005
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
–
33
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
It consists of a hash of all the messages sent and received so far, signed with
the client’s secret key
TLS/SSL Scenario 2
Hello
Client
Server
Hello
Server Certificate
Server
Authentication
Client Key Exchange
Change connection state
Server Challenge
Client Response
34
© IITelecom,
2005
Client
Authentication
TLS/SSL Scenario 2



Only the Server uses a certificate
The Client is authenticated by the server using an encrypted password
technique
Examples:
–
–
35
© IITelecom,
2005
Web e-commerce transactions
Web banking
Kerberos Scenario part 1
Request Ticket, I am “A”, encrypted password
Client
Key
Distribution
Centre (KDC)
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
–
–
36
© IITelecom,
2005
It is encrypted using the secret key
It contains data to establish a session key for later communications with the
KDC
Kerberos Scenario part 2
Request Ticket for C, this is my TGT
Client
Key
Distribution
Centre (KDC)
Encrypted Ticket for C
Ticket for C
Ticket
Granting
Service (TGS)
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
–
–

37
© IITelecom,
2005
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
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
–
–
38
© IITelecom,
2005
A request for a resource may be denied, even if a user is valid
Based on policies in place
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
–
–
39
© IITelecom,
2005
Part of a greater security policy
Use authorization and intrusion detection