10.2 World Wide Web Security S-HTTP (secure hypertext transfer protocol) SEA (security extension architecture)

Contents 1 / 55 10.1 Kerberos Kerberos V4 Kerberos V5 10.2 World Wide Web Security S-HTTP (secure hypertext transfer protocol) SEA (security extension architecture) Kerberos V4 / Contents 2 / 55 Kerberos V4 Login via Password Secret Keys (used in Kerberos) Tickets and Ticket-Granting Tickets Replicated KDCs Realms and Inter-realm Authentication Ticket Version Numbers Privacy and Integrity Kerberos 1

Kerberos / Introduction 3 / 55 developed by the Massachusetts Institute of Technology (MIT) authentication service secret key based uses KDC (Key Distribution Centre) User logs into workstation with name, password (weak) the workstation establishes authenticated connections Assumptions: network is insecure the KDC is trusted Kerberos / Secret Keys 4 / 55 1) Master Keys K KDC : KDC s master Key this is the KDC s own secret key, known only to the KDC, whoever has this key can encrypt the KDC database. K A : master key of a principal A the KDC shares such a secret key with each principal, nobody else should know this key, e.g.: Alice - K A (known by KDC and Alice). 2

Kerberos / Secret Keys 5 / 55 2) Session Keys S WS : a session key the KDC invents such session keys for communication with a workstation (WS), it is valid only during the actual session. K AB : a shared session key the KDC invents shared session keys for communications between principals A and B, e.g.: Alice and Bob share K AB. shared Key s are distributed using Tickets and TGTs (Ticket- Granting Tickets) Kerberos V4 / Login via Password 6 / 55 Consider Alice, a human user who wants to establish a secret connection via a workstation to a principal in the network: Alice can only remember a password (not a strong key). Convert Alice s password into a DES key K A. Alice doesn t want to enter her password for each connection. Use a session key S A for communication between the WS and the KDC. The workstation should not remember Alice s secret. Let the workstation forget Alice s master key K A as soon as possible. 3

Kerberos V4 / Login via Password 7 / 55 Alice enters her user name, WS sends AS_REQ (Authentication Server Request), WS receives AS_REP (Authentication Server Reply), WS gets password from Alice and derives K A, WS decrypts AS_REP using K A, WS forgets Alice s Master Key K A (hopefully!). Workstation knows session key S A and a TGT A (Ticket-Granting Ticket). Username: Alice Alice Password: geheim Workstation AS_REQ Alice needs a TGT AS_REP K A (S A, TGT A ) KDC invents key S A finds Alices master key K A TGT A = K KDC ( Alice, S A ) Kerberos V4 / Login via Password 8 / 55 What is the TGT? A ticket to get tickets: Ticket-Granting Ticket. It is advantageous to have no volatile data on the KDC, as this makes KDC replications easier. Thus... KDC does not store the session key, instead, the WS uses the TGT for ticket requests, the TGT contains all data needed by the KDC to identify Alice and encrypt the reply with the suitable session key, an additional authenticator provides for authentication. 4

Kerberos V4 / Tickets and Ticket-Granting Tickets Drawbacks of the login protocol: 9 / 55 It is easy to obtain a data for an offline password guessing attack: simply send: Alice needs a TGT remedy in V5: the user has to prove his identity, by sending a pre-authentication. Thus, the workstation knows the user s master key for a slightly longer time, as it needs to know the users password already prior to sending the request. However, this is not considered to significantly decrease the security level. double encrypted Double encryption of the TGT K A (S A, TGT A ) = K A (S A, K KDC ( Alice, S A )) offers no security benefit, but needs computational effort, Kerberos has sometimes been criticised for this minor performance degradation Kerberos V4 / Tickets and Ticket-Granting Tickets Suppose that Alice wants to talk to a remote partner Bob. 10 / 55 Kerberos uses the Needham-Schroeder protocol for authentication, but: timestamps are used instead of Nonces, the TGT and the session key are used instead of Alice s master key Messages involved: TGS_REQ: Ticket-Granting-Service Request TGS_REP: Ticket-Granting-Service Reply AP_REQ: Application Request AP_REP: Application Reply 5

Kerberos V4 / Tickets and Ticket-Granting Tickets 11 / 55 Kerberos authentication and session key distribution: Alice s Workstation TGS_REQ Alice wants to talk to Bob TGT A = K KDC { Alice, S A } authenticator = S A {timestamp} TGS_REP S A { Bob, K AB, ticket to Bob} KDC AP_REQ ticket to Bob authenticator = K AB {timestamp} decrypts TGT to get S A decrypts authenticator verifies timestamp finds Bob s master key invents key K AB ticket to Bob = K B {K AB, Alice } Bob AP_REP K AB {timestamp+1} Kerberos V4 / Tickets and Ticket-Granting Tickets 12 / 55 Similar to the Needham-Schroeder protocol: Alice wants to talk to Bob N 1 K A {N 1, Bob, K AB, ticket to Bob} KDC finds Bob s master key invents key K AB ticket to Bob = K B {K AB, Alice } Alice ticket to Bob K AB {N 2 } Bob K AB {N 2-1, N 3 } K AB {N 3-1} 6

Kerberos V4 / Replicated KDCs 13 / 55 Problem: The KDC is a bottleneck: if the KDC is down, it will not be possible to access remote resources (single-point-of-failure), if the KDC is overloaded, the whole network performance will be affected. Solution: Replicated KDCs: multiple, interchangeable KDCs, share the same Master KDC key, identical database, use master copy to keep all KDCs identical, all updates are made on this master copy, all other slave KDCs sites update the master copy (periodically or initiated by a human). Kerberos V4 / Replicated KDCs 14 / 55 Updates: an update consists on inserting, deleting, or changing a database entry. a database entry is of the format: < principal, name, K KDC (key)> Download the database to slave KDCs: transmission is done in the clear - an attacker may learn the names of the resources by eavesdropping, - however, all keys are encrypted with the master key of the KDC and are thus of no use for an attacker. To prevent an attacker from re-arranging the data, it is transmitted using the Kerberos integrity protection. - database replay attack is prevented, as the integrity protocol includes a timestamp. 7

Kerberos V4 / Realms Remaining problems with replicated KDCs: consider several companies, banks, governments,... in a big network: whoever manages the KDC can access all user master keys, it is hard to find an organisation to manage the KDC that anybody would trust, replicated KDCs are physically located at the different stakeholders sites, and all of them need to be secure and trusted by all stakeholders. 15 / 55 Solution: split network into Realms each realm has its own trusted master KDC database, KDCs in the same realm are equivalent, KDCs of different Realms are different: different KDC master key different principals (and also keys) Kerberos V4 / Interrealm Authentication 16 / 55 Interrealm Authentication: KDC-B = KDC of realm B Problem: suppose Alice wants to talk to Dorothy located in a different realm. How to authenticate Alice to Dorothy? a KDC can be registered as principal in several other realms, assume KDC-B is registered at KDC-A: they share a key K B@A, a shared key for different realms are different: K B@A K B@C, if the KDC-B receives a ticket generated by a KDC of another realm, it needs to know the source realm in order to use the right key for decryption. The source realm is included in the TGS_REQ. 8

Kerberos V4 / Interrealm Authentication 17 / 55 Interrealm Authentication between realms Wonderland and Oz : Alice s Workstation TGS_REQ Alice@W wants to talk to Oz@W KDC s Realm = Wonderland TGT = K KDC { Alice, S A } authenticator = S A {timestamp} TGS_REP S A { Oz, K A,Oz, TGT Oz = ticket to Oz} TGS_REQ (interrealm) Alice@W wants to talk to Dorothy@Oz KDC s Realm = Wonderland TGT Oz = K oz@w { Alice, K A,Oz } authenticator = K A,Oz {timestamp} TGS_REP (interrealm) K A,Oz { Dorothy, K AD, ticket to Dorothy} Wonderland KDC Oz KDC decrypts TGT to get S A decrypts authenticator verifies timestamp finds master key of Oz K oz@w invents key K A,Oz TGT Oz = ticket to Oz = K oz@w { Alice, K A,Oz } determines Wonderland as Realm of source KDC decrypts TGT Oz using K oz@w to get K A,Oz decrypts authenticator verifies timestamp finds Dorothy s master key invents key K AD ticket to Dorothy = K D { Alice, K AD } now Alice (her workstation) knows everything needed to talk to Dorothy Kerberos V4 / Interrealm Authentication 18 / 55 Kerberos V4 does not allow to go through a chain of realms. Suppose: realm Wonderland (short W ) and Oz share a key K oz@w and, realm Oz and Carolina share a K Corolina@Oz, the realms Wonderland and Carolina do not share a key. Assume now: Alice has already obtained a ticket to the KDC of Carolina as demonstrated before (Dorothy was substituted with Carolina s KDC): TGT Carolina = K Carolina@Oz { Alice, K A,Carolina } 9

Kerberos V4 / Interrealm Authentication 19 / 55 Alice s Workstation TGS_REQ Alice@W wants to talk to Oz@W KDC s Realm = Wonderland TGT = K KDC { Alice, S A } authenticator = S A {timestamp} TGS_REP S A { Oz, K A,Oz, TGT Oz = ticket to Oz} Wonderland KDC same as before TGS_REQ (interrealm) Alice@W wants to talk to Carolina@Oz KDC s Realm = Wonderland TGT Oz = K oz@w { Alice, K A,Oz } authenticator = K A,Oz {timestamp} TGS_REP (interrealm) K A,Oz { Carolina, K A,Carolina, TGT Carolina } Oz KDC decrypts TGT to get S A decrypts authenticator verifies timestamp finds master key of Oz K oz@w invents key K A,Oz TGT Oz = ticket to Oz = K oz@w { Alice, K A,Oz } determines Wonderland as Realm of source KDC decrypts TGT Oz using K oz@w to get K A,Oz decrypts authenticator verifies timestamp finds Carolina s master key K Carolina@Oz invents key K A, Carolina TGT Carolina = ticket to Carolina = K Carolina@Oz { Alice, K A,Carolina } now Alice tries to talk to Carolina s KDC... Kerberos V4 / Interrealm Authentication The attempt to obtain a ticket to Carol@Carolina from the KDC of Carolina will fail, due to mismatching realms: 20 / 55 Alice s home realm is not equal to the entry KDC s realm in the TGS_REQ: Oz is a principal in Wonderland Carolina is a principal in Oz Alice s Workstation TGS_REQ (interrealm) Alice@W wants to talk to Carol@Carolina KDC s Realm = Oz TGT Carolina = K Carolina@Oz { Alice, K A,Carolina } authenticator = K A,Carolina {timestamp} refused Carolina s KDC Carol 10

Kerberos V4 / Interrealm Authentication 21 / 55 Alice will not be able to talk to Carol@Carolina with this TGT: The attempt to get a ticket for Carol from Carolina s KDC will fail because of mismatching realms. A principal can only use TGTs originating from its home KDC to ask for a ticket at any other KDCs. TGT s originating from realms other than the home realm of the requesting principal are refused. Kerberos does not such KDC-chaining! Otherwise a rogue KDC could not only impersonate its own principals, but those of any other realm, when it is (or pretends to be!) a connecting realm (by simple generating a suitable TGT). Kerberos V4 / Key Version Numbers 22 / 55 Problem: if a principal changes its master key, already distributed tickets will become unusable (since they are still encrypted with the old key). this is not practical, especially considering batch jobs! Solution: key version numbers new keys get a new version number, principals remember several old key versions, tickets expire after about 21 hours, thus keys must not be remembered any longer than that, the version number of the used key is included in tickets and TGTs. 11

Kerberos V4 / Privacy and Integrity 23 / 55 After authentication the communication is: either in clear text, or privacy and integrity protected (DES encryption), or integrity protected only (Message-Digest). * The combined privacy and integrity protection proves to be difficult and is not fully provided for by Kerberos V4. Kerberos V4 / Privacy and Integrity Privacy and integrity protected communication: DES encryption for long messages, done through modified CBC (Cipher Block Chaining) (referred to as PCBC, Plaintext Cipher Block Chaining), the unmodified CBC provides for privacy, PCBC claims to additionally provide integrity. 24 / 55 m 1 m 2 m 3 m n IV additional operations done in PCBC compared to CBC encrypt with E E E E secret key c 1 c 2 c 3 c n CBC: modification of c i will garble only m i and m i+1 PCBC: modification of c i will garble all following: m i, m i+1,...,m n 12

Kerberos V4 / Privacy and Integrity 25 / 55 Integrity check: put some recognisable data at the end (m n ) of a message, check this when receiving the message. Assumption behind this: The last part of the message, e.g. m n, decrypts properly only if the message was not changed. with CBC this assumption does not hold, therefore PCBC was introduced, but: if an attacker exchanges blocks of the message, this assumption will not hold for PCBC as well! Kerberos V4 / Privacy and Integrity 26 / 55 Integrity only protected communication: Kerberos V4 uses a (mathematically questionable) so called modified Jueneman checksum Kerberos V5 uses better methods (MD4, MD5, DES-MAC,...) 13

Kerberos V5 / Contents 27 / 55 Kerberos V5 ASN.1 Delegation Long Life Tickets Privacy and Integrity Inter-realm Authentication Kerberos Kerberos V5 28 / 55 Kerberos V4 V5 + more features and flexibility e.g. delegation, ASN.1, realm chaining, + fewer restrictions e.g. longer addresses, long life tickets, + optimisations e.g. enhanced algorithms for privacy and integrity. - But also more overhead. 14

Kerberos V5 / ASN.1 29 / 55 ASN.1 is a data representation language ISO standard, looks similar to data structure definitions in programming languages, independent of data representation (such as bit and byte order), allows optional fields, varying of field lengths. More flexibility, but also more overhead Example: Kerberos V5 / Delegation 30 / 55 Problem: consider...... a batch job (or an agent) running on Bob, that needs to access files of Alice... a login from one remote node Bob into another. Bob needs authorization Solution: Delegation of rights give someone else access to things you are authorized to access delegation is usually limited: in time in scope (subset of resources) 15

Kerberos V5 / Delegation 31 / 55 Idea to obtain delegation: send tickets (e.g. a ticket to Carol ) or even the TGT to Bob. in Kerberos V4: network layer address of Alice is included in TGT and tickets, delegation not possible (tickets unusable for Bob) in Kerberos V5: Alice can request tickets ( proxy tickets ) and TGTs containing a network layer address different from her own (e.g. Bob s address), even multiple or no address can be specified (no address ticket usable from any address). delegation possible Kerberos V5 / Delegation 32 / 55 Note: In Kerberos Alice delegates rights to Bob, by allowing Bob to impersonate Alice to the KDC and/or other principals. thus Alice in some sense passes on her identity. Additionally, the AUTHORIZATION-DATA field provides the possibility to restrict the rights of Bob impersonating Alice on the application level. 16

Kerberos V5 / Delegation 33 / 55 The possibilities of delegation can be controlled using the flags in the TGT: forwardable (this TGT can be forwarded, means: you can get TGTs with a different address) proxiable (with this TGT its possible to obtain a ticket including a different address) There are additional flags notifying the status of a ticket: a TGT can be marked as forwarded (it originates from a TGT with another address) a ticket can be marked as forwarded (it originates from a forwarded TGT) proxy (it was generated with a different address than the originating TGT) Kerberos V5 / Delegation 34 / 55 forwardable and proxiable flags (4 different settings in a TGT) KDC KDC set forwardable flag? set proxiable flag? TGT Alice s address equal address ticket to Bob Alice s address forwardable TGT Alice s address ticket to Bob Alice s address different addresses (forwardable) (proxiable) TGT Bobs s address forwarded KDC KDC proxiable TGT Alice s address ticket to Bob Alice s address different addresses ticket to Carol Bobs s address proxy proxiable forwardable TGT Alice s address ticket to Bob Alice s address ticket to Carol Bobs s address proxy (forwardable) (proxiable) TGT Bobs s address forwarded 17

Kerberos V5 / Delegation / TGT forwarding 35 / 55 forwardable TGT set forwardable flag? YES TGS_REQ Alice s Workstation Alice s address (forwardable) forwardable TGT Bobs s address forwarded send TGT to Bob Bob TGS_REP (forwardable) forwardable TGT Bobs s address forwarded (forwardable) forwardable set forwardable flag? YES TGS_REQ KDC TGT TGS_REP Carol s address forwarded...and so on Kerberos V5 / Delegation 36 / 55 When Alice requests a forwarded TGT, she can specify the desired settings of the forwardable and proxiable flags, the KDC can than decide which flags are actually set. using these flags in a TGT...... the KDC can control the delegation rights of clients (with higher priority than Alice),... Alice can control the delegation rights of the principal the delegation is given to. 18

Kerberos V5 / Delegation 37 / 55 Alice can limit the delegation in 3 different ways: by using the forwardable and proxiable flags, by giving no TGT to Bob, but only proxy tickets for the required services, by using the AUTHORIZATION-DATA field, which...... is given by Alice when requesting a TGT or ticket,... is added to the TGT or ticket,... is not interpreted by the KDC, but is instead application-specific. Kerberos V5 / Delegation 38 / 55 Furthermore the applications are involved in the delegation: by using the forwarded and proxy flags, when deciding what access to allow, by interpreting the AUTHORIZATION-DATA field. This results in a very flexible, but also very confusing access control. 19

Kerberos V5 / Long Life Tickets 39 / 55 In Kerberos V4: four bytes start time, one byte life time (units of 5 minutes)» approx. 21 hours maximum life In Kerberos V5: ASN.1 defined quantity of 17 bytes granularity: 1 second Lifetime is practically unlimited: end time <= 31 dec 9999 Lifetime is specified by: Start time (i.e. postdated tickets are possible) End time Authtime (time when Alice received her initial TGT) Renew-till (necessary for renewable tickets) Disadvantage: Long life time => higher security risk Kerberos V5 / Long Life Tickets 40 / 55 Disadvantage: Long life time => higher security risk Solution: renewable tickets Alice has to renew tickets, say once a day (thus the end time of a ticket is never more than one day ahead) To renew a ticket it has to be presented to the KDC the KDC then changes the end-time, if the ticket is still renewable (renew-till time) this makes revocation possible If Alice is ever late renewing a ticket, the KDC will refuse to renew it. this is due to the fact, that otherwise the KDC has to remember to many not renewed tickets. 20

Kerberos V5 / Privacy and Integrity 41 / 55 Cryptographic algorithms: Kerberos V4 uses DES with PCBC for privacy and integrity, modified Jueneman checksum for integrity only. Problems PCBC not safe against cipher block exchange, modified Jueneman checksum is mathematically questionable (though never publicly broken yet). Kerberos V5 / Privacy and Integrity 42 / 55 Kerberos V5 uses the following MICs (Message Integrity Codes) for integrity only: rsa-md5-des (required) des-mac (required) des-mac-k (required) rsa-md4-des (optional) rsa-md4-des-k (optional) rsa-md4-des is mainly rsa-md5-des using MD4. Algorithms ending with -k are old versions not using a modified key K (implemented to provide for backward compatibility). rsa-md5-des and des-mac are described in the following: 21

Kerberos V5 / Privacy and Integrity / rsa-md5-des 43 / 55 rsa-md5-des (has nothing to do with RSA other than RSADSI, a company owning rights to MD5!) MIC calculation: 1) choose Confounder = random number (64-bit), 2) X = [Confounder message ], message has variable length, 3) MD = MD5(X), (128 Bits), 4) K = K AB F0F0F0F0F0F0F0 16, 5) Y = [Confounder MD ], (192 Bits), 6) MIC = K (Y), (192-Bits), encrypt in CBC mode using IV = 0 (Initialisation Vector). MIC verification: a) calculate K, b) decrypt MIC = [Confounder MD ] using K, c) X = [Confounder message ], d) if MD = MD5(X ) then message = message, OK. Kerberos V5 / Privacy and Integrity / des-mac 44 / 55 des-mac similar to rsa-md5-des (main difference: Step 3): MIC calculation: 1) choose Confounder = random number (64-bit), 2) X = [Confounder message ], message has variable length, 3) Residue = K AB (X), (64 Bits), encrypt in CBC mode using IV = 0, 4) K = K AB F0F0F0F0F0F0F0 16, 5) Y = [Confounder Residue ], (128 Bits), 6) MIC = K (Y), (128 Bits), encrypt in CBC mode using IV = 0. MIC verification: a) calculate K, b) decrypt MIC = [Confounder Residue ] using K, c) X = [Confounder message ], d) if Residue = K AB (X ) then message = message, OK. 22

Kerberos V5 / Privacy and Integrity 45 / 55 For privacy and integrity Kerberos V5 uses the following algorithms: des-cbc-crc (MIC = CRC-32) des-cbc-md4 (MIC = MD4) des-cbc-md5 (MIC = MD5) all algorithms do the following: 32 bits for des-cbc-crc 129 bits for the other algorithms 1) choose Confounder = random number (64-bit), 2) X = [Confounder zeros (length of MIC) message ], 3) Y = [Confounder MIC(X) message ], 4) add padding (64-bit chunks), 5) encrypt the result using DES in CBC mode with IV = 0. Kerberos V5 / Interrealm Authentication 46 / 55 Goal: provide full connectivity Problem: in Kerberos V4: principal in realm A can authenticate with principals in realm B, only if KDC-A is registrated as principal in realm B, hugh registration effort. Approach: allow to go through series of realms. Problem: if one of the KDC in the chain is not trusted, the whole authentication can not be trusted. Idea: list all traversed KDC s in the TRANSITED field, such that no involved KDC can avoid to be listed. it s the clients decision then, if he trusts all traversed KDC s and thus the authentication or not. 23

Kerberos V5 / Interrealm Authentication 47 / 55 Its practical to arrange realm in a tree structure. The tree structure often emerges from present address structures (e.g. internet domains). A Possibly allow additional shortcuts (cross links). B G C D shortcut H I E F WWW Security 48 / 55 10.2 World Wide Web Security Originally, the Internet was intended to be an open network. HTTP was not designed to provide for security. Today, a secure WWW is crucial. Most current application are using SSL (transport layer!), There are alternative approaches on the application layer. 24

WWW Security 49 / 55 Approaches on the application layer: GSS-API (Generic Security Service Application, Interface), PGP-CCI (Pretty Good Privacy - Common Client Interface), S-HTTP (Secure Hypertext Transfer Protocol), SEA (Security Extension Architecture). Only the latter two will be described, in the following. S-HTTP 50 / 55 S-HTTP (not to be confused with https, which corresponds to SSL) is an extension of HTTP, provides end-to-end security, allows to negotiate options between client and server: choice of... - keymanagement mechanism, - security policies, - cryptographic algorithms. Certification Services are not requiered, but supported spontanous communication possible. 25

S-HTTP 51 / 55 S-HTTP uses common cryptographical techniques hash functions MD4, MD5, SHA encryption DES-CBC, Triple-DES, IDEA-CFB, RC4, CDMF-CBC signature RSA, DSS message format standards (content types): PKCS, MOSS S-HTTP 52 / 55 S-HTTP is compatible with HTTP: Communication is possible between S-HTTP enabled client and 'normal' HTTP server, and vice versa. Syntax is similar to HTTP S-HTTP messages consist of request or status line, series of header lines, body (may contain an encapsulated content). S-HTTP defines a set of new RFC 822-style headers and, three new Anchor Attributes (DN, NONCE, CRYTOPTS). 26

S-HTTP 53 / 55 New Anchor Attributes: DN - Contains the distiguished name (DN) of the principal for whom the request should be encrypted when dereferencing the anchor s URL. NONCE - Contains a nonce that must be returned in a separate header line when the anchor has been de-referenced CRYPTOPTS - Contains the cryptographic 'options' information (e.g., which algorithms are available, etc) S-HTTP 54 / 55 S-HTTP provides message content protection on three orthogonal axes: digital signature (using certificates), authentication, encryption. A message may be protected with all combinations of the above (including no protection). 27

SEA 55 / 55 SEA (Security Extension Architecture) initiatedby the W3C (World Wide Web Consortium), SEA for HTTP first published in 1996, uses design principles of S-HTTP and PEP (Protocol Extension Protocol), PEP: allows HTTP client and server to agree on supported extensions, similar to S-HTTP, still subject to ongoing changes. 28