
1349a1ae15a2e54c2bc4020aec0038bb.ppt
- Количество слайдов: 43
第十三讲. Kerberos认证协议与 X. 509 上海交通大学计算机科学系
1. 密钥管理 • 所有的密码系统都存在: 如何安全可靠地分 配密钥 • 许多情况下, 出现的安全问题不是因为密码 算法被破, 而是密钥分配系统被破 • 理想的情况是, 密钥分配协议应得到形式化 验证, 目前已有这方面的结果
2. Physical Delivery • 传统的物理方法 • 秘密传送
3. 认证密钥服务器 • • • 第三方可信的在线服务器 服务器与每个客户有个公享秘密钥 向客户分发密钥 可以利用对称密钥算法 Kerberos
4. Kerberos认证服务协议 • 是一项鉴别协议 • 解决的问题: • 在一个公开的分布式环境中, 作站上的用户 希望访问分布在网络中的服务器上的服务 • 服务器希望能够限制授权用户的访问,并能对 服务请求进行鉴别。
5. Kerberos使用的加密体制 • Kerberos不是为每一个服务器构造一个身份认 证协议,而是提供一个中心认证服务器,提供 用户到服务器和服务器到用户的认证服务。 • Kerberos采用传统加密算法(无公钥体制) • 常用版本:Kerberos Version 4和Version 5 (RFC 1510)
6. Kerberos的解决方案 • 在一个分布式的client/server体系机构中采用一个或 多个Kerberos服务器提供一个认证服务。 • 总体方案是提供一个可信第三方的认证服务。
7. Kerberos系统满足的要求 • 安全。网络窃听者不能获得必要信息以假冒其 它用户;Kerberos应足够强壮以至于潜在的敌 人无法找到它的弱点连接。 • 可靠。Kerberos应高度可靠,并且应借助于一 个分布式服务器体系结构,使得一个系统能够 备份另一个系统。 • 透明。理想情况下,用户除了要求输入口令以 外应感觉不到认证的发生。 • 可伸缩。系统应能够支持大数量的客户和服务 器
8. Kerberos Version 4 • 引入一个信任的第三方认证服务,采用一个基 于Needham & Schroeder协议。 • 采用DES,精心设计协议,提供认证服务。
9. 一个简单的认证对话 • 引入认证服务器(AS),它知道所有用户的口令 并将它们存储在一个中央数据库中。另外,AS 与每一个服务器共有一个唯一的保密密钥。这 些密钥已经通过物理上或以更安全的手段分发
考虑以下假定的对话: (1) C AS: IDC || PC || IDV (2) AS C: Ticket (3) C V : IDC || Ticket AS Ticket = EKV[IDC || ADC || IDV] 其中: C : client AS : Authentication Server V : server IDC: identifier of user on C ADC防止何种攻击? (1) (2) C IDV PC ADC KV (3) V : identifier of V : password of user on C : network address of C : AS与V共有的保密密钥
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 : Ticket. V Kerberos AS TGS (2) (3) (1) C 每种服务会话一次: (5) C V : IDC || Ticket. V Tickettgs = EKtgs[IDC||ADC||IDtgs||TS 1||Lifetime 1] Ticket. V = EKV[IDC||ADC||IDV||TS 2||Lifetime 2] (4) (5) V
11. 方案的详细描述 • 用户向AS请求代表该用户的票据许可票据。 • AS发回加密的票据,密钥由口令导出(Why?) • 票据许可票据包含用户ID、网络地址、TGS的 ID、时戳与生存期(Why? )。 • 用户请求服务许可票据。 • TGS验证,如通过则发服务许可票据。 • 用户使用服务许可票据请求服务。
• 改进方案仍存在的问题 –与TGS相关的生存期问题; • 太长则?太短则?如何应付票据的过期使 用? –需要服务器向客户进行认证其本身; • 假的服务器
12. Kerberos V 4 的认证对话 • 解决方案 –会话密钥(session key) AS用安全方式向用户和TGS各自提供一块秘密 信息, 然后用户也以安全方式向TGS出示该秘密来证 明自己 的身份。这个秘密就是会话密钥
13. Kerberos V 4报文交换总结(1) • 认证服务交换:获得票据许可票据 – (1) C AS : IDC || IDtgs || TS 1 – (2) AS C : EKC[Kc, tgs || IDtgs || TS 2 || Lifetime 2 || Tickettgs] – Tickettgs = EKtgs [Kc, tgs || IDC || ADC || IDtgs || TS 2 || Lifetime 2]
Kerberos V 4报文交换总结(2) • 票据许可服务交换:获得服务许可票据 –(3) C TGS : IDV || Tickettgs || Authenticatorc –(4) TGS C : EKc, tgs[Kc, v || IDV || TS 4 || Ticketv] Tickettgs = EKtgs[Kc, tgs|| IDC|| ADC|| IDtgs || TS 2 || Lifetime 2] Ticketv = EKV[Kc, v||IDC||ADC|| IDv||TS 4||Lifetime 4] Authenticatorc = EKc, tgs[IDc||ADc||TS 3]
Kerberos V 4报文交换总结(3) • 客户/服务器认证交换:获得服务 –(5) C V : Ticketv || Authenticatorc –(6) V C : EKc, v[TS 5+1] ( for mutual authentication) Ticketv = EKV[Kc, v||IDc||ADc||IDv||TS 4||Lifetime 4] Authenticatorc = EKc, v[IDc||ADc||TS 5]
14. 公开公证或证书机构 • • 可信的离线服务器 server 有个公开的公钥 server 对每个用户签名公钥证书 利用公钥加密
15. 要素与基本原理 (a) 认证服务交换 Message(1) Client 请求 ticket-granting ticket IDC : 告诉AS本client端的用户标识; IDtgs : 告诉AS用户请求访问TGS; TS 1 : 让AS验证client端的时钟是与AS的时钟同步的; Message(2) AS返回ticket-granting ticket EKC : 基于用户口令的加密,使得AS和client可以验证口令, 并保护Message(2)。 Kc, tgs : session key的副本,由AS产生,client可用于在AS与 client 之间信息的安全交换,而不必共用一个永久的key。 IDtgs : 确认这个ticket是为TGS制作的。 TS 2 : 告诉client该ticket签发的时间。 Lifetime 2: 告诉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签发的; TS 4 : 告诉client该ticket签发的时间; Ticket. V : 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; TS 5+1: 使C确信这不使报文重放; Ticket. V : 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 || TS 1 (2) AS C : EKC[Kc, tgs || IDtgs || TS 2 || Lifetime 2 || Tickettgs] (3) C TGS: IDtgsrem || Tickettgs || Authenticatorc (4) TGS C: EKc, tgs[Kc, tgsrem || IDtgsrem || TS 4 || Tickettgsrem] (5) C TGSrem: IDvrem || Tickettgsrem || Authenticatorc (6) TGS C: EKc, tgsrem[Kc, vrem || IDvrem || TSb || Ticketvrem] (7) C Vrem: Ticketvrem || Authenticatorc AS TGS (4) (1) (2) (3) C TGSrem (5) (6) (7) Vrem
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 (v 2+)
25. X. 509 证书(续) • • subject unique identifier (v 2+) extension fields (v 3) signature (of hash of all fields in certificate) notation: CA<<User>> means CA has signed 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{t. A, r. A, B, sgn. Data, Ek. Ub[Kab] } • 验证A的身份及消息来源于 • 发送到 B • 包括内容: timestamp, nonce, B's identity signed by A •
32. 双向认证 • 2 消息 (A->B, B->A) A{t. A, r. A, B, sgn. Data, Ek. Ub[Kab] } B{t. B, r. B, A, r. A, sgn. Data, Ek. Ua[Kba] }
33. 三向认证 • 3 messages (A->B, B->A, A->B) A{t. A, r. A, B, sgn. Data, Ek. Ub[Kab] } B{t. B, r. B, A, r. A, sgn. Data, Ek. Ua[Kba] } A{r. B}
34. 小结 • 密钥管理问题 • X. 509 证书与 CA's
1349a1ae15a2e54c2bc4020aec0038bb.ppt