3.1. The Authentication Service Exchange (认证服务交换)

摘要

消息方向	消息类型	章节
1. 客户端到 Kerberos	KRB_AS_REQ	5.4.1
2. Kerberos 到客户端	KRB_AS_REP 或 KRB_ERROR	5.4.2 或 5.9.1

客户端与 Kerberos 认证服务器之间的认证服务 (Authentication Service, AS) 交换由客户端在希望获取给定服务器的认证凭证但当前不持有凭证时启动.在其基本形式中, 客户端的密钥用于加密和解密.此交换通常在登录会话开始时使用, 以获取票据授予服务器的凭证, 随后将用于获取其他服务器的凭证 (请参见第 3.3 节), 而无需进一步使用客户端的密钥.此交换也用于请求不能通过票据授予服务中介的服务的凭证, 而是需要主体密钥的知识, 例如密码更改服务 (密码更改服务拒绝请求, 除非请求者可以证明用户旧密码的知识; 要求此知识可防止有人走到无人看管的会话旁进行未经授权的密码更改).

此交换本身不提供对用户身份的任何保证.要认证登录到本地系统的用户, 可以首先在 TGS 交换中使用 AS 交换中获得的凭证来获取本地服务器的凭证; 然后这些凭证必须由本地服务器通过成功完成客户端/服务器交换来验证.

AS 交换由两条消息组成: 从客户端到 Kerberos 的 KRB_AS_REQ, 以及作为回复的 KRB_AS_REP 或 KRB_ERROR.这些消息的格式在第 5.4.1、5.4.2 和 5.9.1 节中描述.

在请求中, 客户端发送 (明文) 其自己的身份和它请求凭证的服务器的身份、有关它请求的凭证的其他信息以及随机生成的随机数 (nonce), 可用于检测重放并将回复与匹配的请求关联.此随机数必须 (MUST) 由客户端随机生成并记住, 以便针对预期回复中的随机数进行检查.响应 KRB_AS_REP 包含客户端向服务器呈现的票据以及将由客户端和服务器共享的会话密钥.会话密钥和附加信息使用客户端的密钥加密.KRB_AS_REP 消息的加密部分还包含必须 (MUST) 与 KRB_AS_REQ 消息中的随机数匹配的随机数.

如果没有预认证, 认证服务器不知道客户端实际上是请求中命名的主体.它只是发送回复而不知道或不关心它们是否相同.这是可以接受的, 因为除了在请求中给出身份的主体之外, 没有人能够使用回复.其关键信息使用该主体的密钥加密.然而, 攻击者可以发送 KRB_AS_REQ 消息以获取已知明文以攻击主体的密钥.特别是如果密钥基于密码, 这可能会产生安全暴露.因此初始请求支持可选字段, 可用于传递初始交换可能需要的附加信息.此字段应该 (SHOULD) 用于第 3.1.1 节和第 5.2.7 节中描述的预认证.

可能会发生各种错误; 这些错误由错误响应 (KRB_ERROR) 而不是 KRB_AS_REP 响应指示.错误消息未加密.KRB_ERROR 消息包含可用于将其与它回复的消息关联的信息.KRB_ERROR 消息的内容不受完整性保护.因此, 客户端无法检测重放、伪造或修改.此问题的解决方案将包含在协议的未来版本中.

3.1.1. Generation of KRB_AS_REQ Message (生成 KRB_AS_REQ 消息)

客户端可以在初始请求中指定多个选项.这些选项包括是否执行预认证; 请求的票据是否可续期、可代理或可转发; 它是否应该延期或允许派生票据延期; 以及如果由于配置约束请求的票据过期日期不能由不可续期票据满足时, 是否接受可续期票据来代替不可续期票据.

客户端准备 KRB_AS_REQ 消息并将其发送到 KDC.

3.1.2. Receipt of KRB_AS_REQ Message (接收 KRB_AS_REQ 消息)

如果一切顺利, 处理 KRB_AS_REQ 消息将导致创建客户端向服务器呈现的票据.票据的格式在第 5.3 节中描述.

因为 Kerberos 可以在不可靠的传输 (如 UDP) 上运行, 所以 KDC 必须 (MUST) 准备好在响应丢失的情况下重新传输响应.如果 KDC 接收到与它最近成功处理的请求相同的请求, 则 KDC 必须 (MUST) 用 KRB_AS_REP 消息而不是重放错误进行响应.为了减少提供给潜在攻击者的密文, KDC 可以 (MAY) 发送首次处理请求时生成的相同响应.即使实际使用的传输是可靠的, KDC 也必须 (MUST) 遵守此重放行为.

3.1.3. Generation of KRB_AS_REP Message (生成 KRB_AS_REP 消息)

认证服务器在其数据库中查找 KRB_AS_REQ 中命名的客户端和服务器主体, 提取它们各自的密钥.如果请求中命名的请求客户端主体未知, 因为它不存在于 KDC 的主体数据库中, 则返回带有 KDC_ERR_C_PRINCIPAL_UNKNOWN 代码的错误消息.

如果需要, 服务器预认证请求, 如果预认证检查失败, 则返回带有代码 KDC_ERR_PREAUTH_FAILED 的错误消息.如果需要预认证但请求中不存在, 则返回带有代码 KDC_ERR_PREAUTH_REQUIRED 的错误消息, 并且 METHOD-DATA 对象将存储在 KRB-ERROR 消息的 e-data 字段中以指定哪些预认证机制是可接受的.通常这将包括如下所述的 PA-ETYPE-INFO 和/或 PA-ETYPE-INFO2 元素.如果服务器无法适应客户端请求的任何加密类型, 则返回带有代码 KDC_ERR_ETYPE_NOSUPP 的错误消息.否则, KDC 生成一个 "随机" 会话密钥, 这意味着除其他外, 应该不可能根据对过去会话密钥的了解来猜测下一个会话密钥.虽然如果基于密码学原理, 这可以在伪随机数生成器中实现, 但使用真正的随机数生成器更可取, 例如基于随机物理现象测量的生成器.有关随机性的深入讨论, 请参见 [RFC4086].

作为对 AS 请求的响应, 如果在 Kerberos 数据库中为客户端注册了多个加密密钥, 则 KDC 使用 AS 请求中的 etype 字段来选择用于保护发送给客户端的 KRB_AS_REP 消息的加密部分的加密方法.如果 etype 列表中有多个支持的强加密类型, 则 KDC 应该 (SHOULD) 使用加密密钥可用的第一个有效强 etype.

当用户的密钥从密码或口令生成时, 使用特定加密密钥类型的字符串到密钥函数, 如 [RFC3961] 中所指定.字符串到密钥函数的盐值和附加参数具有默认值 (分别由第 4 节和加密机制规范指定), 可以通过预认证数据 (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2 等) 覆盖.由于假定 KDC 仅存储结果密钥的副本, 因此除了更改主体的密钥时, 不应更改基于密码的密钥的这些值.

当 AS 服务器要在 KRB-ERROR 或 AS-REP 中包含预认证数据时, 如果客户端的 AS-REQ 的 etype 字段列出至少一个 "较新" 的加密类型, 它必须 (MUST) 使用 PA-ETYPE-INFO2, 而不是 PA-ETYPE-INFO.否则 (当客户端的 AS-REQ 的 etype 字段未列出任何 "较新" 的加密类型时), 它必须 (MUST) 同时发送 PA-ETYPE-INFO2 和 PA-ETYPE-INFO (两者都有每个 enctype 的条目)."较新" 的 enctype 是与本 RFC 的发布同时或之后首次正式指定的任何 enctype.DES、3DES 或 RC4 以及 [RFC1510] 中定义的任何 enctype 都不是 "较新" 的 enctype.

在不联系 KDC 的情况下, 无法可靠地根据口令生成用户的密钥, 因为不知道是否需要备用盐或参数值.

KDC 将尝试从 etype 字段中的方法列表分配随机会话密钥的类型.KDC 将使用提供的方法列表和来自 Kerberos 数据库的信息 (指示应用程序服务器可接受的加密方法) 来选择适当的类型.KDC 不会颁发具有弱会话密钥加密类型的票据.

如果请求的开始时间不存在、指示过去的时间或在 KDC 可接受的时钟偏移窗口内并且未指定 POSTDATE 选项, 则票据的开始时间设置为认证服务器的当前时间.如果它指示超出可接受时钟偏移的未来时间, 但未指定 POSTDATED 选项, 则返回错误 KDC_ERR_CANNOT_POSTDATE.否则, 将根据本地域的策略检查请求的开始时间 (管理员可能决定禁止某些类型或范围的延期票据), 如果票据的开始时间可接受, 则按请求设置, 并在新票据中设置 INVALID 标志.延期票据在使用前必须 (MUST) 通过在到达开始时间后将其呈现给 KDC 来验证.

票据的过期时间将设置为请求的结束时间和由本地策略确定的时间中的较早者, 可能使用特定于域或主体的因素.例如, 过期时间可以 (MAY) 设置为以下中的最早时间:

KRB_AS_REQ 消息中请求的过期时间 (endtime).
票据的开始时间加上来自认证服务器数据库的与客户端主体关联的最大允许生命周期.
票据的开始时间加上与服务器主体关联的最大允许生命周期.
票据的开始时间加上本地域的策略设置的最大生命周期.

如果请求的过期时间减去开始时间 (如上所确定) 小于站点确定的最小生命周期, 则返回带有代码 KDC_ERR_NEVER_VALID 的错误消息.如果票据的请求过期时间超过如上所确定的时间, 并且如果请求了 'RENEWABLE-OK' 选项, 则在新票据中设置 'RENEWABLE' 标志, 并且 renew-till 值设置为就像请求了 'RENEWABLE' 选项一样 (字段和选项名称在第 5.4.1 节中完整描述).

如果已请求 RENEWABLE 选项或如果已设置 RENEWABLE-OK 选项并且要颁发可续期票据, 则 renew-till 字段可以 (MAY) 设置为以下中的最早时间:

其请求的值.
票据的开始时间加上与主体数据库条目关联的两个最大可续期生命周期中的最小值.
票据的开始时间加上本地域的策略设置的最大可续期生命周期.

如果已请求新票据的标志字段并且本地域的策略允许, 则将设置以下选项: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.如果新票据是延期的 (开始时间在未来), 则其 INVALID 标志也将被设置.

如果以上所有操作都成功, 服务器将使用从 Kerberos 数据库中服务器主体记录中提取的加密密钥, 使用与服务器主体密钥关联的加密类型来加密票据的密文部分.(此选择不受请求中 etype 字段的影响.) 然后它格式化 KRB_AS_REP 消息 (请参见第 5.4.2 节), 将请求中的地址复制到响应的 caddr 中, 将任何需要的预认证数据放入响应的 padata 中, 并使用请求的 etype 字段中请求的可接受加密方法或正在使用的预认证机制指定的某个密钥在客户端的密钥中加密密文部分.

3.1.4. Generation of KRB_ERROR Message (生成 KRB_ERROR 消息)

可能会发生几个错误, 认证服务器通过向客户端返回错误消息 KRB_ERROR 进行响应, 其中 error-code 和 e-text 字段设置为适当的值. 错误消息的内容和详细信息在第 5.9.1 节中描述.

错误生成逻辑是 AS exchange 互操作的重要部分. 客户端依赖错误码决定是否重试、是否执行预认证、是否提示用户或是否终止认证流程. 因此, KDC 不应使用过于笼统的错误码掩盖可恢复条件.

3.1.5. Receipt of KRB_AS_REP Message (接收 KRB_AS_REP 消息)

如果回复消息类型是 KRB_AS_REP, 则客户端验证回复的明文部分中的 cname 和 crealm 字段是否与它请求的内容匹配.如果存在任何 padata 字段, 它们可用于派生适当的密钥来解密消息.客户端使用其密钥解密响应的加密部分, 并验证加密部分中的随机数是否与它在请求中提供的随机数匹配 (以检测重放).它还验证响应中的 sname 和 srealm 是否与请求中的那些匹配 (或者是否是其他预期的值), 并且主机地址字段也是正确的.然后它存储票据、会话密钥、开始和过期时间以及其他信息以供以后使用.可以 (MAY) 检查响应的加密部分中的 last-req 字段 (和已弃用的 key-expiration 字段) 以通知用户即将发生的密钥过期.这使客户端程序能够建议补救措施, 例如密码更改.

在验证 KRB_AS_REP 消息时 (通过将返回的随机数与在 KRB_AS_REQ 消息中发送的随机数进行比较), 客户端知道 KDC 上的当前时间是从回复的加密部分的 authtime 字段中读取的时间.客户端可以选择使用此值进行后续消息中的时钟同步, 方法是记录票据的 authtime 值与本地时钟之间的差异 (偏移).然后同一用户可以使用此偏移来在生成消息时调整从系统时钟读取的时间 [DGT96].

在调整时钟偏移时必须 (MUST) 使用此技术, 而不是直接更改系统时钟, 因为 KDC 回复仅对其密钥用于的用户进行认证, 但不对系统或工作站进行认证.如果调整时钟, 攻击者与登录到工作站的用户串通可以就密码达成一致, 导致 KDC 回复将被正确验证, 即使它不是来自工作站信任的 KDC.

KRB_AS_REP 消息的正确解密不足以让主机验证用户的身份; 用户和攻击者可以合作生成正确解密但不是来自适当 KDC 的 KRB_AS_REP 格式消息.如果主机希望验证用户的身份, 它必须 (MUST) 要求用户呈现可以使用主机的安全存储的密钥验证的应用程序凭证.如果可以验证这些凭证, 则可以确保用户的身份.

3.1.6. Receipt of KRB_ERROR Message (接收 KRB_ERROR 消息)

如果回复消息类型是 KRB_ERROR, 则客户端将其解释为错误并执行恢复所需的任何特定于应用程序的任务.

接收 KRB_ERROR 后, 客户端需要根据错误码判断是否可以重新发送请求、补充预认证数据、校正时间偏差或向用户报告失败. 错误消息本身仍是 Kerberos 协议消息, 因此应按第 5.9 节的结构完整解析和验证.