1 / 36

Authentication Protocols

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.

tino
Download Presentation

Authentication Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Authentication Protocols 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? CSE 5349/7349

  3. Types of Authentication • Peer entity authentication • Prevent masquerading • Ensure freshness • Data origin authentication • Claims of data origin • Prevention of forgery We are dealing with Entity Authentication 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 CSE 5349/7349

  5. Simple Challenge-Response AP • A B: Na • B A: { Na }kab • One way protocol using shared secret key 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 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 CSE 5349/7349

  8. Attacks on AP • Crypto system • We have seen many of them • Protocol • Replay • Oracle session • Parallel session CSE 5349/7349

  9. CSE 5349/7349

  10. 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? CSE 5349/7349

  12. Digital Signature Algorithms 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 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 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 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)) 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 CSE 5349/7349

  18. Kerberos 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) 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) CSE 5349/7349

  21. Kerberos Database Server Server Ticket Granting Server Server Server Workstation Authentication Server 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. 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 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) 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. 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 CSE 5349/7349

  27. Authentication Server • The client sends a plaintext request to the ASasking 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. 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. 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. Sealed with TGS key Ticket: login name TGS name net address TGS session key TGS session key Sealed with user key 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. CSE 5349/7349

  31. Accessing a Server • 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: sealed with TGS key TGS Ticket Authenticator sealed with session key Server Name CSE 5349/7349

  32. TGS response • The TGSdecrypts the ticket using its secret key. Inside is the TGS session key. • The TGSdecrypts 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. 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. 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. CSE 5349/7349

  35. Requirements • Secure • Reliable • Transparent • Scalable CSE 5349/7349

  36. Problems • Single point of failure • Denial-of-service attack • Traffic • Reliability will compromise security CSE 5349/7349

More Related