第十三讲 . Kerberos 认证协议与 X.509

上海交通大学计算机科学系

1. 密钥管理 • 所有的密码系统都存在 : 如何安全 \ 可靠地分配密钥• 许多情况下 , 出现的安全问题不是因为密码算法被破 , 而是密钥分配系统被破 • 理想的情况是 , 密钥分配协议应得到形式化验证 , 目前已有这方面的结果

2. Physical Delivery• 传统的物理方法• 秘密传送

3. 认证密钥服务器• 第三方可信的在线服务器• 服务器与每个客户有个公享秘密钥• 向客户分发密钥 • 可以利用对称密钥算法• Kerberos

4. Kerberos 认证服务协议• 是一项鉴别协议• 解决的问题：• 在一个公开的分布式环境中，工作站上的用户希望访问分布在网络中的服务器上的服务• 服务器希望能够限制授权用户的访问，并能对服务请求进行鉴别。

5.Kerberos使用的加密体制• Kerberos 不是为每一个服务器构造一个身份认证协议，而是提供一个中心认证服务器，提供用户到服务器和服务器到用户的认证服务。• Kerberos 采用传统加密算法（无公钥体制）• 常用版本： Kerberos Version4 和 Version5 (RFC1510)

6. Kerberos 的解决方案• 在一个分布式的 client/server 体系机构中采用一个或多个 Kerberos 服务器提供一个认证服务。• 总体方案是提供一个可信第三方的认证服务。

7. Kerberos 系统满足的要求• 安全。网络窃听者不能获得必要信息以假冒其它用户； Kerberos 应足够强壮以至于潜在的敌人无法找到它的弱点连接。• 可靠。 Kerberos 应高度可靠，并且应借助于一 个分布式服务器体系结构，使得一个系统能够备份另一个系统。• 透明。理想情况下，用户除了要求输入口令以外应感觉不到认证的发生。• 可伸缩。系统应能够支持大数量的客户和服务器

8. Kerberos Version4• 引入一个信任的第三方认证服务，采用一个基于 Needham & Schroeder 协议。• 采用 DES ，精心设计协议，提供认证服务。

9. 一个简单的认证对话• 引入认证服务器 (AS) ，它知道所有用户的口令并将它们存储在一个中央数据库中。另外，AS与每一个服务器共有一个唯一的保密密钥。这些密钥已经通过物理上或以更安全的手段分发

考虑以下假定的对话：(1) C AS: IDC || PC || IDV

(2) AS C: Ticket(3) C V : IDC || Ticket

Ticket = EKV[IDC || ADC || ID

V]

IDV : identifier of VPC : password of user on CADC : network address of CKV : AS 与 V 共有的保密密钥

C V

AS

(1) (2)

(3)

ADC 防止何种攻击？

考虑以下假定的对话：(1) C AS: IDC || PC || IDV

(2) AS C: Ticket(3) C V : IDC || Ticket

Ticket = EKV[IDC || ADC || ID

V]

IDV : identifier of VPC : password of user on CADC : network address of CKV : AS 与 V 共有的保密密钥

C V

AS

(1) (2)

(3)

ADC 防止何种攻击？

其中： C : client AS : Authentication Server V : server IDC: identifier of user on C

10. 上述对话存在的问题• 两个主要问题

– 希望用户输入口令的次数最少。– 口令以明文传送会被窃听。

• 解决办法– 票据重用（ ticket reusable ）– 票据需可服务器（ ticket-granting server ， TGS ）

改进后的假想的对话：用户登录的每次对话 :(1) C AS : IDC || IDtgs

(2) AS C : EKC[Tickettgs]

每种服务类型一次：(3) C TGS : IDC || IDv || Tickettgs

(4) TGS C : TicketV

每种服务会话一次：(5) C V : IDC || TicketV

Tickettgs = EKtgs[IDC||ADC||IDtgs||TS1||Lifetime1]

TicketV = EKV[IDC||ADC||IDV||TS2||Lifetime2]

C V

AS

(1) (2) (3)

TGS

(4)

(5)

Kerberos

11. 方案的详细描述• 用户向AS请求代表该用户的票据许可票据。• AS 发回加密的票据，密钥由口令导出 (Why ？ )• 票据许可票据包含用户 ID、网络地址、 TGS 的 ID、时戳与生存期 (Why?) 。• 用户请求服务许可票据。• TGS验证，如通过则发服务许可票据。• 用户使用服务许可票据请求服务。

• 改进方案仍存在的问题

–与 TGS 相关的生存期问题；•太长则？太短则？如何应付票据的过期使用？

–需要服务器向客户进行认证其本身；•假的服务器

12. Kerberos V4 的认证对话•解决方案

–会话密钥（ session key）AS用安全方式向用户和 TGS各自提供一块秘密信息，然后用户也以安全方式向 TGS出示该秘密来证明自己的身份。这个秘密就是会话密钥

13.Kerberos V4 报文交换总结（ 1）• 认证服务交换：获得票据许可票据

– (1) C AS : IDC || IDtgs || TS1

– (2) AS C : EKC[Kc,tgs || IDtgs || TS2 || Lifetime2 || Tic

kettgs]

– Tickettgs = EKtgs [Kc,tgs || IDC || ADC || IDtgs || TS2 || Lif

etime2]

Kerberos V4 报文交换总结（ 2）• 票据许可服务交换：获得服务许可票据

– (3) C TGS : IDV || Tickettgs || Authenticatorc– (4) TGS C : EKc,tgs[Kc,v || IDV || TS4 || Ticketv]Tickettgs = EKtgs[Kc,tgs|| IDC|| ADC|| IDtgs || TS2 || Lifetime2]Ticketv = EKV[Kc,v||IDC||ADC|| IDv||TS4||Lifetime4]Authenticatorc = EKc,tgs[IDc||ADc||TS3]

Kerberos V4报文交换总结（ 3）• 客户 / 服务器认证交换：获得服务

– (5) C V : Ticketv || Authenticatorc– (6) V C : EKc,v[TS5+1] ( for mutual authentication)Ticketv = EKV[Kc,v||IDc||ADc||IDv||TS4||Lifetime4]Authenticatorc = EKc,v[IDc||ADc||TS5]

14. 公开公证或证书机构 • 可信的离线服务器 • server 有个公开的公钥 • server 对每个用户签名公钥证书• 利用公钥加密

15. 要素与基本原理(a) 认证服务交换Message(1) Client 请求 ticket-granting ticket IDC : 告诉 AS 本 client 端的用户标识； IDtgs : 告诉 AS 用户请求访问 TGS ； TS1 : 让 AS 验证 client 端的时钟是与 AS 的时钟同步的；Message(2) AS 返回 ticket-granting ticket EKC

: 基于用户口令的加密，使得 AS 和 client 可以验证口令，并保护 Message(2) 。 Kc,tgs : session key 的副本，由 AS 产生， client 可用于在 AS 与 clie

nt之间信息的安全交换，而不必共用一个永久的 key 。 IDtgs : 确认这个 ticket 是为 TGS 制作的。 TS2 : 告诉 client 该 ticket 签发的时间。 Lifetime2: 告诉 client 该 ticket 的有效期； Tickettgs: client 用来访问 TGS 的 ticket 。

16. 基本原理 (续 )(b) 票据许可服务交换Message(3) client 请求 service-granting ticket IDv: 告诉 TGS 用户要访问服务器 V ； Tickettgs : 向 TGS 证实该用户已被 AS 认证；Authenticatorc: 由 client 生成，用于验证 ticket ；Message(4) TGS 返回 service-granting ticket EKc,tgs

: 仅由 C 和 TGS 共享的密钥；用以保护 Message(4) ； Kc,tgs: session key 的副本，由 TGS 生成，供 client 和 server 之间信息的安全交换，而无须共用一个永久密钥。 IDv : 确认该 ticket 是为 server V 签发的； TS4 : 告诉 client 该 ticket 签发的时间； TicketV : client 用以访问服务器 V 的 ticket ； Tickettgs: 可重用，从而用户不必重新输入口令； EKtgs

: ticket 用只有 AS 和 TGS 才知道的密钥加密，以预防篡改； Kc,tgs : TGS 可用的 session key 副本，用于解密 authenticator, 从而认证 ticket ； IDc : 指明该 ticket 的正确主人；

17 基本原理客户 / 服务器鉴别交换 :

Message(5) client 请求服务 Ticketv : 向服务器证实该用户已被 AS 认证； Authenticatorc: 由客户生成，用于验证 ticket 有效；Message(6) 客户对服务器的可选认证 Ekc,v

: 使 C 确认报文来自 V ； TS5 ＋ 1 ： 使 C 确信这不使报文重放； TicketV : client 用以访问服务器 V 的 ticket ； EKv

: 用只有 AS 和 TGS 才知道的密钥加密的票据，以预 防篡改； Kc,v: 用户的会话密钥副本； IDc ： 票据的合法用户； ADc ： 防止非法使用； IDv: 使服务器确信解密正确；

18.Kerberos 领域和多个域服务• 一个完整的 Kerberos 环境（域）包括一个 Kerberos 服务器，一组工作站，和一组应用服务器，满足下列要求：

– Kerberos 服务器必须在其数据库中拥有所有参与用户的 ID(UID) 和口令散列表。所有用户均在 Kerberos 服务器上注册。– Kerberos 服务器必须与每一个服务器之间共享一个保密密钥。所有服务器均在 Kerberos服务器上注册。

19. 不同域间的鉴别机制• 条件：• 每一个辖区的 Kerberos 服务器与其它辖区内的 Kerberos 服务器之间共享一个保密密钥。两个 Kerberos 服务器互相注册。

20. 获得另一领域中的认证服务• 分三步骤：（ 1）获得本地 TGS 的访问权；（ 2）请求一张远程 TGS 的票据许可票据；（ 3）向远程 TGS申请其领域内的服务许可票据

细节描述：(1) C AS : IDC || IDtgs || TS1 (2) AS C : EKC

[Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs](3) C TGS: IDtgsrem || Tickettgs || Authenticatorc

(4) TGS C: EKc,tgs[Kc,tgsrem || IDtgsrem || TS4 || Tickettgsrem]

(5) C TGSrem: IDvrem || Tickettgsrem || Authenticatorc

(6) TGS C: EKc,tgsrem[Kc,vrem || IDvrem || TSb || Ticketvrem]

(7) C Vrem: Ticketvrem || Authenticatorc

C

AS TGS TGSrem

Vrem

(1) (2)(3) (4) (5)

(6)

(7)

21. Kerberos Version 5• 改进 version 4 的环境缺陷

– 加密系统依赖性，需 DES– Internet 协议依赖性，需 IP 地址– 消息字节次序（不明确字节顺序）– Ticket 的时效性（可能太短）– 认证转发，用户的认证不能转发到其它主机或用户。– 域间认证，

22. 公钥证书• 公钥管理包括公钥证书的使用• 证书将用户身份与公钥绑定• 也包括其他信息 :有效期、使用权限• 所有内容有可信中心签名 (CA) • 假设任何人可以得到或已知 CA的公钥，并验证证书

23. X.509 鉴别服务• CCITT X.500 一部分，目录服务标准• X.509 定义了认证服务框架 • 这种目录可以存储证书 • 定义了利用证书的认证协议• 使用公钥密码与数字签名 • 推荐使用 RSA （不是标准）

24. X.509 证书• 由证书授权 (CA) 机构发送：• each certificate contains: • 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+)

25. X.509 证书（续）• subject unique identifier (v2+) • extension fields (v3) • signature (of hash of all fields in certificate) • notation: CA<<User>> means CA has sign

ed certificate details for User

26. 证书 扩展项 • 证书中，其它信息是有必要的• 如： email address/URL, policy details, usage constraints etc • 参见 SSL的使用

27. 证书性质• 任何能够访问 CA的用户，可以得到 CA上的任何证书• 只有 CA 能够修改证书 • 因为证书不能伪造，证书可以放在目录中•

28. CA 分层结构 • 如果两个用户享有一个共同的 CA，他们可以得到CA的一个相同的公钥• 若不是一个 CA，则需要 CA分层• 利用证书链验证其它 CA • 每个 CA 有对客户的证书和其上一级 CA 的证书 • 每个用户相信更高层的 CA’S • 能够使得任何 CA 的用户验证其它 CA签发的任何证书

29. CA 分层

• A acquires B certificate following chain: • X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>> • B acquires A certificate following chain: • Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>

•

30. 认证流程• X.509 包括三种认证形式 : • 单向认证（ One-Way Authentication ）• 双向认证（ Two-Way Authentication ）• 三向认证（ Three-Way Authentication ）

31. 单向认证• 1 个消息 ( A->B) ： A{tA, rA, B, sgnData, EkUb[Kab] }• 验证 A的身份及消息来源于• 发送到 B • 包括内容： timestamp, nonce, B's identity signed by A •

32. 双向认证• 2 消息 (A->B, B->A) A{tA, rA, B, sgnData, EkUb[Kab] }

B{tB, rB, A, rA, sgnData, EkUa[Kba] }

33. 三向认证• 3 messages (A->B, B->A, A->B) A{tA, rA, B, sgnData, EkUb[Kab] }

B{tB, rB, A, rA, sgnData, EkUa[Kba] }

A{rB}

34. 小结• 密钥管理问题 • X.509 证书与 CA's