Xác thực trong hệ phân tán Kerberos

Xác thực trong hệ phân tán Kerberos Chương I : Giao thức Kerberos : Chương này trình bày những tìm hiểu của em về giao thức Kerberos, cách thức vận hành của Kerberos, các loại khóa, thẻ, phân vùng của Kerberos. Đồng thời trong chương này cũng phân tích một số cải tiến và đánh giá về giao thức Kerberos hiện nay. Chương II : Xây dựng ứng dụng Kerberos : Trình bày phần thiết kế chương trình thử nghiệm sử dụng Kerberos để phục vụ mục đích SSO trên nền Windows 2003 Server . Trong chương này sẽ phân tích chương trình thử nghiệm dựa trên Kerberos áp dụng cho cơ chế domain logon và việc áp dụng cơ chế đó vào SSO. Chương trình thử nghiệm có 2 thành phần cơ bản là DemoKerberosSSO và TestGateway. Trong chương này cũng sẽ trình bày các biểu đồ thiết kế chương trình thử nghiệm và kết quả đạt được. Chương III : Kết Luận : Tổng kết công việc đã làm và những kinh nghiệm thu được trong quá trình thực hiện đồ án.

LỜI NÓI ĐẦU 2

CHƯƠNG I

GIAO THỨC KERBEROS 4

1 Nội dung giao thức 4

a Pha thứ nhất 5

b Pha thứ hai 7

c Pha thứ ba 9

2 Các thẻ Kerberos 10

2.1 Các yêu cầu thẻ Kerberos 10

2.2 Các thẻ dùng để trao thẻ 11

2.3 Các thẻ dịch vụ 11

2.4 Nội dung của một thẻ Kerberos 12

2.5 Các TGT có thể gia hạn 16

3 Authenticator 16

3.1 Vai trò của authenticator 16

3.2 Hoạt động của authenticator 16

3.3 Nhãn thời gian của authenticator 17

3.4 Cấu trúc của authenticator 17

4 Vùng (realm) và chứng thực liên vùng 17

5 Những cải tiến chính trong Kerberos phiên bản 5 19

6 Đánh giá giao thức Kerberos 20

6.1.Tăng cường bảo mật 20

6.2.Cung cấp cơ chế chứng thực mạnh 21

CHƯƠNG II

ỨNG DỤNG KERBEROS 24

1 Xác thực trong Windows : 25

1.1 SSP và SSPI 25

1.2 Kerberos Authentication 26

2 Windows Logon 27

2.1 Local Logon 27

2.2 Domain Logon 28

3 Xây dựng chương trình Demo Kerberos trong SSO 32

3.1 Chương trình Demo-Kerberos-SSO tại Client 33

3.2 Chương trình TestGateway 35

3.3 Thực hiện chương trình Demo-Kerberos-SSO: 37

4 Ưu nhược điểm của Kerberos 39

KẾT LUẬN 40

LỜI NÓI ĐẦU

Ngày nay vấn đề xác thực trong các hệ phân tán là một yếu tố vô cùng quan trọng bởi vì các hệ phân tán không thể làm việc đơn lẻ mà phải tương tác với nhau

Trong quá trình tương tác đó các hệ phân tán phải có những quá trình xác thực để đảm bảo những yêu cầu về bảo mật cũng như gia tăng quyền hạn cho các thành viên, đặc biệt để chống lại những nguy cơ bảo mật ngày càng gia tăng hiện nay

Với những lý do như vậy em đã chọn đồ án : Xác thực trong hệ phân tán,

Kerberos để nghiên cứu về giao thức xác thực này và tìm hiểu triển khai những mô

hình phân tán dựa trên Kerberos để phục vụ cho các ứng dụng trên môi trường mạng

Với ý tưởng như vậy em đã đặt ra mục tiêu công việc như sau :

 Tìm hiểu về giao thức Kerberos.

 Tìm hiểu việc ứng dụng Kerberos trong thực tế.

 Thiết kế chương trình sử dụng giao thức Kerberos phục vụ SSO.

Như vậy đồ án Xác thực trong hệ phân tán, Kerberos của em sẽ bao gồm những

phần sau :

Chương I : Giao thức Kerberos : Chương này trình bày những tìm hiểu của em

về giao thức Kerberos, cách thức vận hành của Kerberos, các loại khóa, thẻ, phân vùng của Kerberos

Đồng thời trong chương này cũng phân tích một số cải tiến và đánh giá về giao thứcKerberos hiện nay

Chương II : Xây dựng ứng dụng Kerberos : Trình bày phần thiết kế chương trình

thử nghiệm sử dụng Kerberos để phục vụ mục đích SSO trên nền Windows 2003

Chương III : Kết Luận : Tổng kết công việc đã làm và những kinh nghiệm thu

được trong quá trình thực hiện đồ án

Qua đây em cũng xin gửi lời cám ơn TS Nguyễn Linh Giang đã giúp đỡ em rất nhiều trong quá trình thực hiện đồ án này !

CHƯƠNG I GIAO THỨC KERBEROS

Kerberos là một giao thức chứng thực mạng được phát triển trong dự án Athenacủa học viện công nghệ Massachusetts (MIT) Kerberos là một cơ chế chứng thựcmạnh cho các ứng dụng client/server trên môi trường mạng phân tán; nó cho phépcác thực thể truyền thông trong mạng chứng thực lẫn nhau mà vẫn đảm bảo an toàn,chống nghe lén hay tấn công reply attack trên mạng Nó cũng đảm bảo tính toàn vẹn

và tính mật cho thông tin truyền đi, sử dụng mã hoá bí mật như DES, triple DES.Trong thông báo đầu tiên của Kerberos đã liệt kê các yêu cầu trong Kerberos đólà:

- An toàn : Một kẻ nghe trộm trên mạng không thể bắt được các thông tin

cần thiết để giả mạo một người dùng Hay nói chung là Kerberos phải đủmạnh để kẻ địch không thể liệt nó vào kênh có thể xâm nhập

- Đáng tin cậy: Tất cả các dịch vụ trong mạng đều sử dụng Kerberos để

kiểm soát truy nhập, nếu thiếu dịch vụ Kerberos có nghĩa là nó chưa đượcbảo đảm Vì thế, Kerberos phải đáng tin cậy và phải sử dụng kiến trúcmáy chủ phân tán mà một hệ thống này có thể chuyển trở lại một hệthống khác

- Trong suốt: Một cách lý tưởng, người dùng không thể phát hiện ra sự

chứng thực, ngoại trừ yêu cầu nhập mật khẩu

- Co giãn được: Hệ thống phải có khả năng hỗ trợ một số lượng lớn máy

chủ và máy khách

1 Nội dung giao thức

Kerberos không xây dựng các giao thức chứng thực phức tạp cho mỗi máy chủ

mà hoạt động dựa trên một máy chủ chứng thực tập trung KDC (Key DistributionCentre), sử dụng giao thức phân phối khoá được đề xuất bởi Needham vàSchroeder KDC cung cấp vé để chứng minh định danh người dùng và bảo mậttruyền thông giữa hai bên bởi khoá phiên trong vé Một chiếc vé có thể là một chuỗidài khoảng vài trăm byte và có thể được nhúng vào bất kỳ trong một giao thứcmạng nào, điều này đảm bảo độc lập với giao thức giao vận của mạng

Trung tâm phân phối khoá KDC (Key Distribution Centre) gồm máy chủ chứngthực AS (Authentication Server) biết mật khẩu của tất cả người dùng được lưu giữtrên một cơ sở dữ liệu tập trung, máy chủ cấp khoá TGS (Ticket Granting Server)cung cấp vé dịch vụ cho người dùng truy nhập vào các máy chủ trên mạng

Giao thức Kerberos được thực hiện qua ba giai đoạn, hay ba pha Trong kịchbản này, người dùng C đăng nhập vào máy trạm và yêu cầu truy nhập tới máy chủ

là S

Mô hình tổng quát của giao thức Kerberos :

Trong phần tiếp theo ta sẽ tìm hiểu kỹ hơn về 3 pha trong kịch bản củaKerberos :

a Pha thứ nhất : Kết nối với AS để lấy về TGT ( 1,2)

Truyền thông với Authentication Server

Truyền thông với AS thường là giai đoạn khởi đầu của phiên đăng nhập, nhằmlấy về có dữ liệu chứng thực (TGT) cho TGS, để sau đó lấy về chứng thực cho cácmáy chủ khác mà không phải nhập lại khoá bí mật của client Khoá bí mật củaclient được sử dụng cho cả việc mã hoá và giải mã

Truyền thông với AS cũng được sử dụng để lấy dữ liệu chứng thực cho cácmáy chủ khác không do TGS quản lý như dịch vụ đổi mật khẩu

1 Người dùng đăng nhập vào hệ thống, nhập định danh và mật khẩu Client sẽ

chuyển đổi mật khẩu thành khoá mã hoá bí mật, lưu trữ trong biến của chương

trình Cient sẽ gửi yêu cầu TGT tới AS bằng thông điệp Kerberos Authentication

Service Request (KRB_AS_REQ) gồm 3 phần sau dưới dạng Plain Text :

- Service Name : Ở đây Service Name sẽ là TGS

- Định danh người dùng : Client's Name

- Địa chỉ người dùng : Client's IP-Addr

Client gửi KRB_AS_REQ tới AS

2 AS nhận được KRB_AS_REQ từ client C, AS sẽ truy lục trong cơ sở dữ liệu,

lấy khoá bí mật của C dưới dạng hash, sau đó sẽ gửi lại cho Client thông tin TGTđược mã hóa với khóa riêng của TGS đồng thời AS cũng tạo một Session-Key giữa

C và TGS được dùng để mã hóa dữ liệu cho những lần trao đổi tiếp theo giữa Client

và TGS Toàn bộ 2 thành phần trên sẽ được mã hóa bằng khóa của Client ( mậtkhẩu của Client dưới dạng hash )

Thông tin bên trong TGT sẽ bao gồm những thành phần sau :

- Service Name : TGT

- Định danh Client : Client's Name và Client's IP Addr

- Time-stamp : ghi lại thời gian gửi tin

- Ticket Lifetime : thời gian sống của TGT

- Session Key giữa C và TGS giống như bên trên

Toàn bộ phần TGT này sẽ được mã hóa với khóa là khóa riêng của TGS, nghĩa

là khi Client nhận được gói tin trả lời và giải mã thông tin thì Client cũng sẽ khôngthể thay đổi và đọc các thông tin bên trong TGT

2 thành phần TGT và Session-Key(C,TGS) sẽ được ghép với nhau và mã hóabằng khóa riêng của Client ( mã hash của Client ) điều này giúp cho việc xác thựcClient, bởi vì chỉ có mật khẩu của Client thì mới có thể giải mã thông tin này Lưu ý

là trong toàn bộ quá trình thì mật khẩu của Client không bao giờ được gửi giữa 2bên

AS gửi KRB_AS_REQ cho Client

3 Client sau khi nhận được KRB_AS_REQ sẽ giải mã gói tin này bằng khóa

riêng của mình và thu được TGT và Session-Key(C-TGS) ( khóa phiên C-TGS ).TGT sẽ được sử dụng khi Client có yêu cầu sử dụng một dịch vụ nào đó

Session-Key(C,TGS) sẽ được sử dụng để mã hóa những thông tin sau này giữaClient và TGS

Như vậy tại bước này thì Client đã có được TGT như là một chứng chỉ xác thựcsau này Client có thể đưa cho TGS để chứng mình quyền hạn của mình

b Pha thứ hai : Truyền thông với máy chủ cấp vé dịch vụ TGS, lấy về service

ticket ( 3,4)

Truyền thông với Ticket-granting server

1 Có vé TGT và khóa phiên trong tay, C đã sẵn sàng để truy nhập vào TGS.

Đầu tiên C gửi cho TGS một thông điệp KRB_TGS_REQ có chứa :

- Vé TGT và Định danh dịch vụ yêu cầu

- Authenticator được mã hoá bằng khoá phiên gồm định danh, địa chỉ người dùng C và tem thời gian Authenticator chỉ sử dụng một lần và có

hiệu lực trong một thời gian cực ngắn

Client gửi yêu cầu KRB_TGS_RQ tới TGS.

2 TGS giải mã TGT bằng khóa mật của TGS, lấy ra khoá phiên dùng chung

với C ( Session-Key(C,TGS) )

Khoá phiên này được dùng để giải mã Authenticator, kiểm tra tính hợp lệ Nếu

đúng, TGS được đảm bảo chắc chắn rằng người gửi chiếc vé chính là chủ nhânthực sự của nó Khi đó, TGS sẽ sinh ra khoá phiên mới chung cho Client và ServerDịch vụ V Và gửi thông điệp KRB_TGS_REP về cho Client bao gồm :

- Một bản sao khoá phiên giữa Client và Server S

- Service Ticket được mã hóa bởi khóa riêng của Server S bao gồm nhữngthành phần sau :

+ Service Name

+ Client's Name và Client's IP Address

+ TimeStamp và Ticket Lifetime

Session-TGS gửi KRB_Session-TGS_REP cho Client

c Pha thứ ba : Truyền thông trong chứng thực client/server ( 5,6 )

Đăng nhập vào máy chủ cung cấp dịch vụ

1 Bây giờ thì, Client sẵn sàng chứng thực với máy chủ S Client gửi cho Server

một thông điệp KRB_AP_REQ có chứa :

- Authenticator mã hoá bởi khoá phiên dùng chung C, S

- Service ticket mã hoá bởi khoá mật của S.

- Service Name

2 Server giải mã service ticket, lấy ra dữ liệu phân quyền của C và khoá phiên.

Server dùng khoá phiên nhận được giải mã authenticator, xác minh tem thời gian Nếu hợp lệ Server sử dụng khoá phiên mã hoá thời gian từ authenticator và gửi về

cho Client bằng thông điệp KRB_AP_REP

3 Client giải mã thông điệp bằng khoá phiên dùng chung với Server, xác minh

thời gian trong đó có đúng như khi gửi cho V không Nếu hợp lệ, kết nối truyềnthông sẽ được thực hiện

2 Các thẻ Kerberos

Thành phần chính của xác thực Kerberos là thẻ Các thông điệp Kerberos được

sử dụng để yêu cầu và phân phối các thẻ Có hai loại thẻ được sử dụng trong xácthực Kerberos, là TGT và thẻ dịch vụ

2.1 Các yêu cầu thẻ Kerberos

Kerberos client gửi các yêu cầu thẻ đến KDC:

Các yêu cầu thẻ gồm có:

- Các thuộc tính được yêu cầu, ví như xác định thẻ này có được gia hạnkhông

- Phương thức mã mật được yêu cầu

Kiều thẻ được yêu cầu Dịch vụ KDC nhận yêu

cầu

Bảng 4 Các kiểu thẻ được yêu cầu

2.2 Các thẻ dùng để trao thẻ

KDC đáp ứng yêu cầu dịch vụ xác thực của một client bằng cách trả về một thẻdịch vụ cho chính nó Thẻ dịch vụ đặc biệt này được gọi là thẻ dùng để trao thẻ(TGT) TGT cho phép dịch vụ xác thực truyền tải một cách an toàn các giấy tin cậy(credential) của người yêu cầu đến dịch vụ trao thẻ (ticket-granting service - TGS).Một TGT là:

- Thẻ đầu tiên của người dùng từ dịch vụ xác thực

- Được sử dụng để yêu cầu các thẻ dịch vụ

- Chỉ có ý nghĩa khi được sử dụng bởi dịch vụ trao thẻ

Các TGT được mã hoá với một khoá được chia sẻ bởi các KDC Client khôngthể đọc được các thẻ đó Chỉ có các KDC server mới có thể đọc được các TGT đểđảm bảo an toàn truy cập đến các giấy tin cậy của người dùng, các khoá phiên, vàcác thông tin khác Giống như một thẻ dịch vụ bình thường, một TGT chứa một bảnsao của khoá phiên mà dịch vụ (trong trường hợp này là KDC) sẽ sử dụng trong khitruyền thông với client TGT này được mã mật với khoá long-term của KDC

Từ quan điểm của client, một TGT chỉ là một thẻ khác nữa Trước khi nó cốgắng kết nối tới một dịch vụ nào đó, client này trước tiên kiểm tra bộ đệm các giấytin cậy (credentials cache) của nó về thẻ dịch vụ dành cho dịch vụ đó Nếu thẻ nàykhông tồn tại, nó kiểm tra một lần nữa bộ đệm xem có TGT hay không.Nếu nó tìmthấy thẻ TGT, thì client lấy được khoá phiên TGS tương ứng từ bộ đệm, sử dụngkhoá này để tạo ra một authenticator, và gửi cả authenticator này và TGT đến KDC,cùng với yêu cầu xin một thẻ dịch vụ cho dịch vụ tương ứng Nói cách khác, việcđạt được sự chấp nhận của KDC hoàn toàn giống với việc đạt được sự chấp nhậncủa bất kỳ dịch vụ khác trong cùng một miền – nó đều yêu cầu một khoá phiên, mộtauthenticator, và một thẻ dịch vụ

Từ quan điểm của KDC, các TGT cho phép nó tránh được các sự bất lợi vềhiệu năng khi phải tìm kiếm một khoá long-term của người dùng mỗi khi ngườidùng này yêu cầu một dịch vụ Thay vào đó, KDC chỉ tìm kiếm khoá trên chỉ mộtlần, khi nó trao cho client dùng TGT lần đầu tiên Đối với các trao đổi các với clientnày, KDC có thể giải mã TGT bằng khoá long-term của chính nó, lấy ra được khoáphiên tương ứng, và sử dụng nó để kiểm tra tính hợp lệ của authenticator của clientnày

thẻ dịch vụ Toàn bộ cấu trúc này sau đó được mã mật bằng khoá mà KDC chia sẻvới dịch vụ Thẻ này - với bản sao khoá phiên của dịch vụ trong đó - sẽ được quản

lý bởi client cho đến khi client này liên lạc được với dịch vụ

Thẻ dịch vụ được sử dụng để xác thực với các dịch vụ khác với TGS và chỉ có

ý nghĩa đối với dịch vụ đích đó

Thẻ dịch vụ được mã mật với khoá dịch vụ Đó là một khoá long-term đượcdùng chung bởi KDC và dịch vụ đích Do đó, mặc dù client quản lý thẻ dịch vụ,nhưng client lại không thể đọc nó Chỉ có KDC và dịch vụ đích là có thể đọc đượccác thẻ này, qua đó đảm bảo việc truy cập an toàn đến giấy tin cậy người dùng,khoá phiên, và các thông tin khác

Khi client nhận được trả lời của KDC, nó lấy ra thẻ dịch vụ và bản sao khoáphiên của nó, đặt các thông tin này vào trong một bộ đệm an toàn (được định vịtrong bộ nhớ tạm thời, không phải ở trên đĩa) Khi client này muốn có được sự chấpnhận của server, nó gửi cho server này một thông điệp trong đó bao gồm thẻ dịch

vụ, được mã mật bằng khoá mật của server, và một authenticator, được mã mậtbằng khoá phiên Thẻ dịch vụ và authenticator này chính là giấy tin cậy của clientđối với server

Client không cần phải quay trở lại KDC mỗi lần nó muốn truy cập đến serverbởi vì các thẻ dịch vụ có thể được sử dụng lại Để bảo vệ chống lại khả năng ngườinào đó có thể ăn cắp một bản sao của thẻ dịch vụ, các thẻ dịch vụ có một thời gianhết hạn được chỉ rõ bởi KDC trong cấu trúc dữ liệu của thẻ dịch vụ Thời gian tồntại của thẻ dịch vụ phụ thuộc vào chính sách của từng miền Đối với Kerberos trongWindows Server khoảng thời gian mặc định là 10 giờ Khi người dùng log off, bộđệm giấy tin cậy được xoá đi và tất cả các thẻ dịch vụ cũng như là các khoá phiênđều bị phá huỷ

2.4 Nội dung của một thẻ Kerberos

Phần này liệt kê các trường trong một thẻ Kerberos và mô tả các thông tin màchúng chứa trong đó

Cấu trúc của một thẻ Kerberos

Ba trường đầu tiên trong một thẻ không được mã mật Thông tin này ở dạngvăn bản rõ để client có thể sử dụng nó để quản lý các thẻ trong bộ đệm của nó

Tên trường Mô tả

Ticket Version

Realm

Tên của một vùng đã phát ra thẻ đó KDC có thể phát ra các thẻchỉ cho các server trong miền của nó, do đó trường này cũng làtên của vùng của server

Server Name Tên của server

Các trường dưới đây được mã mật bằng khoá mật của server:Flags Các tuỳ chọn chỉ ra bằng cách nào và khi nào thẻ có thể được sửdụng.Key Khoá phiên được sử dụng để mã hoá và giải mã các thông điệp

của client và server đích

Client Realm Tên của vùng của người yêu cầu

Client Name Tên của người yêu cầu

Transited Liệt kê các vùng Kerberos có tham gia vào việc xác thực củaclient trong xác thực liên vùng.

cũ, nó yêu cầu client phải lấy về một TGT mới và sau đó là thẻdịch vụ mới

Start Time Thời gian mà sau đó thì thẻ là hợp lệ

End Time Thời gian hết hạn của thẻ

Renew Till (Tuỳ chọn) Thời gian kết thúc cuối cùng mà có thể được thiết lậptrong một thẻ thông qua cờ thẻ RENEWABLE.Client Address

(Tuỳ chọn) Một hoặc một vài địa chỉ mà thẻ được sử dụng ở đó.Nếu trường này bỏ trống, thì thẻ có thể được sử dụng từ bất kỳđịa chỉ nào

Authorization-Data

(Tuỳ chọn) Trường này chứa dữ liệu quyền hạn (authorization)của client Đối với việc thực hiện Kerberos của Microsoft trườngnày rất quan trong bởi vì nó chứa định danh an toàn (SID) củangười dùng và các định danh an toàn của các nhóm mà client làthành viên Dữ liệu này được sử dụng để xây dựng thẻ truy cập(access token) của client (các thuộc tính đặc quyền của client).Dịch vụ Kerberos không làm sáng tỏ nội dung của trường này,

mà việc này được dành cho dịch vụ có yêu cầu giấy tin cậy

Các nội dung thẻ

Các cờ của thẻ

Bảng dưới đây liệt kê và mô tả trường Flag của thẻ Kerberos Trường Flag làmột trường bit trong đó các tuỳ chọn được thiết lập bằng cách bật (1) tắt (0) các bit

cụ thể Mặc dù trường này có độ dài là 32 bit, nhưng chỉ 11 cờ là đáng cho các nhàquản trị Kerberos quan tâm

FORWARDABLE (Chỉ dành cho TGT) Thông báo với dịch vu trao thẻ rằng nócó thể phát ra một TGT mới - dựa trên TGT hiện có - với một

địa chỉ mạng khác dựa trên TGT hiện có

FORWARDED Biểu thị rằng hoặc một TGT đã được chuyển tiếp hoặc mộtthẻ đã được phát ra từ TGT đã chuyển tiếp.PROXIABLE

(Chỉ dành cho TGT) Thông báo với dịch vụ trao thẻ rằng nó

có thể phát ra các thẻ với một địa chỉ mạng khác với địa chỉmạng ở trong TGT

PROXY Biểu thị rằng địa chỉ mạng trong thẻ là khác với địa chỉ mạngtrong TGT được sử dụng để lấy được thẻ đó.MAY-POSTDATE

(Chỉ dành cho TGT) Thông báo với dịch vụ trao thẻ rằng thẻđược ghi thời gian sử dụng muộn hơn (postdated) có thể đượcphát ra

POSTDATED Biểu thị rằng thẻ này đã được ghi thời gian sử dụng muộnhơn.INVALID

Biểu thị rằng thẻ này là không hợp lệ và phải được xác nhậntính hợp lệ bởi KDC trước khi sử dụng Một thẻ postdatedđược đánh dấu là không hợp lệ cho đến thời gian hợp lệ bắtđầu của nó

RENEWABLE

Được sử dụng kết hợp với các trường End Time và RenewTill để cho phép thời gian tồn tại của các thẻ được gia hạn tạiKDC một cách định kỳ

INITIAL Biểu thị rằng thẻ được phát ra bởi dịch vụ xác thực (AS) vàkhông được tạo ra dựa trên TGT

PRE-AUTHENT

Biểu thị rằng client đã được xác thực bởi KDC trước khi thẻđược phát ra Cờ này thường biểu thị sự hiện diện của mộtauthenticator ở trong thẻ Nó cũng có thể cho biết sự hiện diệncủa giấy tin cậy được lấy ra từ việc đăng nhập bằng thẻ thôngminh

HW-AUTHENT Biểu thị rằng việc xác thực ban đầu được thực hiện bằng cáchsử dụng phần cứng.

Các cờ của thẻ

Những thông tin các client biết về các thẻ

Một client cần phải có một vài thông tin về những thông tin ở bên trong các thẻ

và TGT để quản lý bộ đệm giấy tin cậy Khi KDC trả về một thẻ và khoá phiên như

là kết quả của việc trao đổi dịch vụ xác thực hoặc dịch vụ trao thẻ, nó đóng gói bảnsao khoá phiên của client trong một cấu trúc dữ liệu mà trong đó bao gồm các thôngtin trong các trường thẻ dưới đây: Authentication Time, Start Time, End Time, and

Renew Till Toàn bộ cấu trúc này được mã mật bằng khoá của client và được trả vềcùng với các thông điệp KRB_AS_REP hoặc KRB_TGS_REP.

Phương thức KDC giới hạn thời gian sống của thẻ

Mỗi thẻ có một thời gian bắt đầu và thời gian hết hạn Tại mọi thời điểm sauthời điểm bắt dầu nhưng trước thời điểm hết hạn, client đang lưu giữ thẻ của mộtdịch vụ có thể đưa ra thẻ này và giành được quyền truy cập đến dịch vụ mà khôngcần quan tâm đến client này đã sử dụng thẻ đó bao nhiêu lần trước đó Trong đó đểgiảm nguy cơ một thẻ hoặc khoá phiên tương ứng có thể bị xâm phạm, các nhà quảntrị có thể thiết lập thời gian sống tối đa cho các thẻ Việc thiết lập thời gian sống này

là một thành phần của chính sách Kerberos

Khi một client yêu cầu KDC cung cấp một thẻ cho một dịch vụ, client này cóthể yêu cầu một thời điểm bắt đầu cụ thể Nếu thời điểm bắt đầu này vắng mặt yêucầu hoặc là một thời điểm trong quá khứ, thì KDC thiết lập trường thời gian bắt đầucủa thẻ bằng thời gian hiện hành

Dù client có chỉ rõ thời điểm bắt đầu hay không, thì yêu cầu của nó phải baogồm thời điểm hết hạn được mong muốn KDC xác định giá trị trong trường EndTime của thẻ bằng cách cộng thời gian tồn tại tối đa được cố định bởi chính sáchKerberos với giá trị trong trường Start Time của thẻ Sau đó nó so sánh kết quả vớithời điểm hết hạn được yêu cầu Khi đó thời điểm nào sớm hơn sẽ là thời điểm kếtthúc của thẻ

Các hoạt động xảy ra khi các thẻ hết hạn

KDC không thông báo cho các client biết khi nào các thẻ dịch vụ hoặc TGT sắpsửa hết hạn Thêm nữa, ngoài việc duy trì các bản ghi short-term dùng để ngăn cảncác tấn công kiểu phát lại, nó không theo dõi các giao dịch với các client

Nếu một client đưa ra một thẻ dịch vụ đã hết hạn khi yêu cầu kết nối đến mộtserver, server sẽ trả về một thông điệp lỗi Client này phải yêu cầu một thẻ dịch vụmới từ KDC Tuy nhiên, sau khi một kết nối được xác thực, thì việc thẻ dịch vụ cócòn hợp lệ hay không không còn là điều quan trọng Các thẻ dịch vụ được sử dụngchỉ để xác thực các kết nối mới với các server Các hoạt động đang diễn ra không bịgián đoạn nếu thẻ dịch vụ, được sử dụng để xác thực kết nối, hết hạn trong lúc kếtnối

Nếu một client đưa ra một TGT đã hết hạn khi yêu cầu một thẻ dịch vụ từKDC, KDC sẽ đáp ứng lại bằng một thông điệp lỗi Client này phải yêu cầu mộtTGT mới, và để thực hiện điều đó nó cần khoá long-term của người dùng Nếuclient này không lưu trữ khoá này trong quá trình đăng nhập ban đầu, client có thểphải yêu cầu người dùng cung cấp mật khẩu và từ đó lấy ra được khoá long-term

2.5 Các TGT có thể gia hạn

Khi các client có thể gian hạn được, các khoá phiên được làm tươi mới mộtcách định kỳ mà không phát ra một thẻ mới hoàn toàn Nếu chính sách Kerberoscho phép các thẻ có thể gia hạn được, thì KDC sẽ thiết lập cờ RENEWABLE trongmọi thẻ mà nó phát ra và thiết lập hai thời điểm hết hạn trong thẻ đó Một thời điểmhết hạn giới hạn thời gian tồn tại của instance hiện hành của thẻ Thời điểm hết hạnthứ hai giới hạn thời gian tồn tại tích luỹ của tất cả các instance của thẻ Thời điểmhết hạn đối với instance hiện tại được lưu giữ trong trường End Time Cũng như làcác thẻ không được phép gia hạn, giá trị trong trường End Time bằng với giá trịtrong trường Start Time cộng với gia trị thời gian tồn tại lớn nhất của thẻ được quyđịnh bởi chính sách Kerberos Client đang giữ thẻ có thể gian hạn được phải gửi nó

- đồng thời đưa tra một authenticator mới - đến KDC để gia hạn trước thời điểm kếtthúc Khi KDC nhận được thẻ cần gia hạn, nó kiểm tra giá trị thời điểm hết hạn thứhai được lưu trong trường Renew Till Giá trị này được thiết lập khi thẻ được phát

ra lần đầu tiên Nó bằng với giá trị trong trong trường Start Time của thẻ cộng vớigiá trị thời gian tồn tại tích luỹ tối đa của thẻ được quy định bởi chính sáchKerberos Khi KDC gia hạn cho thẻ, nó kiểm tra để xác định xem thời điểm renew-till đã đến hay chưa Nếu chưa đến, KDC sẽ phát ra một instance mới của thẻ vớithời gian kết thúc muộn hơn và một khoá phiên mới Tại thời điểm kết thúc thờigian tồn tại tích luỹ, thẻ hết hạn và không còn hợp lệ để gia hạn nữa

3 Authenticator

Mỗi khi một client gửi một thẻ đến server đích, client cũng gộp mộtauthenticator vào trong thông điệp Authenticator này xác nhận rằng client được liệt

kê với tư cách người gửi trong thẻ thực sự là nơi gửi thẻ

3.1 Vai trò của authenticator

Server đích có thể tin tưởng nội dung của thẻ bởi vì thẻ đó được mã mật bằngkhoá mật của server đích đó Tuy nhiên, server đích có thể không tin rằng thẻ đóthực sự đã được gửi đi bởi chính client được chỉ ra trong thẻ Thẻ này có thể bị ăncắp và bây giờ được gộp vào trong thông điệp của kẻ giả danh

3.2 Hoạt động của authenticator

Authenticator được mã mật với khoá phiên, khoá này được tạo ra bởi KDC vàđược sử dụng giữa client và server đích Chỉ client và server đích có thể truy cậpđược vào khoá phiên này

Server đích sử dụng khoá mật của nó để giải mã thẻ dịch vụ, tìm ra khoá phiêntrong thẻ đó, và sử dụng nó để giãi mã authenticator

Nếu server đích có thể giãi mã thành công authenticator và nếu dữ liệu củaauthenticator là chính xác, thì server sẽ tin vào nguồn gốc của thẻ

3.3 Nhãn thời gian của authenticator

Nhãn thời gian này có thể là phần dữ liệu quan trọng nhất trong authenticator.Chính sách Kerberos của miền và các chính sách khác được thiết lập bởi các ứngdụng thường yêu cầu rằng nhãn thời gian phải trong phạm vi vài phút so với thờigian trên server đích Nếu ngược lại, authenticator này và thẻ tương ứng sẽ bị loại

bỏ Điều này giúp ngăn cản việc phát lại thông điệp Mặc dù không có authenticatornào được gộp vào trong thông điệp yêu cầu dịch vụ xác thực ban đầu, nhưng thôngđiệp này vẫn gộp nhãn thời gian của client trong trường tiền xác thực

3.4 Cấu trúc của authenticator

Bảng dưới đây liệt kê và mô tả các trường của authenticator Các cấu trúc dữliệu chính xác về các authenticator cũng như là các thông điệp có thể tìm thấy trongRFC 1510

Checksum

Một tổng kiểm tra dữ liệu từ thông điệp yêu cầu dịch vụ trao thẻKRB_TGS_REQ) hoặc yêu cầu server ứng dụng(KRB_AP_REQ) mà authenticator là một thành phần Điều nàygiúp xác nhận rằng người gửi thông điệp thật sự là client đó

Subkey

Trong KRB_AP_REQ, trường này chỉ ra một khoá con mà serverđích và client sẽ sử dụng để mã mật các cuộc truyền thông sau đó,thay vì sử dụng khoá phiên do TGS cung cấp

Máy chủ Kerberos phải có định danh người dùng và mật khẩu dạng băm của tất

cả người dùng trong cơ sở dữ liệu Tất cả người dùng đều đã đăng kí với máy chủKerberos

Máy chủ Kerberos phải dùng chung khóa bí mật với mỗi máy chủ dịch vụ Tất

cả máy chủ này đều đã đăng kí với máy chủ Kerberos

Một hệ thống như thế gọi là một phạm vi an toàn (realm) Mạng của các máykhách và máy chủ trong các tổ chức quản trị khác nhau tạo thành các phạm vi/miềnkhác nhau

Vì thế, nói chung là không thực tế hoặc không tuân theo chính sách quản trị khibắt người dùng và máy chủ ở phạm vi này phải đăng kí với máy chủ Kerberos ởvùng khác Tuy nhiên, người dùng trong một phạm vi có thể cần truy nhập tới cácmáy chủ ở trong vùng khác và một số máy chủ trong vùng cũng có thể phải phục vụcho người dùng ở vùng khác

Kerberos cung cấp một cơ chế cho phép chứng thực liên vùng Để hai vùng cóthể chấp nhận chứng thực liên vùng, cần có thêm một bên thứ ba

Máy chủ server của mỗi phạm vi liên vận hành dùng chung một khóa với máychủ trong khu vực kia Có hai máy chủ Kerberos đăng kí lẫn nhau

Mô hình này yêu cầu máy chủ Kerberos trong một vùng tin cậy vào máy chủKerberos của vùng kia để chứng thực người dùng của nó Hơn nữa, các máy chủcủa vùng thứ hai phải tin cậy máy chủ Kerberos của vùng thứ nhất

Từ đó, ta có thể mô tả cơ chế hoạt động như hình dưới đây:

Chứng thực liên vùng trong Kerberos

Một người dùng muốn truy nhập dịch vụ của máy chủ trong vùng khác thì cầnphải có vé của máy chủ đó Client của người dùng như thường lệ sẽ liên hệ với TGS

và yêu cầu vé xin cấp vé cho TGS từ xa Sau đó, client có thể truy nhập tới TGS ở

xa để có vé yêu cầu dịch vụ cho máy chủ tương ứng trong vùng đó

Kerberos hỗ trợ hai loại cấu trúc realm, chứng thực liên vùng ngang hàng to-one cross authentication) và chứng thực liên vùng phân cấp (hierachical crossauthentication) Điều này đảm bảo cho tính co giãn của hệ thống Kerberos

(one-5 Những cải tiến chính trong Kerberos phiên bản 5

Phiên bản 5 Kerberos được đặc tả trong RFC 1510 và cải tiến phiên bản 4 rấtnhiều Điểm khác nhau giữa hai phiên bản có thể nhóm lại thành : Các yếu kém môitrường, phụ thuộc kỹ thuật

Các yếu kém môi trường (Environmental shortcomings)

- Phụ thuộc hệ thống mã hóa : Phiên bản 4 yêu cầu phải sử dụng DES Vìthế, các thiếu sót thấy được của DES cũng như mọi ngờ vực về sức mạnhcủa DES phải được xem đến Trong phiên bản 5, bản mã được đính kèmthêm chỉ danh kiểu mã hóa được dùng vì thế bất kì kiểu mã hóa nào cũng

có thể sử dụng Các khóa mã hóa được gắn kèm kích thước và kiểu loạinên một khóa có thể sử dụng cho nhiều thuật toán khác nhau và cho phépbiến đổi theo các đặc tả khác nhau của thuật toán sử dụng

- Phụ thuộc vào giao thức Internet : Phiên bản 4 yêu cầu phải sử dụng địachỉ IP Các kiểu địa chỉ khác, như địa chỉ mạng ISO không được chấpnhận Phiên bản 5, địa chỉ mạng được đính thêm thẻ độ dài và kiểu địachỉ cho phép bất kì kiểu địa chỉ nào cũng có thể sử dụng

- Sắp xếp byte thông điệp : Trong phiên bản 4, người gửi thông điệp sửdụng một trật tự byte của nó và gắn thẻ để chỉ ra byte ít có ý nghĩa nhất ởđịa chỉ thấp nhất hoặc byte có ý nghĩa cao nhất ở địa chỉ thấp nhất Kỹthuật này được sử dụng nhưng không tuân theo thoả thuận thiết lập

- Ticket lifetime : Thời gian hiệu lực trong phiên bản 4 được mã hóa thànhtừng khối 8 bít của 5 phút một Vì thế, giá trị tối đa của thời gian hiệu lực

là 28 * 5 = 1280 phút hay bé hơn 21 giờ Như thế có thể không đủ chomột số ứng dụng Trong phiên bản 5 các vé có “ghi” rõ thời gian bắt đầu

và thời gian kết thúc

- Chuyển tiếp chứng thực : Trong phiên bản 4 không cho phép giấy chứngthực cấp cho một người dùng chuyển tiếp cho các máy khác và được sửdụng bởi các client khác Chuyển tiếp chứng thực sẽ cho phép client cóthể truy nhập vào máy chủ và cho phép máy chủ truy nhập tới máy chủkhác mà client có quyền Ví dụ, client phát ra một yêu cầu đến máy chủ

in, máy chủ này sẽ truy nhập vào máy chủ file có sử dụng giấy chứngthực của client đó Phiên bản 5 có cung cấp khả năng này

- Chứng thực liên vùng : Trong phiên bản 4, khả năng liên vận hành giữa Nvùng khác nhau yêu cầu phải có N2 quan hệ Kerberos-Kerberos Phiênbản 5 hỗ trợ chức năng với yêu cầu về số quan hệ là bé hơn

Phụ thuộc kỹ thuật (Technical deficiencies)

- Mã hóa kép :Vé trước khi cung cấp cho client được mã hóa hai lần, mộtlần sử dụng khóa bí mật của máy chủ cần truy nhập và một lần bằng khóa

bí mật của người dùng Việc mã hóa lần thứ hai là không cần thiết, gâylãng phí tính toán

- Mã hóa PCBC : Mã hóa trong phiên bản 4 sử dụng kiểu mã hóa khôngtheo chuẩn của DES gọi là mã hóa móc xích truyền khối (propagatingcipher block chaining - PCBC) Kiểu mã hóa này có nguy cơ bị tấn côngbằng cách tráo đổi các khối mã với nhau Bởi PCBC cho phép kiểm tratoàn vẹn như là một phần của thao tác mã hóa Phiên bản 5 cung cấp một

cơ chế kiểm tra rõ ràng cho phép chế độ CBC chuẩn có thể sử dụng để

mã hóa

- Các khóa phiên : Mỗi vé gắn kèm một khóa phiên được client sử dụng để

mã hóa authenticator gửi cho dịch vụ tương ứng với vé Hơn nữa, khóa

phiên có thể được người dùng và máy chủ tiếp tục sử dụng để bảo vệ cácthông điệp truyền trong phiên Tuy nhiên, do sử dụng một khóa để sửdụng dịch vụ của mỗi máy chủ nên dễ bị kẻ gian tấn công bằng cách dùnglại thông điệp của phiên cũ gửi cho máy chủ hoặc client Trong phiên bản

5, máy chủ và client có thể dàn xếp với nhau để sử dụng một khóa phiêncon, khóa này chỉ có hiệu lực trong một kết nối Cứ mỗi lần client truycập có thể lại phải sử dụng khóa phiên con mới

- Tấn công mật khẩu : Cả hai phiên bản đều có điểm yếu là có thể bị tấncông mật khẩu Thông điệp từ AS tới client sử dụng khóa phiên sinh ra từmật khẩu người dùng Kẻ địch có thể bắt lấy thông điệp và cố gắng giải

mã bằng nhiều mật khẩu khác nhau Nếu thành công kẻ địch có thể sửdụng để lấy chứng thực từ Kerberos Phiên bản 5 sử dụng cơ chế gọi làtiền chứng chứng thực làm cho việc tấn công mật khẩu khó khăn hơnnhiều nhưng không hẳn là ngăn chặn được !

6 Đánh giá giao thức Kerberos

Qua quá trình phát triển, Kerberos đã đạt đến độ thuần thục, ổn định; phiên bảnKerberos v5 đã được cài đặt trên hầu hết các nền tảng, được sử dụng trong rất nhiềuứng dụng Việc sử dụng giao thức Kerberos để xây dựng hệ thống sẽ đảm bảonhững tính năng sau cho hệ thống:

6.1.Tăng cường bảo mật

Khi một phiên truyền thông được thiết lập, khoá phiên sẽ được truyền an toànđến các bên truyền thông Điều này sẽ đảm bảo cho hệ thống các tính năng bảo mậtsau:

- Tính xác thực: Không ai gửi một thông điệp sai Do chỉ có client và máy

chủ dịch vụ có thể biết được khoá phiên nên không thể xảy ra trường hợp

có kẻ thứ ba mạo danh một trong hai bên để tham gia vào phiên truyền

thông Ở đây, Kerberos đảm bảo tính Chứng thực lẫn nhau.

- Tính riêng tư, tính toàn vẹn: Thông điệp trước khi truyền sẽ được mã hoá

và kí bằng khoá phiên nên thám mã không thể nào có thể đọc hay thayđổi nội dung thông điệp được truyền

Như vậy, sử dụng giao thức Kerberos thì ta được đảm bảo tính xác thực, tính

riêng tư, và tính toàn vẹn của các thông điệp được truyền Đây chính là các yêu cầu