Security in Communication Networks WS‘00/01 1 / 55 Contents
10.1 Kerberos
• Kerberos V4
• Kerberos V5
10.2 World Wide Web Security
• S-HTTP (secure hypertext transfer protocol)
• SEA (security extension architecture)
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
2 / 55
Kerberos V4 / Contents
• 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
Security in Communication
Networks WS‘00/01
3 / 55
Kerberos / Introduction
• 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
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
4 / 55
Kerberos / Secret Keys 1) Master Keys
KKDC: 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.
KA: master key of a principal A
• the KDC shares such a secret key with each principal, • nobody else should know this key,
Security in Communication
Networks WS‘00/01
5 / 55
Kerberos / Secret Keys 2) Session Keys
SWS: a session key
• the KDC invents such session keys for communication with a workstation (WS),
• it is valid only during the actual session. KAB: a shared session key
• the KDC invents shared session keys for communications between principals A and B,
• e.g.: Alice and Bob share KAB.
è shared Key’s are distributed using Tickets and TGTs Granting Tickets)
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
6 / 55
Kerberos V4 / Login via Password
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 KA.
• Alice doesn’t want to enter her password for each connection. ð Use a session key SA for communication between the WS and the
KDC.
• The workstation should not remember Alice’s secret.
ð Let the workstation forget Alice’s master key KA as soon as possible.
Security in Communication
Networks WS‘00/01
7 / 55
Kerberos V4 / Login via Password
• 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 KA,
• WS decrypts AS_REP using KA,
• WS forgets Alice’s Master Key KA (hopefully!).
ð Workstation knows session key SA and a TGTA (Ticket-Granting Ticket).
Workstation Alice KDC 7 Username: Alice AS_REQ Alice needs a TGT AS_REP KA(SA, TGTA) invents key SA
finds Alices master key KA
TGTA = KKDC(“Alice”, SA)
7 Password: ‘ geheim ’
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
8 / 55
Kerberos V4 / Login via Password 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,
Security in Communication
Networks WS‘00/01
9 / 55
Kerberos V4 / Tickets and Ticket-Granting Tickets Drawbacks of the login protocol:
• 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 encryption of the TGT
KA(SA, TGTA) = KA(SA, KKDC(“Alice”, SA ))
• offers no security benefit, but needs computational effort,
• Kerberos has sometimes been criticised for this minor performance degradation
double encrypted
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
10 / 55
Kerberos V4 / Tickets and Ticket-Granting Tickets Suppose that Alice wants to talk to a remote partner Bob.
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
Security in Communication
Networks WS‘00/01
11 / 55
Kerberos V4 / Tickets and Ticket-Granting Tickets Kerberos authentication and session key distribution:
Alice‘s Workstation
Bob
TGS_REQ
Alice wants to talk to Bob TGTA = KKDC{„Alice“, SA} authenticator = SA{timestamp}
TGS_REP
SA{“Bob”, KAB, ticket to Bob}
KDC
decrypts TGT to get SA decrypts authenticator verifies timestamp finds Bob’s master key invents key KAB
ticket to Bob = KB{KA B, “Alice”}
AP_REQ ticket to Bob authenticator = KAB{timestamp} AP_REP KAB{timestamp+1} Security in Communication Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
12 / 55
Kerberos V4 / Tickets and Ticket-Granting Tickets
Similar to the Needham-Schroeder protocol:
Alice Bob
Alice wants to talk to Bob
N1
KA{N1, “Bob”, KAB, ticket to Bob}
KDC
finds Bob’s master key invents key KAB
ticket to Bob = KB{KA B, “Alice”}
ticket to Bob KAB{N2}
KAB{N2-1, N3 }
Security in Communication
Networks WS‘00/01
13 / 55
Kerberos V4 / Replicated KDCs 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).
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
14 / 55
Kerberos V4 / Replicated KDCs Updates:
an update consists on inserting, deleting, or changing a database entry. a database entry is of the format: < principal, name, KKDC(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.
Security in Communication
Networks WS‘00/01
15 / 55
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. 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)
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
16 / 55
Kerberos V4 / Interrealm Authentication Interrealm Authentication:
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 KB@A, • a shared key for different realms are different: KB@A ¹ KB@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.
Security in Communication
Networks WS‘00/01
17 / 55
Kerberos V4 / Interrealm Authentication
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 = KKDC{„Alice“, SA} authenticator = SA{timestamp}
TGS_REP
SA{“Oz”, KA,Oz, TGTOz = ticket to Oz}
Wonderland KDC
decrypts TGT to get SA decrypts authenticator verifies timestamp finds master key of Oz Koz@W invents key KA,Oz
TGTOz = ticket to Oz = Koz@W{“Alice”, KA,Oz}
Oz KDC
determines Wonderland as Realm of source KDC decrypts TG TOz using Koz@W to get KA,Oz decrypts authenticator
verifies timestamp finds Dorothy’s master key invents key KAD
ticket to Dorothy = KD{“Alice”, KAD} TGS_REQ (interrealm)
Alice@W wants to talk to Dorothy@Oz KDC‘s Realm = Wonderland TGTOz = Koz@W{„Alice“, KA,Oz}
authenticator = KA,Oz{timestamp}
TGS_REP (interrealm)
KA,Oz{“Dorothy”, KAD, ticket to Dorothy}
now Alice (her workstation) knows everything needed to talk to Dorothy
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
18 / 55
Kerberos V4 / Interrealm Authentication Kerberos V4 does not allow to “go through” a chain of realms. Suppose:
• realm “Wonderland” (short “W”) and “Oz” share a key Koz@W and, • realm “Oz” and “Carolina” share a KCorolina@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): TGTCarolina = KCarolina@Oz{„Alice“, KA,Carolina}
Security in Communication
Networks WS‘00/01
19 / 55
Kerberos V4 / Interrealm Authentication
Alice‘s Workstation
TGS_REQ
Alice@W wants to talk to Oz@W KDC‘s Realm = Wonderland
TGT = KKDC{„Alice“, SA} authenticator = SA{timestamp}
TGS_REP
SA{“Oz”, KA,Oz, TGTOz = ticket to Oz}
Wonderland KDC
decrypts TGT to get SA decrypts authenticator verifies timestamp finds master key of Oz Koz@W invents key KA,Oz
TGTOz = ticket to Oz = Koz@W{“Alice”, KA,Oz}
Oz KDC
determines Wonderland as Realm of source KDC decrypts TG TOz using Koz@W to get KA,Oz decrypts authenticator
verifies timestamp
finds Carolina’s master key KCarolina@Oz invents key KA, Carolina
TGTCarolina = ticket to Carolina
= KCarolina@Oz{“Alice”, KA,Carolina} TGS_REQ (interrealm)
Alice@W wants to talk to Carolina@Oz KDC‘s Realm = Wonderland TGTOz = Koz@W{„Alice“, KA,Oz}
authenticator = KA,Oz{timestamp}
TGS_REP (interrealm)
KA,Oz{“Carolina”, KA,Carolina, TGTCarolina}
now Alice tries to talk to Carolina’s KDC...
same as before
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
20 / 55
Kerberos V4 / Interrealm Authentication
The attempt to obtain a ticket to Carol@Carolina from the KDC of Carolina will fail, due to mismatching realms:
“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 Carol TGS_REQ (interrealm)
Alice@W wants to talk to Carol@Carolina KDC‘s Realm = Oz
TGTCarolina = KCarolina@Oz{„Alice“, KA,Carolina}
authenticator = KA,Carolina{timestamp}
Carolina ‘s KDC refused Alice’s Workstation
Security in Communication
Networks WS‘00/01
21 / 55
Kerberos V4 / Interrealm Authentication
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).
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
22 / 55
Kerberos V4 / Key Version Numbers 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,
Security in Communication
Networks WS‘00/01
23 / 55
Kerberos V4 / Privacy and Integrity 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.
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
24 / 55
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.
m1 c1 E m2 c2 E IV m3 c3 E mn cn E encrypt with secret key additional operations done in PCBC compared to CBC
Security in Communication
Networks WS‘00/01
25 / 55
Kerberos V4 / Privacy and Integrity Integrity check:
• put some recognisable data at the end (mn) of a message, • check this when receiving the message.
Assumption behind this:
The last part of the message, e.g. mn, decrypts properly only if the message was not changed.
• with CBC this assumption does not hold, therefore PCBC was introduced,
L but: if an attacker exchanges blocks of the message, this assumption will not hold for PCBC as well!
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
26 / 55
Kerberos V4 / Privacy and Integrity Integrity only protected communication:
• Kerberos V4 uses a (mathematically questionable) so called “modified Jueneman checksum”
Security in Communication Networks WS‘00/01 27 / 55 Kerberos V5 / Contents
• Kerberos V5
• ASN.1 • Delegation • Long Life Tickets • Privacy and Integrity • Inter-realm AuthenticationKerberos
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
28 / 55
Kerberos V5 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.
Security in Communication
Networks WS‘00/01
29 / 55
Kerberos V5 / ASN.1 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:
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
30 / 55
Kerberos V5 / Delegation 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
Security in Communication
Networks WS‘00/01
31 / 55
Kerberos V5 / Delegation 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
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
32 / 55
Kerberos V5 / Delegation
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.
Security in Communication
Networks WS‘00/01
33 / 55
Kerberos V5 / Delegation
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)
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
34 / 55
Kerberos V5 / Delegation forwardable and proxiable flags
(4 different settings in a TGT) KDC TGT Alice’s address (forwardable) (proxiable) TGT Bobs’s address forwarded KDC TGT Alice’s address ticket to Carol Bobs’s address proxy KDC TGT Alice’s address ticket to Bob Alice’s address ticket to Bob Alice’s address TGT Alice’s address (forwardable) (proxiable) TGT Bobs’s address forwarded KDC ticket to Carol Bobs’s address proxy ticket to Bob Alice’s address ticket to Bob Alice’s address proxiable proxiable forwardable forwardable
set forwardable flag? set proxiable flag ?
equal address different addresses different addresses
Security in Communication
Networks WS‘00/01
35 / 55
Kerberos V5 / Delegation / TGT forwarding
(forwardable) TGT Bobs’s address forwarded forwardable (forwardable) TGT Bobs’s address forwarded forwardable Alice‘s Workstation TGT Alice’s address forwardable KDC Bob TGS_REQ set forwardable flag? YES
TGS_REP TGS_REQ TGS_REP (forwardable) TGT Carol’s address forwarded forwardable ...and so on set forwardable flag? YES
send TGT to Bob
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
36 / 55
Kerberos V5 / Delegation
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.
Security in Communication
Networks WS‘00/01
37 / 55
Kerberos V5 / Delegation 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.
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
38 / 55
Kerberos V5 / Delegation
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.
Security in Communication
Networks WS‘00/01
39 / 55
Kerberos V5 / Long Life Tickets 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
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
40 / 55
Kerberos V5 / Long Life Tickets 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
Security in Communication
Networks WS‘00/01
41 / 55
Kerberos V5 / Privacy and Integrity 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).
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
42 / 55
Kerberos V5 / Privacy and Integrity
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)
m rsa-md4-des is mainly rsa-md5-des using MD4.
m 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:
Security in Communication
Networks WS‘00/01
43 / 55
Kerberos V5 / Privacy and Integrity / rsa-md5-des
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’ = KAB⊕ F0F0F0F0F0F0F016,
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.
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
44 / 55
Kerberos V5 / Privacy and Integrity / des-mac
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 = KAB(X), (64 Bits), encrypt in CBC mode using IV = 0,
4) K’ = KAB⊕ F0F0F0F0F0F0F016 ,
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’],
Security in Communication
Networks WS‘00/01
45 / 55
Kerberos V5 / Privacy and Integrity
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:
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.
32 bits for des-cbc-crc 129 bits for the other algorithms
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
46 / 55
Kerberos V5 / Interrealm Authentication
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.
Security in Communication
Networks WS‘00/01
47 / 55
Kerberos V5 / Interrealm Authentication • Its practical to arrange realm in a tree structure. • The tree structure often emerges
from present address structures (e.g. internet domains).
• Possibly allow additional shortcuts (cross links).
A D C B E F G H I shortcut Security in Communication Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
48 / 55
WWW Security
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.
Security in Communication
Networks WS‘00/01
49 / 55
WWW Security
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.
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
50 / 55
S-HTTP
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
Security in Communication
Networks WS‘00/01
51 / 55
S-HTTP
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
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
52 / 55
S-HTTP
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,
Security in Communication
Networks WS‘00/01
53 / 55
S-HTTP
New Anchor Attributes:
• DN
- Contains the distiguished name (DN) of the principal for whom the request should be encrypted when
de-referencing 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)
Security in Communication
Networks WS‘00/01
10. Application Layer Security (Kerberos, WWW)
54 / 55
S-HTTP
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).
Security in Communication
Networks WS‘00/01
55 / 55
SEA