CSCE 815 Network Security Lecture 10

1. CSCE 815 Network Security Lecture 10 Kerberos X.509 February 13, 2003

2. Version 4 Authentication Dialogue • Authentication Service Exchange, To obtain Ticket-Granting Ticket (1) C AS: IDc|| IDtgs ||TS1 (2) AS  C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs] • Ticket-Granting Service Exchange: To obtain Service-Granting Ticket • (3) C  TGS: IDv||Tickettgs ||Authenticatorc • TGS  C: EKc[Kc,¨v|| IDv || TS4 || Ticketv] • Client/Server Authentication Exchange: To Obtain Service • (5) C  V: Ticketv || Authenticatorc • (6) V  C: EKc,v[TS5 +1]

3. Kerberos 4 Overview Fig 4.1

4. Kerberos Realms • a Kerberos environment consists of: • a Kerberos server • a number of clients, all registered with server • application servers, sharing keys with server • this is termed a realm • typically a single administrative domain • if have multiple realms, their Kerberos servers must share keys and trust

5. Request for Service in Another Realm

6. Kerberos Version 5 • developed in mid 1990’s • provides improvements over v4 • addresses environmental shortcomings • encryption algorithm – v4 DES based, v5 tags ciphertext by type of encryption • IP dependence – v4 requires internet Protocol (IP), v5 general • byte order - v5 message defined using Abstract Syntax Notation(ASN.1) and encoded with Basic Encoding Rules (BER) • ticket lifetime – 8 bits (255)x five minutes = 21+ hours; v5 start/stop times • authentication forwarding: In v5 one server can forward credentials to another e.g., a print server can forward credentials to file server so that a file can be printed • interrealm authorization – In v4 n realms  n(n-1)/2 relationships • and technical deficiencies • specified as Internet standard RFC 1510

7. Kerberos Version 5 • V5 solves technical deficiencies of v4 • double encryption: tickets provided to clients are encrypted twice (fig 4.1) • PCBC encryption: v4 uses propagating block chaining (PCBC) - non-std and vulnerable to ciphertext block interchange attack • session keys – a key used by the client to encrypt the AS to the service; however it may be reused to gain access to the service again. V5 allows subsession keys to prevent replays. • password attacks – both versions are susceptible to attacks on the password. The message from the AS to the client is encrypted with a key based on the client’s password. This can be captured and then attempts to decrypt and figure out the password.

8. Kerberos Version 5 Message Exchanges • Table 4.3 • Authentication Service Exchange: to obtain the ticket-granting ticket • New additions • Realm of the user • Options • Times: from, till, renewTime • Nonce – random value to be repeated in response to insure freshness

9. Ticket-Granting Service Exchange • To obtain a service-granting ticket • Both versions include • Authenticator • a ticket • Name of the requested service • In addition v5 includes • Requested times for the ticket • Options for the ticket • And a nonce

10. Client/Server Authentication Exchange • To obtain service • Both versions include • Authenticator • Ticket • Name of the requested service • In addition v5 includes • Options for mutual authentication • Subkey – client’s choice of encryption key (default is Kc,v) • Sequence number – used to detect replays • Ticket Flags table 4.4

11. X.509 Authentication Service • part of CCITT X.500 directory service standards • distributed servers maintaining some user info database • defines framework for authentication services • directory may store public-key certificates • with public key of user • signed with private key by certification authority • also defines authentication protocols • uses public-key cryptogrraphy & digital signatures • algorithms not standardised, but RSA recommended • Used in a variety of contexts • S/MIME chapter 5 • IP secuirty chapter 6 • SSL/TLS, SET chapter 7

12. X.509 Certificates • issued by a Certification Authority (CA), containing (fig 4.3): • version (1, 2, or 3) • serial number (unique within CA) identifying certificate • signature algorithm identifier and parameters • issuer X.500 name (CA) • period of validity (from - to dates) • subject X.500 name (name of owner) • subject public-key info (algorithm, parameters, key) • issuer unique identifier (v2+) • subject unique identifier (v2+) • extension fields (v3) • signature (of hash of all fields in certificate) • notation CA<<A>> denotes certificate for A signed by CA

13. X.509 Certificates

14. Obtaining a Certificate • any user with access to CA can get any certificate from it • only the CA can modify a certificate • because cannot be forged, certificates can be placed in a public directory

15. CA Hierarchy • if both users share a common CA then they are assumed to know its public key • otherwise CA's must form a hierarchy • use certificates linking members of hierarchy to validate other CA's • each CA has certificates for clients (forward) and parent (backward) • each client trusts parents certificates • enable verification of any certificate from one CA by users of all other CAs in hierarchy

16. CA Hierarchy Use

17. Certificate Revocation • certificates have a period of validity • may need to revoke before expiry, eg: • user's private key is compromised • user is no longer certified by this CA • CA's certificate is compromised • CA’s maintain list of revoked certificates • the Certificate Revocation List (CRL) • users should check certs with CA’s CRL

18. Authentication Procedures • X.509 includes three alternative authentication procedures: • One-Way Authentication • Two-Way Authentication • Three-Way Authentication • all use public-key signatures

19. One-Way Authentication • 1 message ( A->B) used to establish • the identity of A and that message is from A • message was intended for B • integrity & originality of message • message must include timestamp, nonce, B's identity and is signed by A

20. Two-Way Authentication • 2 messages (A->B, B->A) which also establishes in addition: • the identity of B and that reply is from B • that reply is intended for A • integrity & originality of reply • reply includes original nonce from A, also timestamp and nonce from B

21. Three-Way Authentication • 3 messages (A->B, B->A, A->B) which enables above authentication without synchronized clocks • has reply from A back to B containing signed copy of nonce from B • means that timestamps need not be checked or relied upon

22. X.509 Version 3 • has been recognised that additional information is needed in a certificate • email/URL, policy details, usage constraints • rather than explicitly naming new fields defined a general extension method • extensions consist of: • extension identifier • criticality indicator • extension value

23. Certificate Extensions • key and policy information • convey info about subject & issuer keys, plus indicators of certificate policy • certificate subject and issuer attributes • support alternative names, in alternative formats for certificate subject and/or issuer • certificate path constraints • allow constraints on use of certificates by other CA’s

24. Summary • have considered: • Kerberos trusted key server system • X.509 authentication and certificates