Network Information Security 网络信息安全 No. 7: Authentication Applications Instructor: Lu Bin 鲁斌 Tel: 7525260 Email: binlu 714@yahoo. com. cn Office: Room B 404, Teaching building 10#
Outline l Security Concerns l Kerberos l Public Key Infrastructure (PKI) 2
Security Concerns l l l key concerns are confidentiality and timeliness to provide confidentiality must encrypt identification and session key info which requires the use of previously shared private or public keys need timeliness to prevent replay attacks provided by using sequence numbers or timestamps or challenge/response 3
Kerberos In Greek mythology, a many headed dog, the guardian of the entrance of Hades 4
Kerberos l Users wish to access services on servers. l Three threats exist: ¡ User pretend to be another user. ¡ User alter the network address of a workstation. ¡ User eavesdrop on exchanges and use a replay attack. 5
Kerberos l l l trusted key server system from MIT Provides a centralized authentication server to authenticate users to servers and servers to users. Relies on conventional encryption, making no use of public-key encryption two versions in use: 4 & 5 Version 4 makes use of DES 6
Kerberos Requirements l first published report identified its requirements as: ¡ security ¡ reliability ¡ transparency ¡ scalability l implemented using an authentication protocol based on Needham-Schroeder 7
Kerberos Overview la basic third-party authentication scheme l have an Authentication Server (AS) ¡ users initially negotiate with AS to identify self ¡ AS provides a non-corruptible authentication credential (ticket granting ticket TGT) l have a Ticket Granting server (TGS) ¡ users subsequently request access to other services from TGS on basis of users TGT 8
Kerberos Overview l Terms: ¡ ¡ ¡ ¡ ¡ C = Client AS = authentication server V = server IDc = identifier of user on C IDv = identifier of V Pc = password of user on C ADc = network address of C Kv = secret encryption key shared by AS an V TS = timestamp || = concatenation 9
A Simple Authentication Dialogue (1) C AS: IDc || Pc || IDv (2) AS C: Ticket (3) C V: IDc || Ticket = EKv[IDc || ADc || IDv] 10
Improved authentication Dialogue Once per user logon session: (1) C AS : IDc || IDtgs (2) AS C : EKc [ Tickettgs ] l Once per type of service: (3) C TGS: IDc||IDv||Tickettgs (4) TGS C: Ticket. V l Once per service session: (5) C V: IDc || Ticket. V l Tickettgs = EKtgs [ IDc || ADc || IDtgs || TS 1 || Lifetime 1] Ticket. V = EKV [ IDc || ADc || IDV || TS 2 || Lifetime 2] 11
The client requests a ticket-granting ticket on behalf of the user by sending its User’s ID to the AS, together with the TGS ID, indicating a request to use the TGS service (2) AS responds with a ticket that is encrypted with a key that is derived from the user’s password when this response arrives at the client, the client prompts the user for his/her password, generates the key, and attempts the decrypt the incoming message. If the correct password is supplied, the ticket is successfully recovered. (1) 12
(3) The client requests a service-granting ticket on behalf of the user and transmits a message to TGS containing the user’s ID, the ID of the desired service, and the ticket-granting ticket (4) TGS decrypts the incoming ticket and verifies the success of the decryption by the presence of its ID. It checks to make sure that the lifetime has not been expired (5) Client requests access to a service on behalf of the user, and transmits a message to the server containing the user’s ID and the service-granting ticket. The server authenticates by using the contents of the ticket. 13
Problems l Lifetime associated with the ticket-granting ticket too short repeatedly asked for password ¡ If too long greater opportunity to replay ¡ If l The threat is that an opponent will steal the ticket and use it before it expires 14
Kerberos Version 4 15
Version 4 Authentication Dialogue Authentication Service Exhange: To obtain Ticket-Granting Ticket (1) C AS: IDc || IDtgs ||TS 1 (2) AS C: EKc [Kc, tgs|| IDtgs || TS 2 || Lifetime 2 || Tickettgs] Tickettgs = EKtgs[Kc, tgs || IDC || ADC || IDtgs || TS 2 || Lifetime 2 ] Ticket-Granting Service Echange: To obtain Service-Granting Ticket (3) C TGS: (4) TGS C: IDv ||Tickettgs ||Authenticatorc EKc, tgs [Kc, v || IDv || TS 4 || Ticketv] Ticket. V = EKv [KC, V || IDC || ADC || IDV || TS 4 || Lifetime 4 ] Authenticator. C = EKc, tgs [ IDC || ADC || TS 3 ] 16
Version 4 Authentication Dialogue Client/Server Authentication Exhange: To Obtain Service (5) C V: (6) V C: Ticketv || Authenticatorc EKc, v[TS 5 +1] Authenticator. C = E Kc, v [ IDC || ADC || TS 5 ] Ticket. V ＝ EKv[KC, V || IDC || ADC || IDV || TS 4 || Lifetime 4 ] 17
Kerberos Realms la Kerberos environment consists of: ¡a Kerberos server ¡ a number of clients, all registered with server ¡ application servers, sharing keys with server l this is termed a realm ¡ typically a single administrative domain l if have multiple realms, their Kerberos servers must share keys and trust 18
Request for Service in Another Realm (1) C AS : IDC || IDtgs || TS 1 (2) AS C : EKc[Kc, tgs || IDtgs || TS 2 || Lifetime 2 || Tickettgs] (3) C TGS : IDrem || Tickettgs ||Authenticator. C (4) TGS C : Kc, tgs [KC, tgsrem || IDtgsrem || TS 4 || Tickettgsrem ] (5) C TGSrem : IDVrem || Tickettgsrem ||Authenticator. C (6) TGSrem C : Kc, tgsrem [KC, Vrem || IDVrem || TSb || Ticket. Vrem ] (7) C Vrem : Ticket. Vrem || Authenticator. C 19
Kerberos Version 5 l developed in mid 1990’s l provides improvements over v 4 ¡ addresses l encryption alg, network protocol, byte order, ticket lifetime, authentication forwarding, interrealm auth ¡ and l environmental shortcomings technical deficiencies double encryption, non-std mode of use, session keys, password attacks l specified as Internet standard RFC 1510 20
Difference Between Version 4 and 5 l Encryption system dependence ¡ V. 4 requires DES ¡ V. 5 is tagged with an encryption type identifier so that any encryption technique may be used, key is tagged with a type and a length, allowing the same key to be used in different algorithm and allowing the specification of different variations on a given algorithm 21
l Internet ¡ ¡ l protocol dependence V. 4: use of Internet Protocol(IP) address V. 5: networks are tagged with type and lengths, allowing any network address type to be used. Message byte ordering V. 4: employ a byte ordering and tags the message to indicate least significant byte in lowest address or most significant byte in lowest address. ¡ V. 5: all messages structures are defined using Abstract Syntax Notation One(ASN. 1) and Basic Encoding Rules(BER). ¡ 22
l Ticket lifetime ¡ V. 4: encoded in an 8 -bit quantity in units of five minutes. Thus maximum lifetime=1280 minutes ¡ V. 5: tickets include an explicit start time and end time, allowing tickets with arbitrary lifetime. l Authentication forwarding ¡ V. 4: does not allow credential issued to one client to be forwarded to some other host and used by other client ¡ V. 5: allow 23
l Interrealm authentication ¡ V. 4: Interoperability among N realms requires on the order of N(N-1)/2 Kerberos-to-Kerberos relationship ¡ V. 5: support a method that requires fewer relationships 24
Kerberos in practise l Currently have two Kerberos versions: 4 : restricted to a single realm ¡ 5 : allows inter-realm authentication ¡ Kerberos v 5 is an Internet standard ¡ specified in RFC 1510, and used by many utilities ¡ l To use Kerberos: need to have a KDC on your network ¡ need to have Kerberised applications running on all participating systems ¡ major problem - US export restrictions ¡ 25
Public Key Infrastructure (PKI) l Public Key Certificate (PKC) l PKI components l Certification creation steps l Certificate hierarchies l Obtaining a certificate l Certificate revocation 26
l Q: How to authenticate the association between the public key with the owner ? l A: Public Key Certificate ¡ X. 509 standard 27
Public key certificate l A public key certificate signifies the association between my public key and me ¡ Ex. Like a driver license or passport Q: Who can approve the association ? A: A trusted entity – Certificate Authority (CA) Q: What is the content of a digital certificate? A: X. 509 standard 28
X. 509 Certificates l issued by a Certification Authority (CA), containing: ¡ ¡ ¡ l version (1, 2, or 3) serial number (unique within CA) identifying certificate signature algorithm identifier 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 (v 2+) subject unique identifier (v 2+) extension fields (v 3) signature (of hash of all fields in certificate) notation CA<<A>> denotes certificate for A signed by CA 29
X. 509 Certificates 30
Example: Digital certificate 31
X. 509 certificate format 公钥 32
X. 509 V 2 extensions: unique identifier l V 2 extensions: Issuer unique identifier ¡ Subject unique identifier ¡ l Motivation: Deal with the possibility that the issuer (CA’s name) name and the subject name (certificate holder’s name) might be duplicated over time 33
X. 509 V 3 certificate extensions Certificate Revocation List Certificate policies Key usage: 1. digital signature 2. Certificate signing 3. CRL signing 4. Key enciphering 5. Data enciphering 6. Diffie-Hellman key exchange 34
Certificate Authority 35
PKI components l The interaction between PKI components ¡ ¡ ¡ End user Registration authority (RA) CA Key recovery server X. 500 directory 36
Registration authority (RA) l an intermediate entity between the end users and the CA ¡ Share the workload of CA l l l ¡ Accept and verify registration info about new users Generate keys on behalf of the end users Accept and authorize requests for key backups and recovery Accept and authorize requests for certificate revocation RA does not generate certificate CA becomes an isolated entity, which makes it less susceptible to security attacks 37
Key recovery server Q: End users lose their private keys? l A 1: CA must revoke the corresponding PKC, a new key pair must be generated, a new corresponding PKC must be created l A 2: provide a key recovery server ¡ CA backs up private keys at the time of creation l 38
Certificate directory Q: where to store the certificates? l A 1: end user stores on his local machine l A 2: CAs use a certificate directory (or a central storage location) ¡ Provide a single point for certificate administration and distribution (ex. for later certificate revocation) l 39
Certificate creation steps Key generation Registration Verification Certificate creation 40
1. Subject generating his own key pair 2. RA generating a key pair for subject ① RA knows private key! ② How to transmit it to user? 41
Registration & Verification l l RA verify the user’s credentials Check the Proof of Possession of the private key 42
Certificate creation l CA creates a digital certificate for the user ¡ Certificates in X. 509 standard format ¡ Q: Why should we trust digital certificates? l Certificate goes to ¡ RA (or user) ¡ Certificate directory ¡ Backup user private key (if necessary) 43
CA Hierarchy if both users share a common CA then they are assumed to know its public key l otherwise CA's must form a hierarchy l use certificates linking members of hierarchy to validate other CA's l ¡ each CA has certificates for clients (forward) and parent (backward) each client trusts parents certificates l enable verification of any certificate from one CA by users of all other CAs in hierarchy l 44
CA hierarchy l Purpose: root CA can delegate job to lower CAs Chain of trust 45
Self-signed certificate for root CA Who signs for root CA? 1. Root CA is automatic considered as trusted CA 2. Software contains a preprogrammed, hard coded certificated of the root CA 3. The root CA signs its own certificate (self-signed certificate) 46
Cross-certification Root CAs in different countries 47
Obtaining a Certificate l any user with access to CA can get any certificate from it l only the CA can modify a certificate l because cannot be forged, certificates can be placed in a public directory l Y<<X>> = the certificate of user X issued by certification authority Y 48
Example of “A obtains B’s public key l Suppose that ¡ l A get the certificate from Certification Authority(CA) X 1, B get it from other X 2. If A does not securely know the public key of X 2, then B’s certificate issued by X 2 is useless to A although A can read B’s certificate but can not verify the signature. The following procedure will enable A to obtain B’s public key: ¡ ¡ ¡ A obtains, from the directory, the certificate of X 2 signed by X 1. Because A securely knows X 1’s public key, A can obtain X 2’s public key from its certificate and verify it by means of X 1’s signature on the certificate A goes back to the directory and obtains the certificate of B signed by X 2. Because A now has a trusted copy of X 2’s public key, A can verify the signature and securely obatin B’s public key. X 1<<X 2>> → X 2<<B>> 49
Certificates Revocation l l l Ex. lost of credit card, driver license, … 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 ¡ The CA made mistakes while issuing a certificate ¡ CA's certificate is compromised ¡ l CA’s maintain list of revoked certificates ¡ l the Certificate Revocation List (CRL) users should check certs with CA’s CRL 50
How to revoke a certificate? Certificate has been issued, how to revoke it? 51
Authentication Procedures l X. 509 includes three alternative authentication procedures: ¡ One-Way Authentication ¡ Two-Way Authentication ¡ Three-Way Authentication l all use public-key signatures 52
One-Way Authentication l 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 l message must include timestamp, nonce, B's identity and is signed by A 53
Two-Way Authentication l 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 l reply includes original nonce from A, also timestamp and nonce from B 54
Three-Way Authentication l 3 messages (A->B, B->A, A->B) which enables above authentication without synchronized clocks l has reply from A back to B containing signed copy of nonce from B l means that timestamps need not be checked or relied upon 55
Summary l have considered: ¡ Kerberos trusted key server system ¡ X. 509 authentication and PKI 56
Скачать презентацию Network Information Security 网络信息安全 No 7 Authentication Applications
5e911cf7db2a31efed06446ece576833.ppt