Computer Science&Technology School of Shandong University

Instructor: Hou Mengbo

Email: houmb AT sdu.edu.cn

Office: Information Security Research Group

Guide to Information Security

Chapter 14 – Authentication Applications

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

Kerberos Authentication Protocol

Kerberos Authentication Protocol

• Kerberos Overview

• Kerberos Protocol Description

• Kerberos Analysis and related Resources

What’s Kerberos ？• 1988 由 MIT开发，在一个分布式环境中，用于服务器与用户之间的相互认证的协议。

• 名称来源于希腊神话， Kerberos是地狱入口的守护者，通常有三个头。

• 设计者的设计初衷是要用 Kerberos的三个头来守卫网络之门。三个头包括：认证、帐目清算以及审计。

• 到目前共有 5个版本。 1、 2、 3版为实验室版。第 4、 5版得到广泛应用。第 5版和第 4版基本原理一致，只对第 4版做了部分改进。

Kerberos 要解决的问题• 在一个开放的分布式网络环境中，用户通过工作站访问服务器提供的服务。存在很多问题：

–工作站上的用户可以冒充另一用户操作。–用户可以改变工作站地址冒充另一台工作站。–用户可以窃听并回放他人的信息交换，获得对于某种服务的访问权或中断服务的运行。

–使用假冒服务器从而骗得用户的机密信息。

Kerberos 的解决方案• 在一个分布式的 Client/Server体系机构中，引入一个可信任的第三方（ Kerberos服务器），让其提供认证服务。

• 采用共享密钥加密技术。

Kerberos 基本性质•安全：使网络窃听者不能获得必要的信息来伪装成另一客户。

•可靠：对所有以 Kerberos进行访问控制的服务来说，客户无法通过 Kerberos服务器的认证就意味着无法获得所需要的服务。

•透明：用户除了需要输入一个口令外，不必知道认证过程的存在以及细节。

•可伸缩：可支持大量用户和服务器。（采用模块化、 C/S结构）

Kerberos 应用• Kerberos 第 5版 是 Windows 2000 中最基本的安全协议，是默认的用户和服务器验证提供者。

• Linux 、 Unix 类系统也都支持 Kerberos协议。

• 作为网络环境的双向认证协议。

三个概念 在一个开放的网络环境中，所有用户都可以向任一服务器请求服务。每个服务器为了认证用户的合法性就必须知道每一个用户口令。显然网络规模越大维护越复杂，所以引入： 认证服务器（ AS）：它将所有用户的口令集中存放在本地数据库中；而且它与每一个应用服务器共享一个唯一的密钥。（密钥通过物理的或其他安全的方式分发）

客户端（ C）：代替用户与服务器进行信息交换。票据（ Ticket ） ：身份或权利的证明。Ticket 由 AS 以数据报形式发放给 C。

一个简单的认证对话对话过程(1) C AS : IDc || Pc || IDv

(2) AS C : Ticket

(3) C V : IDc || Ticket

Ticket = EKv [ IDc || ADc || IDv ]

字符说明C ＝客户端AS ＝认证服务器V ＝服务（服务器）IDc ＝在 C 上的用户标识IDv ＝ V 的标识符Pc ＝在 C 上的用户

口令ADc ＝ C 的网络地址Kv ＝ AS与 V 共享

加密密钥|| ＝级联

两个最突出问题：•用户每次访问一种新服务就需要一个新的票据，导致用户多次输入口令。

•用明文传递的用户口令会被窃听。

解决方案• 票据许可服务器 （ TGS）向已经通过 TGS认证的用户发放服务 Ticket。用户首先向 AS请求一张票据许可票 Tickettgs ，并将它保存在 C 中。每当用户要求一种新的服务时，客户便用这张能认证自己的 Tickettgs 向 TGS发出申请。 TGS给用户发回一张针对某种特定服务的服务许可票据 TicketV，客户将保留每一个TicketV，在每次请求相同服务时提供给服务器 V 来认证。

• Ticket 重用，设置生命期。

改进的认证对话• Once per user logon session:

(1) C AS : IDc || IDtgs

(2) AS C : EKc [ Tickettgs ]

• Once per type of service:

(3) C TGS: IDc||IDv||Tickettgs

(4) TGSC: TicketV

• Once per service session:

(5) CV: IDc || TicketV

Tickettgs =

EKtgs [ IDc || ADc || IDtgs || TS1 || Lifetime1]

TicketV =

EKV [ IDc || ADc || IDV || TS2 || Lifetime2]

• 符号说明IDtgs ＝ TGS 的标识符Kc ＝由用户口令导出的密钥TS1＝时间戳 TimeStamp

Lifetime1 ＝ 生存期

改进版过程说明(1) 客户通过向 AS发送用户 ID 、 TGS ID来请求一张代表该用户的票据许可票据。

(2) As发回一张加密过的票据作为响应，加密密钥是由用户口令导出的散列码。响应到达客户端后，客户端提示用户输入口令，产生密钥，解密报文。口令正确，票据正确恢复。

(3)客户端代表用户请求一张服务许可票据。(4)TGS 对收到的 Tickettgs 进行解密，通过检查 TGS ID来验证解

密是否成功。并检查票据的生存期，确保没有过期。比较用户 ID和网络地址与通过 AS 认证用户的信息是否一致。若允许用户访问V ， TGS 发回一张该 TicketV。两种票据的结构完全相同。

(5)客户端 C 代表用户请求某项服务。向 V 发送用户 ID和 TicketV 服务许可票据的报文。应用服务器解密票据。通过检查 IDV 来验证解密是否成功。并检查票据的生存期，确保没有过期。比较用户 ID和网络地址与通过 TGS 认证用户的信息是否一致。一致则向用户提供服务。

仍然存在的两个问题•很难选择 Ticket的生存期长短。短：用户多次重复输入口令；长：对手窃听网络得到 Ticket后，可在生存期结束前获得合法用户的资源。 （一般为 8小时）

•服务器不能向用户认证自己。

解决方案• 会话密钥（ Session Key）让 AS 以安全的方式向 C 和 TGS 提供同一个会话密钥，然后 C 向 TGS出示用 Session Key 加密个人信息（认证符） || Ticket 来证明身份。同样， TGS 向 C 和 V 作同样的事情。

• 认证符：使用 Session Key 加密（用户 ID、地址、时间戳）的报文。 Session Key 是安全的， V 在对 Ticket 认证之后，将认证符的时间戳 +1 ，并用 Session Key 加密发还给 C ； C 使用 Session Key 解密，得到时间戳 +1 ，和前次发送的认证符中的时间戳比较，来认证服务器。

Kerberos 第 4 版

第 4 版 报文交换总结（一）• 认证服务交换：获得票据许可票据(1) CAS : IDC || IDtgs || TS1

IDC ： 客户端将用户的身份标识告诉给 AS IDtgs ：告诉 AS 用户想要请求的 TGS TS1 ：允许 AS 验证客户端的时钟是否与 AS同步

(2) ASC : EKc[Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs]

Tickettgs = EKtgs[Kc,tgs || IDC || ADC || IDtgs || TS2 || Lifetime2 ]

Ekc：用基于用户口令的散列码来加密，使 AS 和 C 能够验证口令，并保护报文 (2)

Kc,tgs ：由 AS生成允许客户端与 TGS 间安全交换报文 TS2 ：通知客户端票据发出的时间

Lifetime2 ：通知客户端票据的有效期Tickettgs：客户用来访问 TGS 的票据

第 4 版 报文交换总结（二）• 票据许可服务交换：获得服务许可票据(3) CTGS : IDV || Tickettgs || AuthenticatorC

(4) TGSC : Kc,tgs [KC,V || IDV || TS4 || TicketV ]

TicketV = EKv [KC,V || IDC || ADC || IDV || TS4 || Lifetime4 ]

AuthenticatorC = E Kc,tgs [ IDC || ADC || TS3 ]

IDV ：告诉 TGS 用户访问的应用服务器 V

Tickettgs ：使 TGS确信该用户以通过 AS 的认证TicketV ：客户用来访问服务器 V 的票据AuthenticatorC ：由客户端产生认证符，证明票据的有效性ADC ：防止非法用户在另一台工作站上使用该票据TS3 ：通知 TGS此认证符产生时间。

第 4 版 报文交换总结（三）• 客户 / 服务器认证交换：获得服务

(5) CV : TicketV || AuthenticatorC

(6) VC : EKc,v [TS5 +1 ]

AuthenticatorC = E Kc, v [ IDC || ADC || TS5 ]

TicketV ＝ EKv[K C,V || IDC || ADC || IDV || TS4 || Lifetime4 ]

EKc,v ：使客户端确信该报文来自 V,仅有客户和服务器知道的密钥加密以防篡改。TicketV ：使服务器 V确信该用户已经通过 AS 的验证 K C,V ：客户端获得会话密钥的副本；用来解密认证符，以认证票据AuthenticatorC ：由客户端产生认证符，证明票据的有效性 TS4 ：由通知服务器该票据发出的时间TS5 +1 ：使 C确信这不是就回答的重放

Kerberos Realm 和多个Kerberos

• 完整的 Kerberos环境包含一个 kerberos服务器、许多客户和许多应用服务器，同时必须满足以下两个条件：

(1) Kerberos 服务器数据库必须包含所有的参与用户的 ID和用户口令的散列码。所有用户都想 Kerberos服务器注册。

(2) Kerberos 服务器必须与每一个服务器共享唯一的密钥。

这样的一种环境叫做Kerberos Realm。

• 当用户需要访问其他Realm的服务器时， Kerberos 提供了多个 Realm 间的认证机制。为了支持这种机制互操作的两个Realm之间必须满足一个条件：

(3) 每个互操作 Realm中Kerberos服务器要与另一 Realm中Kerberos服务器共享唯一的密钥。它们必须相互注册。

请求另一 Realm 中的服务(1) CAS : IDC || IDtgs || TS1

(2) ASC :

EKc[Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs]

(3) CTGS : IDrem || Tickettgs || AuthenticatorC

(4) TGSC :

Kc,tgs [KC,tgsrem || IDtgsrem || TS4 || Tickettgsrem ]

(5) CTGSrem :

IDVrem || Tickettgsrem || AuthenticatorC

(6) TGSrem C :

Kc,tgsrem [KC,Vrem || IDVrem || TSb || TicketVrem ]

(7) C Vrem : TicketVrem || AuthenticatorC

第 5 版做的主要改进• 对加密算法的依赖性• 对 TCP/IP 协议的依赖性• 报文字节序 （ big endian-> little endian）• 票据有效期： 8 bit表示（ 5~1280分钟） ( 双字节表示 )有任意长度有效期。

• 认证的转发： 4版不允许将发给一个用户的认证证书转发给其他主机或服务器。 5版允许。例如，某客户向打印服务器请求（打印其在文件服务器上的文件），打印服务器使用客户访问认证证书从文件服务器中取该客户的文件。此时， TGS代表客户充当代理，客户向 AS申请设置了 PROXIABLE标志位的票据许可票据， TGS收到后，向有不同的网络地址并且设置 PROXY标志的服务许可票据，应用服务器代替客户做出相应的请求。

• 领域间的认证： 4 版中，若有 N 个领域，需要有 N(N-1)/2 个Kerberos之间的安全密钥交换。第 5版引用 DNS解析的原理，领域组织为树状的层次结构，客户可以沿着树向上走到一个公共节点，然后在向下走到目的域。移动的每一步，域中的 TGS都要将票据许可票据转发到路径中的下一个 TGS。

• 取消重复加密： 4 版中，报文 2 、 4，提供给客户的票据被加密两次，一次采用目标服务器的密钥，一次采用客户知道的密钥。 5版去掉了不必要的第二次加密。 EKc[Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs] EKc[Kc,tgs || IDtgs || TS2 || Lifetime2 ] || Tickettgs

功能特性分析• 可信的第三方 Kerberos服务器

– 所需的密钥分配和管理变简单– AS负担认证工作，减轻应用服务器负担– 安全相关数据集中管理和保护，使攻击者入侵难以成功

• Ticket– 使 AS（ TGS）的认证结果和会话密钥安全传给 C

和 TGS（应用服务器）– 生存期内可重用，减少认证开销，提高方便性

•共享密钥– 为认证提供安全依据

功能特性分析

•TGS–降低用户口令的使用频度，提供更好的口令保护

–减轻 AS负担，提高系统效率•Session Key

–防止非法用户窃得 Ticket进行重放攻击–提供了对服务器得认证

•时间戳–防止对 Ticket和认证符的重放攻击

局限性分析• Kerberos服务器易受攻击

– 它的安全性决定了整个系统得安全性，若此关键环节发生问题，危害是灾难性的。

•口令攻击– 对手截获基于口令的密钥加密的内容，采用暴力破解成功后，得到口令也就到该用户的全部资源

•域间认证复杂

资源• 掌握 Kerberos概念的简单方法请参考：http://web.mit.edu/kerberos/www/dialogue.html

• MIT Kerberos 站点http://web.mit.edu/kerberos/

• USC/ISI Kerberos 站点http://www.isi.edu/gost/info/kerberos/

X.509 Authentication Service

• 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 crypto & digital signatures

– algorithms not standardised, but RSA recommended

• X.509 certificates are widely used

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

X.509 Certificates

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

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

CA Hierarchy Use

Certificate Revocation

• certificates have a period of validity

• may need to revoke before expiry, eg:1. user's private key is compromised

2. user is no longer certified by this CA

3. CA's certificate is compromised

• CA’s maintain list of revoked certificates– the Certificate Revocation List (CRL)

• users should check certs with CA’s CRL

Authentication Procedures

• X.509 includes three alternative authentication procedures:

• One-Way Authentication

• Two-Way Authentication

• Three-Way Authentication

• all use public-key signatures

One-Way Authentication

• 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

• message must include timestamp, nonce, B's identity and is signed by A

One-Way Authentication

Two-Way Authentication

• 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

• reply includes original nonce from A, also timestamp and nonce from B

Two-Way Authentication

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 signed copy of nonce from B

• means that timestamps need not be checked or relied upon

Three-Way Authentication

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

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

Public Key Infrastructure

Summary

• have considered:– Kerberos trusted key server system– X.509 authentication and certificates