ISA 662 Internet Security Protocols Kerberos Prof. Ravi Sandhu.
Module 4 Network & Application Security: Kerberos – X509 Authentication service – IP security...
-
Upload
neil-francis -
Category
Documents
-
view
241 -
download
1
Transcript of Module 4 Network & Application Security: Kerberos – X509 Authentication service – IP security...
Module 4
Network & Application Security: Kerberos – X509 Authentication service – IP security Architecture –
Secure socket layer – Electronic mail security – Pretty Good privacy – S/MIME – secure Electronic Transactions – Firewalls - Security mechanisms in JAVA platform – Applet security – Security policy
and Security Manager.
Authentication Applications
• will consider authentication functions• developed to support application-level
authentication & digital signatures• will consider Kerberos – a private-key
authentication service• then X.509 directory authentication service
2
Kerberos• trusted key server system from MIT • provides centralised private-key third-party
authentication in a distributed network– allows users access to services distributed through
out the network– without needing to trust all workstations– rather all trust a central authentication server
• two versions in use: 4 & 5
3
Kerberos Requirements
• first published report identified its requirements as:– security– reliability– transparency– scalability
4
Kerberos 4 Overview• a basic third-party authentication scheme• have an Authentication Server (AS)
– users initially negotiate with AS to identify themselves
– AS provides a non-corruptible authentication credential (ticket granting ticket TGT)
• have a Ticket Granting server (TGS)– users subsequently request access to other services
from TGS on basis of users TGT
5
A Simple Authentication Dialogue
• (1) C -> AS : IDC || PC || IDV
– C = client – AS = authentication server– IDC = identifier of user on C– PC = password of user on C– IDV = identifier of server V– C asks user for the password– AS checks that user supplied the right password
6
Message 2
• (2) AS -> C : Ticket• Ticket = E K(V) [IDC || ADC || IDV]
– K(V) = secret encryption key shared by AS and V – ADC = network address of C
– Ticket cannot be altered by C or an adversary
7
Message 3
• (3) C -> V: IDC || Ticket– Server V decrypts the ticket and checks various
fields– ADC in the ticket binds the ticket to the network
address of C– However this authentication scheme has
problems
8
Problems
• Each time a user needs to access a different service he/she needs to enter their password– Read email several times– Print, mail, or file server– Assume that each ticket can be used only once
(otherwise open to replay attacks)
• Password sent in the clear
9
Authentication Dialogue II• Once per user logon session• (1) C -> AS: IDC || IDTGS
• (2) AS -> C: E (K(C), [TicketTGS])
• TicketTGS is equal to– E( K(TGS) [IDC || ADC || IDTGS || TS1 || Lifetime1 ])
• TGS = Ticket-granting server• IDTGS = Identifier of the TGS
• TicketTGS = Ticket-granting ticket or TGT
• K (C) = key derived from user’s password
• TS1 = timestamp
• Lifetime1 = lifetime for the TGT
10
Messages (3) and (4)• Once per type of service• (3) C -> TGS: IDC || IDV || TicketTGS
• (4) TGS -> C : TicketV
• TicketV is equal to– E K(V) [ IDC || ADC || IDV || TS2 || Lifetime2 ]
K(V): key shared between V and TGSIs called the service-granting ticket (SGT)
11
Message 5
• Once per service session• (5) C -> V: IDC || TicketV
• C says to V “I am IDC and have a ticket from the TGS” . Let me in!
• Seems secure, but..– There are problems
12
Problems• Lifetime of the TGT
– Short : user is repeatedly asked for their password– Long : open to replay attack– Oscar captures TGT and waits for the user to logoff– Sends message (3) with network address IDC
(network address is easy to forge)
• Same problem with SGT
13
What should we do?• A network service (TGS or server) should be able to
verify that – person using the ticket is the same as the person that the
ticket was issued to– Remedy : use an authenticator
• Server should also authenticate to user– Otherwise can setup a “fake” server– A “fake” tuition payment server and capture the student’s
credit card– Remedy : use a challenge-response protocol
14
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
16
Kerberos Version 5• developed in mid 1990’s• provides improvements over v4
– addresses environmental shortcomings• encryption algorithm, network protocol, byte order,
ticket lifetime, authentication forwarding, inter-realm authentication
– and technical deficiencies• double encryption, non-standard mode of use, session
keys, password attacks
• specified as Internet standard RFC 1510
18
Kerberos v5 Dialogueauthentication service exchange. •Message (1) is a client request for a ticket-granting ticket. •Message (2) returns a ticket-granting ticket, identifying information for the client, and a block encrypted using the encryption key based on the user's password. This block includes the session key to be used between the client and the TGS.
Kerberos v5 Dialogueticket-granting service •message (3) for includes an authenticator, a ticket, and the name of the requested service.•includes requested times and options for the ticket and a nonce•Message (4) has the same structure as message (2), returning a ticket plus information needed by the client, the latter encrypted with the session key now shared by the client and the TGS.
Kerberos v5 Dialogueclient/server authentication exchange,• several new features appear in version 5, such as a request for mutual authentication. •If required, the server responds with message (6) that includes the timestamp from the authenticator. •The flags field included in tickets in version 5 supports expanded functionality compared to that available in version 4
X.509 Authentication Service • X.509 is the Internationally accepted standard
– to construct a public key certificate, – is becoming widely used.
• part of CCITT X.500 directory service standards– distributed servers maintaining some info database
• defines framework for authentication services – directory may store public-key certificates– with public key of user– signed by certification authority
• also defines authentication protocols • uses public-key cryptography & digital signatures
– algorithms not standardised, but RSA recommended It is used by S/MIME secure email, SSL/TLS secure Internet links (eg for secure
web).
X.509 Certificates• issued by a Certification Authority (CA), containing:
– 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 (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
26
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
27
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
28
CA Hierarchy Use
29
Track chains of certificates:A acquires B certificate using chain: X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>> B acquires A certificate using chain: Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>
Certificate Revocation• certificates have a period of validity• may need to revoke before expiry
1. user's private key is compromised2. user is no longer certified by this CA3. CA's certificate is compromised
• CA’s maintain list of revoked but not expired certificates issued by CA
– the Certificate Revocation List (CRL)
• users should check the directory each time a certificate is received, with CA’s CRL
– To avoid delay user would maintain a local cache of certificates and list of revoked certificates. 30
Authentication Procedures
• X.509 includes three alternative authentication procedures: – One-Way Authentication
• for unidirectional messages (like email)
– Two-Way Authentication • for interactive sessions when timestamps are used
– Three-Way Authentication • for interactive sessions with no need for timestamps
• all use public-key signatures
31
One-Way Authentication
• A single transfer of information from 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
32
Nonce
• a nonce is a parameter that varies with time. – A nonce can be a time stamp, – a visit counter on a Web page, – or a special marker intended to limit or prevent
the unauthorized replay or reproduction of a file.
Two-Way Authentication
• Two 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
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 a signed copy of nonce from B
• means that timestamps need not be checked or relied upon
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
37
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
38