摘要：基於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