摘要：基于Windows的RDP(Remote Desktop Protocol)协议，以Kerberos协议为核心，实现了RDP客户端的网络安全认证。Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。系统采用Kerberos V5协议，基于Windows RDP的特性，扩展实现了Kerberos V5协议在RDP客户端的应用。Kerberos 作为一种可信任的第三方NLA(Network Level Authentication, 网络级身份验证)协议有较高的应用价值。本文实现的系统可用于Windows Server 2008, Windows Vista与Windows 7等RDP客户端Kerberos安全认证。

关键词： Kerberos，NLA，RDP，GSS

Implement of Client Kerberos Authentication Based on Windows RDP Author: Mike Lee

Abstract: Based on Windows RDP (Remote Desktop Protocol), to Kerberos protocol as the core, implement of client network security authentication. Kerberos is a kind of network authentication protocol, and its design goal is through the public-key systems for client/server applications provide strong authentication services. This system adopts Kerberos V5 protocol, based on the characteristics RDP Windows, and expand Kerberos implement in V5 protocol. Kerberos as a trusted third-party NLA (Network, the Network Level to also disables Authentication via an identity verification) protocol has higher application value. This system can be used in the Windows Server 2008, Windows Vista and Windows 7 and so on RDP client Kerberos authentication.

Keywords: Kerberos，NLA，RDP，GSS

引 言

NLA是一种身份验证方法，它要求用户在创建会话前必须通过RDP会话主机服务器的身份验证。NLA在建立远程桌面连接并出现登录屏幕之前完成用户身份验证。这是比较安全的身份验证方法，有助于保护远程计算机避免恶意用户和恶意软件的***。网络级身份验证的好处是[1]：

1.              起初需要较少的远程计算机资源。验证用户身份之前，远程计算机使用有限的资源，而不是像以前版本那样启动完整的远程桌面连接。

2.              可以通过降低受到拒绝服务***的风险，帮助提高安全性。

Kerberos协议是由麻省理工研发用来保护Project Athena提供的网络服务器。这个协议以希腊神话中的人物Kerberos（或者Cerberus）命名，它在希腊神话中是地狱的一条凶猛的三头保卫神犬，Kerberos的官方网站是：http://web.mit.edu/Kerberos；Kerberos作为实现NLA的一种可选择协议，已经广泛应用到各种主流操作系统，如Windows, Unix, Linux，Mac OS等，作为一种安全的网络认证协议数年前已经被成功应用到微软的Windows操作系统中。

1  Kerberos原理

认证（Authentication）解决的是“如何证明某个人确确实实就是他或她所声称的那个人”的问题。对于如何进行认证，可以采用这样的方法：如果一个密钥仅仅存在于A和B，那么有个人对B声称自己就是A，B通过让A提供这个密钥来证明这个人就是他或她所声称的A。Kerberos也是基于这个认证原理来实现双方的认证，它使用了两个独立的逻辑部分：认证服务器和票据授权服务器组成的"可信赖的第三方"，称为密钥分发中心（KDC）。Kerberos工作在用于证明用户身份的"票据"的基础上。KDC持有一个密钥数据库；每个网络实体-无论是客户还是服务器-共享了一套只有他自己和KDC知道的密钥。密钥的内容用于证明实体的身份。对于两个实体间的通信，KDC产生一个会议密钥，用来加密他们之间的交互信息[2]。Kerberos工作原理如下图１所示。


图１　Kerberos协议工作原理

 

Kerberos协议的安全主要依赖于参加者对时间的松散同步和短周期的叫做Kerberos票据的认证声明。 下面是对这个协议的一个简化描述，将使用以下缩写：

•   AS（Authentication Server）= 认证服务器

•   TGS（Ticket Granting Server）= 票据授权服务器。

•   SS（SS）= 服务器。

•   TGT（TGT）= 票据授权票据。

简单地说，客户向AS认证时用了一个长期共享密钥，并从AS得到一个票据。随后客户可以使用这个票据得到与SS通信必须的附加的票据，而不需要转而使用共享密钥。这些票据可以向SS证明身份。


图２　Kerberos消息基本流程

    Kerberos消息的基本流程解释如下：

1．  Client向KDC申请TGT（Ticket Granting Ticket）：由KRB_AS_REQ与KRB_AS_REP消息实现。

2．  Client通过获得TGT向KDC申请用于访问Server的Ticket：由KRB_TGS_REQ与KRB_TGS_REP消息实现。

3．  Client最终为了Server对自己的认证向其提交Ticket：由KRB_AP_REQ和KRB_AP_REP消息实现。

2        软件设计与实现

由于该系统基于Kerberos V5实现，但并非完全是Kerberos V5协议的实现，是对该协议的一种扩展实现。该软件总体数据流程图如图3所示，由三部分通信实现：客户端（Client），KDC与服务器（Server）。


图3 基于Windows Server的Kerberos认证实现流程

3.1   Client与KDC消息交互

以Kerberos V5协议来看，Client与KDC主要实现KRB_AS_REQ、KRB_AS_REP、KRB_TGS_REQ与KRB_TGS_REP四条消息，由于该系统是对Kerberos V5协议的扩展，所以其实现与标准会有所区别。根据图3，笔者来分析Client与KDC消息交互的设计与实现。

1.KRB_AS_REQ：消息发送的主要内容有消息类型、用户的基本信息和时间戳等，数据结构定义如下（参考RFC4120 5.4.1）：

typedef struct KDC_REQ_t {

  int pvno;   //协议的版本号V5，即该值等于5

  int msg_type;   //消息类型为KRB_AS_REQ

  struct PA_DATA_t** padata;  //预认证数据，根据消息类型不同传输不同的内容

  KDC_REQ_BODY *req_body;     //扩展的消息结构

} __PACKED__ KDC_REQ;

其中struct PA_DATA_t结构定义如下：

typedef struct PA_DATA_t {

    int32_t type; //预认证数据类型

ubyte *value;  //预认证数据内容

} __PACKED__ PA_DATA;

其中KDC_REQ_BODY类型定义如下：

typedef struct KDC_REQ_BODY_t {

    ubyte4 kdc_options;     //设定控制KDC的一些flag标记

    PrincipalName cname;       //客户端的用户名         

    char realm[KRB_MAX_NAME_LEN];  //要登陆的域名            

    PrincipalName sname;            //要访问的Server名      

    char*  from;               //期望获得票据的开始时间，如果未设定，默认为当前时间

    char* till;              //期望票据的过期时间    

    char* rtime;       //期望更新获得票据的过期时间         

    ubyte4 nonce;       //随机数用于验证消息           

    int* etype;         //可支持的加密类型，比如该系统支持RC4加解密算法       

    HostAddress addresses;   //客户主机的主机名信息（可选）            

    EncryptedData enc_authorization_data;

    Ticket adt;     //附加的票据，根据kdc_options 中的ENC-TKT-IN-SKEY标记确定是否存在 

} __PACKED__ KDC_REQ_BODY;

2．KRB_ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED (25),KDC返回该消息表明需要附加的认证信息（PA-ENC-TIMESTAMP类型）。关于KRB_ERROR类型的消息，该系统中其数据结构定义（参考RFC4120 5.9.1）如下：

typedef struct krb_error_t {

  int pvno;  //同上

  int msg_type; //同上

  ubyte ctime[KRB_STAMP_LEN];   //当前的时间ASN.1中的GeneralTime格式

  ubyte2  cusec;     //当前时间的微秒数

  ubyte stime[KRB_STAMP_LEN]; //Server端的当前时间

  unsigned int susec;   //Server端当前时间的微秒数

  int code;           //错误代码号，参考RFC4120 7.5.9

  char crealm[KRB_MAX_NAME_LEN];

  PrincipalName cname;

  char realm[KRB_MAX_NAME_LEN];

  PrincipalName sname;

  char *e_text; //附加的消息帮助解释错误原因，可选的

  e_data edata; //帮助恢复或处理错误的数据

} krb_error_msg;

3．KRB_AS_REQ：消息格式与1相同，主要区别是该消息中增加了PA-ENC-TIMESTAMP (2)消息，该消息的数据结构定义（参考RFC4120 5.2.7.2）如下：

typedef struct PA_ENC_TS_ENC_t {

ubyte    patimestamp[15];  //客户端当前的时间，格式为：32303130303630343037343831365a //代表2010-06-04 07:48:16 (UTC)

    int       pausec;       //客户端当前时间的微秒数

} __PACKED__ PA_ENC_TS_ENC;

4．KRB_AS_REP：该消息为KDC正常返回给Client的消息，消息包含票务Ticket消息和加密的信息。该消息的数据结构定义（参考RFC4120 5.4.2）如下：

typedef struct KDC_REP_t {

  int pvno;

  int msg_type;

  struct PA_DATA_t* padata;

  char  crealm[KRB_MAX_NAME_LEN]; 

  PrincipalName cname;     

  Ticket ticket;  //需要转发的Ticket消息

  EncryptedData enc_part; //加密的信息，数据格式为EncKDCRepPart

} __PACKED__ KDC_REP;

关于Ticket的定义参考RFC4120 5.3，用于传递交互的票据信息。关于EncKDCRepPart的定义参考RFC4120 5.4.2，该信息包含双方协商使用的Session Key和一些认证信息。

5．KRB_TGS_REQ: 该消息用来申请用于访问Server的Ticket，消息格式与KRB_AS_REQ相同。

6．KRB_TGS_REP:该消息返回响应KRB_TGS_REQ请求信息，消息格式与KRB_AS_REP相同。

9．KRB_TGS_REQ: 该消息用来申请用于访问Server的Ticket，消息格式与KRB_AS_REQ相同。

10．KRB_TGS_REP:该消息返回响应KRB_TGS_REQ请求信息，消息格式与KRB_AS_REP相同。

3.2   Client与Server消息交互

Client与Server之间的交互主要完成两件事情：一、协商Token用于后续的交互认证，由消息７（NegTokenInit）与8（NegTokenResp）消息实现；二、Client与Server的互相认证，由11（KRB_AP_REQ），12(KRB_AP_REP)和13(NegTokenResp)实现。

７．NegTokenInit：用于发送请求协商Token的OID列表，每一个OID代表一种可支持的GSS-API（Generic Security Service Application Program Interface）机制。NegTokenInit结构定义参考RFC4178 4.2.1，定义内容如下：

typedef struct NegTokenInit_t {

          ubyte *mechTypes        //OID列表

          ubyte4 reqFlags        //ContextFlags  OPTIONAL, 该系统未使用

          ubyte *mechToken       //协商的Token内容

          ubyte * mechListMIC    //如果协商不支持完整性保护，该项就不使用

} __PACKED__ NegTokenInit；

8．NegTokenResp：响应NegTokenInit的请求，返回所支持的OID，以及相应的Token内容，该结构的定义参考RFC4178 4.2.1 4.2.2，定义如下：

typedef struct NegTokenResp _t {

      enum negState {COMPLETED, INCOMPLETE, REJECT , REQUEST-MIC }; //协商的状态

      ubyte * supportedMech; //支持的机制OID

      ubyte *responseToken;  //协商的Token内容

      ubyte * mechListMIC;  // MIC token计算根据RFC4178 第5小节。

} __PACKED__ NegTokenResp;

11．KRB_AP_REQ：该消息主要用于完成Client对Server的认证，即让Server明白该Client是合法的，是可信的。该消息的定义参考RFC4120 5.5.1节，定义如下：

struct AP_REQ_t {

       int pvno;

       int msg_type;

       ubyte ap_options[5];  //请求的标记

       Ticket ticket;   //转发的Ticket

       Authenticator auth;  //加密的认证信息，包含客户可选的subkey，定义参考RFC4120 5.5.1

} __PACKED__ AP_REQ;

12．KRB_AP_REP：这个消息是根据KRB_AP_REQ消息中的ap_options（mutual-required标记）选项来产生的，用于证明自己就是Client要访问的Server。主要返回一个双方协商的subkey为后续的具体应用程序加解密使用。

13．NegTokenResp：与消息8格式相同，不同的是这里的negState的状态为COMPLETED，表示协商已完成。并且包含已计算好的mechListMIC值。

至此，关于Kerberos在RDP协议中的认证过程已经完成，为后续安全传递数据铺平了道路。

结 语

随着网络的飞速发展，网络安全认证日趋重要，Kerberos作为一种强大的网络认证协议已被广泛应用。本文讨论的是Kerberos基于Windows系统RDP协议中的一个典型网络认证应用，通过本文读者可以学习Kerberos协议的工作原理，以及它在实际工作中的具体应用实现。 

参考文献

1.     微软技术资源库：Windows Server 2008 R2.

2.     RFC4120: The Kerberos Network Authentication Service (V5)

3.     [RFC4178]The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanis

4.     [RFC4757] Jaganathan, K., Zhu, L., and Brezak, J., "The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows"

5.     [MS-KILE]: Kerberos Protocol Extensions

6.     Rfc4178: The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism

7.     [Kerberos principle]: Designing an Authentication System:a Dialogue in Four Scenes

8.     Rfc1964: The Kerberos Version 5 GSS-API Mechanism