authentication protocols
DESCRIPTION
Authentication Protocols. The Premise. How do we use perfect cryptographic mechanisms (signatures, public-key and symmetric key encryption, hash functions, MACs) to design secure protocols (providing security services) over an un-trusted network?. Types of Authentication. - PowerPoint PPT PresentationTRANSCRIPT
SMU CSE 5349/7349 1
Authentication Protocols
SMU CSE 5349/7349 2
The Premise How do we use perfect
cryptographic mechanisms (signatures, public-key and symmetric key encryption, hash functions, MACs) to design secure protocols (providing security services) over an un-trusted network?
SMU CSE 5349/7349 3
Types of Authentication• Peer entity authentication
– Prevent masquerading– Ensure freshness
• Data origin authentication– Claims of data origin– Prevention of forgeryWe are dealing with Entity
Authentication
SMU CSE 5349/7349 4
Definitions• Entity authentication:
– Corroboration that an entity is the one claimed at a particular point in time.
• Unilateral authentication:– Provides one entity with assurance of the
other’s identity but not vice versa.• Mutual authentication:
– Provides both entities with assurance of each other’s identity
SMU CSE 5349/7349 5
Simple Challenge-Response AP
1. A B: Na
2. B A: { Na }kab
One way protocol using shared secret key
SMU CSE 5349/7349 6
Mutual Authentication Using Needham-Schroeder (shared key)
• M1 A -> S A, B, Na • M2 S -> A EKas{Na , B, Kab, EKbs{Kab, A} }• M3 A -> B EKbs{Kab, A} • M4 B -> A EKab{Nb} • M5 A-> B EKab{Nb-1}
– Na is a random value chosen by A, Nb random chosen by B
SMU CSE 5349/7349 7
NS – Public Key• KDC has well known public key• B’s public received from KDC• Challenge – response as before
– We saw this in last class
SMU CSE 5349/7349 8
Attacks on AP• Crypto system
– We have seen many of them• Protocol
– Replay– Oracle session– Parallel session
SMU CSE 5349/7349 9
SMU CSE 5349/7349 10
SMU CSE 5349/7349 11
Fix for Replay Attack• Use time stamps
– Needs securely synchronised clocks to prevent replay – not trivial
– Drift window– Log of recent messages within the
window– Logical time stamps?
SMU CSE 5349/7349 12
Digital Signature Algorithms
SMU CSE 5349/7349 13
Need for DS• No complete trust between the
sender and the receiver • Properties:
– Able to verify the author, time– Authenticate the content at time of
signature– Signature verifiable by a third party
• Direct and arbitrated
SMU CSE 5349/7349 14
Use of RSA• When using RSA for both encryption and
authentication: – Use the senders private key to sign the
message – Use the recipients public key to encrypt the
message • RSA can be used without increasing
message size • More commonly use a hash function to
create a digest which is then signed – Send this signed digest separate
SMU CSE 5349/7349 15
DSA (Digital Signature Algorithm)
• US Federal Govt. approved signature scheme – used with SHA hash algorithm
• Designed by NIST & NSA in early 90's • DSA is the algorithm, DSS is the standard • DSA is a variant on the ElGamal and
Schnorr algorithms – Creates a 320 bit signature– Security again rests on difficulty of computing
discrete logarithms – Has been quite widely accepted
SMU CSE 5349/7349 16
Keyed Hash Functions• All the above signature schemes involve
public key methods – Cost and size overheads
• Have a need for a private key signature scheme – Use a fast hash function
• Include a key along with the message:– KeyedHash = Hash(Key|Message) – KeyedHash = Hash(Key1|Hash(Key2|
Message))
SMU CSE 5349/7349 17
HMAC• Use a keyed hash function
HMACK = Hash((K+ XOR opad)||Hash((K+ XOR ipad)||M))
– where K+ is the key padded out to size – opad, ipad are specified padding values
• Security is directly related to the security of the underlying hash
• Any of MD5, SHA-1, RIPEMD-160 hash algorithms can be used
SMU CSE 5349/7349 18
Kerberos
SMU CSE 5349/7349 19
Kerberos• Trusted 3rd party authentication scheme.• Assumes that hosts are not trustworthy.• Requires that each client (each request for
service) prove its identity.• Does not require user to enter password every
time a service is requested
Part of project Athena (MIT)
SMU CSE 5349/7349 20
Kerberos Design• User must identify itself once at the
beginning of a session• Every user has a password.• Every service has a password.• The only entity that knows all the passwords
is the Authentication Server• Passwords are never sent across the
network in clear-text (or stored in memory)
SMU CSE 5349/7349 21
ServerServerServerServerServerServerServerServer
KerberosKerberosDatabaseDatabase
Ticket GrantingTicket Granting ServerServer
AuthenticationAuthentication ServerServer
WorkstationWorkstation
SMU CSE 5349/7349 22
Components
• Encryption• Current Kerberos implementations (v4) use DES, although
Kerberos V5 has hooks so that other algorithms can be used• Tickets
• Each request for a service requires a ticket.• A ticket provides a single client with access to a single server• Tickets are dispensed by the “Ticket Granting Server” (TGS),
which has knowledge of all the encryption keys• Tickets are meaningless to clients, they simply use them to
gain access to servers.
SMU CSE 5349/7349 23
Components - Tickets (cont’d)• The TGS seals (encrypts) each ticket with the secret
encryption key of the server.• Sealed tickets can be sent safely over a network -
only the server can make sense out of it.• Each ticket has a limited lifetime (a few hours)• Ticket Contents
• Client name (user login name)• Server name• Client Host network address• Session Key for Client/Server• Ticket lifetime • Creation of timestamp
SMU CSE 5349/7349 24
Components -Session Key
•Random number that is specific to a session.
•Session Key is used to seal client requests to server
•Session Key can be used to seal responses (application specific usage)
SMU CSE 5349/7349 25
Authenticators• Authenticators prove a client’s identity.• Includes:
– Client user name.– Client network address.– Timestamp.
• Authenticators are sealed with a session key.
SMU CSE 5349/7349 26
Bootstrap• Each time a client wants to contact a server, it
must first ask the 3rd party (TGS) for a ticket and session key.
• In order to request a ticket from the TGS, the client must already have a TG ticket and a session key for communicating with the TGS
SMU CSE 5349/7349 27
Authentication Server• The client sends a plaintext request to the AS
asking for a ticket it can use to talk to the TGS.• Request:
– login name– TGS name
Since this request contains only well-known names, it does not need to be sealed.
SMU CSE 5349/7349 28
Authentication Server• The AS finds the keys corresponding to the
login name and the TGS name.• The AS creates a ticket:
– login name– TGS name– client network address– TGS session key
• The AS seals the ticket with the TGS secret key.
SMU CSE 5349/7349 29
Authentication Server Response• The AS also creates a random session key for
the client and the TGS to use.• The session key and the sealed ticket are
sealed with the user (login name) secret key.
TGS session key
Ticket:login nameTGS namenet addressTGS session key
Sealed with user keySealed with user key
Sealed with TGS keySealed with TGS key
SMU CSE 5349/7349 30
Accessing the TGS• The client decrypts the message using
the user’s password as the secret key.• The client now has a session key and
ticket that can be used to contact the TGS.
• The client cannot see inside the ticket, since the client does not know the TGS secret key.
SMU CSE 5349/7349 31
• When a client wants to start using a server (service), the client must first obtain a ticket.
• The client composes a request to send to the TGS:
Accessing a Server
TGS Ticket
Authenticator
Server Name
sealed withsealed withTGS keyTGS key
sealed withsession key
SMU CSE 5349/7349 32
TGS response• The TGS decrypts the ticket using its secret key.
Inside is the TGS session key.• The TGS decrypts the Authenticator using the
session key.• The TGS check to make sure login names, client
addresses and TGS server name are all OK.• TGS makes sure the Authenticator is recent.
SMU CSE 5349/7349 33
TGS ResponseOnce everything checks out - the TGS:• Builds a ticket for the client and requested
server. The ticket is sealed with the server key.
• Creates a session key• Seals the entire message with the TGS session
key and sends it to the client.
SMU CSE 5349/7349 34
Client Accesses Server• The client now decrypts the TGS response
using the TGS session key.• The client now has a session key for use with
the new server, and a ticket to use with that server.
• The client can contact the new server using the same format used to access the TGS.
SMU CSE 5349/7349 35
Requirements• Secure• Reliable• Transparent• Scalable
SMU CSE 5349/7349 36
Problems• Single point of failure
– Denial-of-service attack• Traffic• Reliability will compromise security