X.509 Topics PGP S/MIME Kerberos

Directory Authentication Framework X.509 is part of the ISO X.500 directory standard. used by S/MIME, SSL, IPSec, and others 1) a standard certificate format Important Components of X.509 2) a standard scheme for implementing certificate authorities 3) standard authentication protocols 4) a digital signature “ standard ” no particular cipher is dictated, but RSA is recommended no particular hash is dictated.

Version Certificate Serial # Dig. Sig. (algorithm & parameters) Issuer name (CA) Start Date End Date Subject name Public Key (algorithm & parameters) Public Key Issuer ID Subject ID Extensions Dig. Sig. (algorithm & parameters) Digital Signature

Simple authentication occurs when two subjects are issued certificates from one CA. CAs issue certificates to subjects. Example A BC D Ole Lena Sven Notation A, B, C, and D are CAs. Ole, Sven and Lena are subjects Certificate: Issuer «Subject» D «Ole»D «Sven» C «Lena» Suppose Ole wants to validate Sven.... but what if Ole wants to send a message to Lena? A subject can transmit his/her certificate to a different subject.

Example (cont ’ d) A BC D Ole Lena Sven Notation A, B, C, and D are CAs. Ole, Sven and Lena are subjects Certificate: Issuer «Subject» D «Ole»D «Sven» C «Lena» For Ole to validate Lena B «D» D «B» General authentication requires CAs to exchange certificates, supporting certificate chaining. A «B» B «A» A «C» C «A» Note: two kinds of certificates: forward - holder is subject, issuer is another CA reverse - holder is issuer, subject is another CA He obtains ___________ & validates B as a CA using D ’ s public key. He obtains ___________ & validates A as a CA using B ’ s public key. He obtains ___________ & validates C as a CA using A ’ s public key. He obtains ___________ & validates Lena using C ’ s public key. Certificate Chain:

Assume that Ole wishes to authenticate Lena. There are three possible protocols. One Way Notation Sig denotes a digital signature (an MD encrypted with the sender ’ s private key) TimeStamp consists of optional generation time and expiration time nonce is a random number unique until expiration time TimeStamp 1 || nonce 1 || ID Lena || Sig || E(SessionKey, K LenaPub ) OleLena This establishes a) the integrity of the message b) the identity of the sender (Ole) c) that the message is intended for Lena (confidentiality) Notes: 1) a message could also be sent this way (protected by Sig). 2) session key is optional.

Two Way TimeStamp 1 || nonce 1 || ID Lena || Sig || E(SessionKey, K LenaPub ) OleLena This establishes additionally a) the integrity of the reply b) the identity of the receiver (Lena) c) that the message is intended for Ole OleLena TimeStamp 2 || nonce 2 || ID Ole || Sig || E(SessionKey, K OlePub ) Three Way TimeStamp 1 || nonce 1 || ID Lena || Sig || E(SessionKey, K LenaPub ) OleLena OleLena TimeStamp 2 || nonce 2 || ID Ole || nonce 1 || Sig || E(SessionKey, K OlePub ) OleLena nonce 2 || Sig This echos nonces to avoid replay w/o time stamps.

PGP created by Phil Zimmerman widely-used secure standard 1996 purchased by Network Associates Brief History Ring of Trust Each user maintains a trusted keyring (public keys) and an owned keyring (private keys). Keys may be retrieved from a server or included at the end of a message. Each key is signed by owner (and possibly others). Trust is based on who signed the key. Subject discretion ultimately determines who to trust. Keys can be revoked by the owner.

create a random session key (for symmetric cipher) encrypt/decrypt session key using public key (RSA or Diffie-Hellman) encrypt/decrypt message using session key (IDEA, 3DES or CAST-128) Potential PGP Operations generate & encrypt (or decrypt) MD (SHA-1) using private key attach encrypted session key (as a digital signature) to a message transmit message

Private Key Ring Time Stamp Key ID Public Key (of pair) Private Key (of pair) User ’ s ID least significant 64 bits of public key usually the user ’ s address Public Key Ring Time Stamp Key ID Public Key (of pair) User ’ s ID

PGP uses the concept of a one-time session key Typical Message Format (from Lena to Ole) ID of K OlePub E( SessionKey, K OlePub ) Timestamp ID of K LenaPub Leading two octets of MD E( MD, K LenaPriv ) File Name Timestamp Data This part is first compressed (zip) then encrypted with SessionKey The entire transmission is encoded in radix-64.

Why use a one-time (session) key?

Certificate Processing Uses X.509v3 certificates S/MIME -- Secure / Multipurpose Internet Mail Extensions Originally developed by RSA Responsibility for maintaining certificates is local. Certificates are signed by a Certificate Authority Typical Functions The client must generate keys. A pair of generated keys are registered with a CA. The CA supplies certificates in X.509 format. The client can maintain a list of trusted certificates. CAs - VeriSign, GTE, Nortel, U.S. Postal Service

Class 1 Class 2 Class 3 Algorithms must support SHA-1 (should support MD5 for backward compatibility) must support DSS (should support RSA-512 and RSA-1024 for digital signatures) must support RC2/40 with one-time key and should support 3DES session key encryption with Diffie-Hellman is preferred (RSA is possible) VeriSign Certificates Classes VeriSign required unambiguous name and address, PIN is ed to user VeriSign does online database search and sends digital ID & PIN to postal address Client must prove identity via notary public or appear in person Web browsers, online subscriptions, secure banking, secure database, membership-based services, e-commerce

Kerberos is an authentication system - authenticating users and services. It was originally developed as part of Project Athena - MIT. Kerberos relies upon a centralized Kerberos server per realm. A kerberos server must contain a database of user IDs and hashed passwords. A kerberos server must share a secret key with registered servers. Multi-realm communication is also possible. The client can maintain a list of trusted certificates.

Weaknesses Alternative 1 Notation Ole is the client AS is the authentication/Kerberos server pwd C is the password for C IP C is the IP address of C key S key shared by AS and server S ID Ole || pwd Ole || ID S ) Ole AS Ole AS Ticket S == Ole S Ticket || ID Ole E( ID Ole || IP Ole || ID s, key S )

Weaknesses 1) lifetime 2) server is never authenticated to the client Alternative 2 ID Ole || ID TGS Ole AS Ole AS Ticket TGS OleTGS ID Ole || ID S || Ticket TGS E( ID Ole || IP Ole || ID TGS || Lifetime 1 || TimeStamp 1, key Ole ) login TGS -- ticket granting server OleTGS Ticket S E( ID Ole || IP Ole || ID S || Lifetime 1 || TimeStamp 2, key s ) key based on Ole ’ s pwd to obtain service Ole S ID Ole || Ticket S once per service session

Version 4 protocol ID Ole || ID TGS || TimeStamp 1 Ole AS Ole AS OleTGS ID S || Ticket TGS || E( ID Ole || IP Ole || TimeStamp 3, key Ole&TGS ) E( Key Ole&TGS || ID Ole || IP Ole || ID TGS || TimeStamp 2 || Lifetime 2, key TGS ) login OleTGS E( Key Ole&S || ID Ole || IP Ole || ID S || TimeStamp 4 || Lifetime 4, key s ) to obtain service Ole S once per service session E( Key Ole&TGS || ID TGS || TimeStamp 2 || Lifetime 2 || Ticket TGS, key Ole ) Ticket TGS == E( Key Ole&S || ID S || TimeStamp 4 || Ticket S, key Ole&TGS ) Ticket S == Ticket S || E( ID Ole || IP Ole || TimeStamp 5, key Ole&S ) Ole S E( 1 + TimeStamp 5, key Ole&S )

Version 5 protocol Ole S once per service session Options || Ticket S || E( ID Ole || Realm Ole || TimeStamp 2 || subkey || seq#, key Ole&S ) Ole S E( TimeStamp 5 || subkey || seq#, key Ole&S ) Options || ID Ole || Realm Ole || ID TGS || Times || Nonce 1 Ole AS Ole AS E( Flags || Key Ole&TGS || Realm Ole || ID Ole || IP Ole || ID TGS || Times, key TGS ) login E( Key Ole&TGS || Times || Nonce 1 || Realm TGS || ID TGS, key Ole ) Ticket TGS == Realm Ole || ID Ole || Ticket TGS || OleTGS Options || ID S || Times || Nonce 2 || Ticket TGS || E( ID Ole || Realm Ole || TimeStamp 1, key Ole&TGS ) OleTGS E( Flags || Key Ole&S || Realm || ID Ole || IP Ole || Times, key s ) to obtain service E( Key Ole&S || Times || Nonce 2 || Realm S || ID S, key Ole&TGS ) Ticket S == Realm Ole || ID Ole || Ticket S ||

Version 4 required the use of DES - Version 5 supports the use of algorithm tags Version 4 used an 8-bit lifetime - restricted to approx. 21 hrs. - Version 5 more flexible. Version 5 also adds realms Both versions are somewhat vulnerable to password attacks, because keys are based on passwords.