Upload
melvin-hall
View
220
Download
0
Tags:
Embed Size (px)
Citation preview
4
KerberosShared-key protocol for user login authentication
Uses passwords as shared keysSolves security and scalability problems in password-based authentication in large domainsBased loosely on the Needham-Schroeder secret-key protocol
Kerberos v4 1988- at MITKerberos v5 1993- [RFC 4120]
Updated protocol and algorithmsASN.1 BER message encodingImplemented in Windows 2000 and later
Used in intranets: e.g. university Unix systems, corporate Windows domains
5
Kerberos architecture
1.–2. Authentication3.–4. Ticket for a specific service5.–6. Authentication to the service
KDC
TGSAS
Application server B
Client A
1.
KR
B_
AS
_R
EQ
2.
KR
B_
AS
_R
EP
3.
KR
B_
TG
S_
RE
Q
4.
KR
B_
TG
S_
RE
P
5. KRB_AP_REQ
6. KRB_AP_REPap_client.exe a
p_s
erv
er.
exe
7
Kerberos architecture (some details)KDC
TGSAS
Application server B
Client A
1. K
RB
_AS
_RE
Q
2. K
RB
_AS
_RE
P
3. K
RB
_TG
S_R
EQ
4. K
RB
_TG
S_R
EP
5. KRB_AP_REQ
6. KRB_AP_REP
TG
T
TG
T, K
AT
Ser
vice
tick
et, K
AB
Service ticket
ap_client.exe ap_s
erve
r.ex
e
krbtgt@RealmY
A@RealmY B@
Rea
lmY
1.–2. Authentication with password → client gets TGT and KAT
3.–4. Authentication with TGT and KAT → client gets
service ticket and KAB
5.–6. Authentication with service ticket and KAB
→ client gets service access
8
Message type, version
Kerberos ticket
Same format for both TGT and service ticketCredentials = ticket + keyASN.1 encoding in Kerberos v5“Encryption” also protects integrity, actually encryption and a MAC
Flags: FORWARDABLE, FORWARDED, PROXIABLE, PROXY, MAY-POST-DATE, POSTDATED, INVALID, RENEWABLE, INTINIAL, PRE-AUTHENT, HW-AUTHENTINITIAL flag indicates TGT
REALM, SNAMEServer name and realm
FLAGS
KEY
CNAME, CREALM Client name and realm
TRANSITEDtransit realms
AUTH-TIME, END-TIME
CADDRClient IP address (optional)
AUTORIZATION-DATAApp-specific access constraints E
ncry
pted
with
ser
ver’
s m
aste
r ke
y
9
Kerberos protocol (more details)Initial login of user A:
1. A → AS: Preauthentication, A, TGS, NA1, AddrA
2. AS → A: A, TGT, EKA (KA-TGS, NA1, TGS, AddrA)
Ticket request:3. A → TGS: TGT, AuthenticatorA-TGS, B, NA2, AddrA
4. TGS → A: A, Ticket, EKA-TGS (KAB, NA2, B, AddrA)
Authentication to server B:5. A → B: Ticket, AuthenticatorAB
6. B → A: AP_REP
KA , KTGS, KB = master keys of A, TGS and B
KA-TGS = shared key for A and TGS
KAB = shared key for A and B
TGT = B, EKTGS (INITIAL, KA-TGS, A, Tauth, Texpiry1, AddrA))
Ticket = B, EKB(KAB, A, Tauth, Texpiry2, AddrA))
Preauthentication = EKA (1 TA)
AuthenticatorA-TGS = EKA-TGS (2 TA)
AuthenticatorAB = EKAB (3 TA)
AP_REP = EKAB(4 TA)
A, B = principal namesTx = timestamp
AddrA = A’s IP addresses
Notes:
1234) ASN.1 encoding adds type tags to all messages
Encryption mode also protects message integrity
11
Kerberos realms
Users and services registered to one KDC form a realmname@realm, e.g. A@X, [email protected]
Cross-realm trust: Two KDCs X and Y share a key (krbtgt@Y is registered in KDC X and krbtgt@X in KDC Y)KDCs believe each other to be honest and competent to name users in their own realm
Cross-realm authentication: Client A@X requests from TGS at realm X a ticket for TGS at realm YThe ticket is encrypted for krbtgt@Y (i.e. TGS at realm Y)Client A@X requests from TGS at realm Y a ticket for server B@Y
Access control at several steps:Local policy at each KDC about when to honor tickets from other realmsLocal policy at B@Y about whether to allow access to users from other realmsACLs at B@Y determine whether the users is allowed to access the particular resources
Possible to transit multiple realms → TRANSITED field in the ticket lists intermediate realms
Local policy at each server about which transit realms are allowed
Server BUser A
Realm X Realm YCross-realm trust
User registration
12
Realm hierarchy
Large organizations can have a realm hierarchy Hierarchy follows internet names → easy to find a path between realms→ can filter cross-realm requests based on the namesCan add shortcut links or create even a fully connected graph between KDCsE.g. Windows domain hierarchy
Compare with X.509 certification hierarchy: similarities, differences?
contoso.com
sales.contoso.com dev.contoso.com
euro.sales.contoso.com asia.sales.contoso.com
Bob David Alice
Charlie
Cross-realm trust
User registration
13
Password guessing attacksKerberos is vulnerable to password guessing:
Sniffed KRB_AS_REQ or KRB_AS_REP can be used to test candidate passwords → offline brute-force password guessingIn Kerberos v4, anyone could request a password-encrypted TGT from AS → easy to obtain material for password crackingPreauthentication in Kerberos v5 prevents active attacks to obtain material for password cracking → must sniff it
Note: active vs. passive attacksMisleading thinking: active attacks (e.g. MitM) are more difficult to implement than passive attacks (sniffing)Reality: Active attacks can often be initiated by the attacker while passive attacks require attacker to wait for something to sniff → vulnerability to such active attacks is serious
!
!
14
PKINITGoal: take advantage of an existing PKI to bootstrap authentication in KerberosReplaces the KRB_AS_REQ / KRB_AS_REP exchange with a public-key protocol
Public-key authentication and encryption to obtain TGTContinue with standard Kerberos → transparent to TGS and application servers
No password, so not vulnerable to password guessingUses DSS signatures and ephemeral DHWindows 2000 and later, now standard [RFC 4556]
16
DelegationServer may need to perform tasks on the client’s behalf
Recursive RPC; agents operating when the user is no longer logged in; batch processing at night
Alice can give her TGT or service ticket and key to DavidControlling the use of delegated rights in applications:
Ticket may specify many allowed client IP addressesAuthorization-data field in ticket may contain app-specific restrictionsIt is safer to delegate a service ticket than TGT
Ticket flags related to delegation:FORWARDABLE flag in TGT: the TGT can be used to obtain a new TGT with different IP addressesPROXIABLE flag in TGT: the TGT can be used to obtain service tickets with a different IP address
Kerberos delegation is identity delegationWhen B has A’s ticket and key, B can act as A and nobody can tell the difference → difficult to audit access; similar to sharing passwordsOther protocols delegate only access rights, and the delegate can be identified
18
Windows access control summaryThe O/S stores security attributes for each processes (subject) in an access tokenToken contains a list of privileges and SIDs (i.e. user and group identifiers)
Permissions are decided by comparing the list of SIDs against a DACLs on an object
The access token is local to the machine, created at login time, and never sent over the network How to authorize access to resources managed by a Windows service (=daemon) on a remote server, e.g. over remote procedure call (RPC)?
19
Network credentialsAlice’s user name, SID and network credentials are cached on the user workstation
username and password, or TGT and KA-TGS
Alice’s processes can use her network credentials for remote login
Two authentication protocols: NTLM and Kerberos V5 (RFC 1510)These authentication protocols do not reveal the password to the server
Applications can also ask the user for a different user name and credentials and store them separately
20
Tokens and remote accessAccess tokens are meaningful only to the local machine and cannot be sent over network
The server does not trust the client machine to tell who Alice is and which groups she belongs to
Instead, the client authenticates Alice to the server using her network credentials. The server creates a new login session and a new token (on the server) for AliceThe service may now assign the token to a process or thread (=impersonation)The authentication protocols also
provide the server with Alice’s user and group SIDsproduce a session key for protecting data between the client and server
Encryption and authentication of session data is controlled by applications
Different secure session protocol exist for network logon, RPC, COM
22
Message type, version
Kerberos ticket in Windows
REALM, SNAMEServer name and realm
FLAGS
KEY
CNAME, CREALM Client name and realm
TRANSITEDtransit realms
AUTH-TIME, END-TIME
CADDRClient IP address (optional)
AUTORIZATION-DATAApp-specific access constrains E
ncry
pted
with
ser
ver’
s m
aste
r ke
y
Username, domain
User and group SIDs
23
Related readingWilliam Stallings. Network security essentials: applications and standards, 3rd ed. chapter 4.1; 4th ed. chapter 4.1–4.2 (Kerberos v5 only)William Stallings. Cryptography and Network Security, 4th ed.: chapters 14.1 (Kerberos v5)Dieter Gollmann. Computer Security, 2nd ed.: chapter 12.4; 3rd ed. chapter 15.4Kaufmann, Perlman, Speciner. Network security, 2nd ed.: chapter 14
Online: How the Kerberos Version 5 Authentication Protocol Works, http://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx
24
ExercisesHow does Kerberos fix the flaw in Needham-Schroeder secret-key protocol?Find source code for a Kerberized client/server application (e.g. telnet) and see how it accesses Kerberos servicesWhy is Kerberos used on the intranets and TLS/SSL on the Internet? Could it be the other way?Learn about Encrypted Key Exchange (EKE) and other similar password-based authentication protocols. Which problem do they solve?Should standard protocols include data fields or messages for proprietary extensions? What are the arguments for and against?