authentication protocols
Post on 13-Jan-2016
35 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
ServerServerServerServerServerServerServerServer
KerberosKerberosDatabaseDatabase
Ticket GrantingTicket Granting ServerServer
Ticket GrantingTicket Granting ServerServer
AuthenticationAuthentication ServerServer
AuthenticationAuthentication ServerServer
WorkstationWorkstationWorkstationWorkstation
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 Response
Once 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
top related