Kerberos工作原理介绍

本文深入解析Kerberos协议的工作原理,包括简单的相互身份验证、sessionkey和密钥分发中心KDC的作用,以及sessionticket的引入。通过具体工作流程说明,帮助读者理解Kerberos如何确保网络安全。

Kerberos协议

参考英文网站,可知Kerberos(也称为Cerberus)来自古希腊神话中,指一个有三个头的狗,阻止活着的入侵者进入地下世界。Kerberos协议以此命名,其中三个组成部分为:Client、Server、KDC(密钥分发中心)。

 

1. 简单的相互身份验证

A向B发送信息时,会附加一个Authenticator(认证码,该数据结构=身份信息+时间戳)来进行彼此的身份验证。开始验证之前,A和B已经有一个有且只有二人知晓的密钥。下面是工作流程:

a. A用密钥加密了【信息+Authenticator(身份信息+时间戳)】,将其发给B

b. B用密钥解密了A发来的Authenticator,并将其中包含的时间戳记录下来。B将这个时间戳与自己的当前时间进行比较,如果这个时间差大于某个值(windows下默认是5分钟),B认为信息不是A发来的,拒绝后续验证。如果这个时间差小于设定值,B要检查在过去5分钟内,是否存在含有更早时间戳的Authenticator,如果没有,B认为信息确实是A发来了。至此,完成了B对A的验证。

c. B用密钥加密Athenticator里的时间戳,然后将其发回给A,以证明自己确实是B.

d. A收到后,解密出时间戳,经过自己的对比,确认了对方确实是B. 至此,完成了A对B的验证

2. 引入session key和密钥分发中心KDC

实现简单相互身份验证有一个前提,即,A和B必须有一个有且只有二人知晓的密钥。在2中,我们要设计一个密钥分发机制来完善1的流程。这里引入key distribution center, KDC密钥分发中心。当A尝试向B发信息时,KDC会分别向A、B发放一个加密过的session key,这相当于1中那个有且只有AB双方知晓的密钥(注意,在传输过程中,session key要再包裹一层密钥进行加密,下面将具体说到)。

3. 引入secret key(密钥的加密)

session key在传输过程中需要加密。因此我们又引入了一个加密密钥,叫做secret key(或者叫long term key,在用户账号验证中,这个key是衍生自账号密码). 这个key是KDC和A(或B)之间有且只有双方知晓的一个密钥。KDC与A之间进行传输时,是由仅有A与KDC双方知晓的key加密。KDC与B之间进行传输时,是由仅有B与KDC双方知晓的key加密。

4. 引入session ticket(密钥的识别)

实际应用中,一个KDC对应着许许多多的客户端和服务端,每个客户端与服务端之间都有一个共享的session key(密钥)。为了区别这些session key,我们引入session ticket的概念,它是一种内嵌了session key和客户端身份信息(原文authorization data for the client)的数据结构。相当于session key与客户端的1对1表。

下面是具体工作过程:

a. 客户端向KDC提交客户端身份信息(这个传输过程使用客户端secretkey进行加密),要求与服务端进行相互身份验证。

b. KDC生成一个仅有客户端与服务端知晓的session key。

c. KDC将session key附加上客户端身份信息形成了session ticket,并用服务端secret key加密session ticke后传给服务端。服务端收到了KDC回复,使用服务端secret key解密,获得了有且只有客户端和服务端二者知晓的密钥session key。

d. KDC将【session key+服务端secret key加密后的session ticket】用客户端secret key加密后,传给客户端。客户端收到了KDC的回复,用客户端secret key解密出【session key+服务端secret key加密后的session ticket】。解密出的两部分内容分开地放在一个安全的缓存中(一块隔离的内存空间,而不是硬盘上)。当客户端再次向服务端发送信息时,客户端就可以直接向服务端发送【要发送的信息+服务端secret key加密后的session ticket+用session key加密的Authenticator(身份信息+时间戳)】

e. 服务端收到了来自客户端的以上凭据,先用服务端secret key将session ticket解密,取得内嵌在session ticket里的session key,用其将Authenticator解密,得到了客户端发送消息的时间戳。之后按照1中简单相互身份验证过程中的步骤b, c, d继续进行。

 

PS:

1. session ticket可以被重复使用。客户端从KDC获得session ticket后,会将其放在安全缓存中(一块隔离的内存空间,而不是硬盘上)。每当客户端想要访问指定服务端,客户端就出示相应的session ticket。

2. session ticket有失效期,通常是8小时,可以在相应的Kerberos策略中设置。

3. 服务端不需要存储session ticket。KDC只负责发送信息,不验证信息是否发放到正确的对象。因为即使发错了对象,对方没有secret key(有且只有KDC和正确对象知晓的密钥),是解不开信息的。循序渐进了解Kerberos认证工作原理

 

转载地址:https://www.cnblogs.com/huamingao/p/7267423.html

 

 

<think>嗯,用户要求了解MIT Kerberos的身份验证原理和工作机制。从引用内容看,用户已经查阅过相关资料,但需要更系统的解释。用户可能正在研究网络安全或分布式系统认证方案,需要理论结合实践的理解。 Kerberos的核心是票据传递认证机制,这个协议设计得很精妙。根据引用[2]的流程图,整个流程分为AS、TGS和服务请求三个阶段。用户特别关注MIT实现版,需要强调其作为标准实现的特性。 在解释原理时要注意技术细节的准确性:比如KDC的组成、对称加密的应用、时间戳防重放等。引用[4]提到的单点登录特性值得展开说明,这是Kerberos在企业环境的核心价值。 考虑到用户可能是技术人员,准备在回答中加入具体技术元素:如加密算法类型(AES256)、票据有效期(默认8小时)、领域(REALM)概念等。同时要避免过于学术化,用TGT(门票兑换券)、服务票据(电影票)这样的生活类比帮助理解。 用户提供的引用[1]提到MIT版本支持多系统,这点可以在工作机制部分补充说明跨平台特性。引用[3]的神话隐喻很有趣,但技术文档里保持专业表述更合适。 最后考虑生成的问题要覆盖原理延伸(NTLM对比)、实践(配置要点)和进阶(PKINIT扩展),这样能形成知识闭环。特别准备加入“时间同步”这个容易被忽视但关键的问题点。</think>以下是MIT Kerberos身份验证原理与工作流程的详细说明: --- ### **Kerberos核心原理** Kerberos是一种基于**票据(Ticket)** 的网络认证协议,通过**对称加密**和**可信第三方(KDC)** 实现安全身份验证,核心目标包括: 1. 用户密码不在网络中明文传输 2. 实现单点登录(SSO) 3. 抵御中间人攻击与重放攻击[^4] --- ### **核心组件** | 组件 | 作用 | |---------------|----------------------------------------------------------------------| | **KDC** | 密钥分发中心,包含AS和TGS两个服务 | | **AS** | 认证服务器:验证用户初始身份,发放TGT | | **TGS** | 票据授权服务器:基于TGT发放服务票据 | | **Principal** | 主体标识(如 `user@REALM` 或 `host/server.example.com@REALM`) | | **Realm** | 管理域(如 `EXAMPLE.COM`),KDC负责该域内的认证 | --- ### **工作流程详解(三次通信)** #### **1. 客户端 → AS:获取TGT** - 用户输入账号密码,客户端生成认证请求 - AS验证用户身份,返回: - **TGT(票据授权票据)**:用KDC的$krbtgt$密钥加密,包含用户信息、会话密钥$K_{TGS}$、有效期等 - **临时会话密钥**:用用户密码派生的密钥加密 > *数学表达*: > $ \text{AS\_Response} = \\{ \text{TGT}\_{enc(K\_{krbtgt})}, \\; K\_{TGS}\_{enc(K\_{user})} \\} $ #### **2. 客户端 → TGS:请求服务票据** - 客户端解密获得$K_{TGS}$,构造服务请求: - 提交TGT + 服务Principal(如 `host/server.example.com`) - 附加**认证符(Authenticator)**:用$K_{TGS}$加密的时间戳 - TGS验证TGT和认证符后返回: - **服务票据(Service Ticket)**:用目标服务的密钥加密 - **服务会话密钥**$K_{Service}$:用$K_{TGS}$加密 > *数学表达*: > $ \text{TGS\_Response} = \\{ \text{Ticket}\_{Service}\_{enc(K\_{Service})}, \\; K\_{Service}\_{enc(K\_{TGS})} \\} $ #### **3. 客户端 → 目标服务:访问服务** - 客户端向服务发送: - 服务票据 - 新认证符(用$K_{Service}$加密的时间戳) - 服务解密票据获得$K_{Service}$,验证认证符后允许访问 - **双向认证**:服务可返回用$K_{Service}$加密的时间戳确认身份[^2] ```mermaid sequenceDiagram participant Client participant AS participant TGS participant Service Client->>AS: 请求TGT (用户身份) AS->>Client: TGT + $K_{TGS}$ (加密) Client->>TGS: TGT + 服务请求 + 认证符 TGS->>Client: 服务票据 + $K_{Service}$ Client->>Service: 服务票据 + 认证符 Service->>Client: 服务响应 (可选) ``` --- ### **MIT Kerberos关键技术特性** 1. **加密算法**:支持AES-256、AES-128等(通过`krb5.conf`配置) 2. **票据有效期**:默认8-10小时,平衡安全与便利 3. **时间同步**:依赖NTP,时间偏差需≤5分钟(防重放攻击) 4. **Keytab文件**:机器密钥存储文件,替代密码认证(用于服务注册)[^2] 5. **跨域信任**:不同Realm间建立信任链实现跨域认证 --- ### **安全机制** | 机制 | 作用 | |------------------|----------------------------------------------------------------------| | **会话密钥** | 每次认证生成唯一密钥,避免密码暴露 | | **时间戳** | 认证符包含精确时间,抵御重放攻击 | | **票据有效期** | 限制票据生命周期,降低被盗用风险 | | **双向认证** | 服务端可向客户端证明自身合法性 | > *MIT实现特别优化了内存管理和票据续期机制,支持大规模企业部署[^1]* --- ### **典型应用场景** - Hadoop集群安全认证 - Windows Active Directory域认证 - SSH单点登录 - Web服务API鉴权(如REST API) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值