Các vấn đề chính

• Kerberos là một dịch vụ chứng thực được thiết kế để sử dụng trong môi trường phân
tán.
• Kerberos sử dụng một dịch vụ chứng thực từ một bên tin cậy thứ ba cho phép các client
và các server thiết lập mối liên lạc chứng thực.

KERBEROS
Kerberos1 là một dịch vụ chứng thực được phát triển như một bộ phận của dự án Athena tại
MIT. Mục tiêu mà Kerberos quan tâm là: giả thiết về một môi trường phân tán mở, trong đó, người
dùng tại các trạm làm việc muốn truy xuất đến các dịch vụ tại các server phân tán trong mạng. Chúng
ta mong muốn các server có thể hạn chế các truy xuất để bảo mật và có khả năng chứng thực các yêu
cầu dịch vụ. Trong môi trường này, một trạm làm việc không thể được coi là tin cậy để nhận diện
đúng người dùng nó. Cụ thể, có ba nguy cơ sau đây:
• Một người dùng có thể truy xuất đến một trạm làm việc và thủ vai một người dùng khác
trên trạm làm việc đó.
• Một người dùng có thể thay địa chỉ mạng của trạm làm việc để các yêu cầu gửi từ trạm
này xuất hiện như nó đến từ một trạm khác.
• Một người dùng có thể nghe/xem lén các thông điệp qua lại và dùng tấn công nhại để
truy xuất server hoặc phá hoại các hoạt động mạng.
Trong bất cứ trường hợp nào vừa nêu, một người dùng giả mạo có thể đoạt được quyền truy
xuất dịch vụ và dữ liệu. Thay vì xây dựng một loạt các dịch vụ chứng thực cho mỗi server, Kerberos
hỗ trợ một server chứng thực trung tâm với chức năng chứng thực người dùng đến server và server
đến người dùng. Không như các hình thức chứng thực khác, Kerbero thực sự dựa trên mã hóa đối
xứng, không sử dụng mã hóa khoá-công-khai.
Hai phiên bản Kerberos được sử dụng phổ biến. Version 4 [MILL88, STEI88] đến nay vẫn
còn sử dụng. Version 5 [KOHL94] sửa chữa một số khiếm khuyết an ninh của phiên bản 4 và được
đề nghị là một chuẩn Internet (Internet Standard RFC 1510)2.
Chúng ta bắt đầu mục này bằng một nghiên cứu ngắn gọn về động lực của phương pháp
Kerberos. Sau đó, do sự phức tạp của Kerberos, cách tốt nhất để bắt đầu với một mô tả về giao thức
chứng thực được sử dụng trong phiên bản Kerberos 4, nó cho chúng ta thấy bản chất thực sự trong
chiên lược Kerberos mà không cần phải xem xét các chi tiết đòi hỏi xử lý các nguy cơ an ninh tinh
vi. Cuối cùng, chúng ta nghiên cứu phiên bản Kerberos 5.

1
Trong thần thoại Hy Lạp, Kerberos là một loại chó nhiều đầu, thường là ba, với một cái đuôi rắn giữ lối
vào đền Hades. (Dictionary of Subjects and Symbols in Art, by James Hall, Harper & Row, 1979). Cũng như chó
Kerberos có ba đầu, mô hình Kerberos hiện đại từng có ý định bao gồm ba thành phần để bảo vệ một cổng mạng:
chứng thực, theo dõi và kiểm định. Nhưng hai “đầu” sau chưa bao giờ được thực hiện.
2
Các phiên bản từ 1 đến 3 là các phiên bản phát triển nội bộ. Version 4 là "original" Kerberos
 Nếu một tập hợp người dùng được hỗ trợ bởi các máy tính cá nhân không nối mạng, thì các
tập tin và tài nguyên của người dùng có thể được bảo vệ bằng các giải pháp an ninh vật lý. Khi
những người dùng này được phục vụ bởi một hệ thống trung tâm chia xẻ thời gian, hệ điều hành nhất
thiết phải thi hành an ninh. Hệ điều hành chia xẻ thời gian có thể bắt buộc phải thi hành chính sách
điều khiển truy xuất dựa trên nhận dạng người dùng và sử dụng thủ tục nhận dạng.
Ngày nay, những kịch bản nêu trên ngày càng hiếm. Phổ biến hơn là một kiến trúc phân tán
gồm các trạm làm việc của người dùng (client) và các server phân tán hoặc trung tâm. Trong môi
trường này, có thể tồn tại ba phương pháp an ninh:
1. Dựa vào từng trạm làm việc để bảo đảm nhận dạng riêng người dùng của nó và dựa trên
mỗi server để thi hành một chính sách bảo mật dựa trên nhân dạng của người dùng (ID).
2. Đòi hỏi các hệ thống client phải tự chứng thực chúng với các server, mà sự tin cậy của
chính hệ thống client liên quan đến nhận dạng của người dùng.
3. Đòi hỏi người dùng chứng minh nhận dạng của họ mỗi khi đòi hỏi truy cập một dịch vụ.
Cũng đòi hỏi rằng các server phải chứng thực với các client.
Trong một môi trường nhỏ, khép kín mà các hệ thống đều thuộc một tổ chức, phương pháp
đầu tiên và có lẽ cả phương pháp thứ hai cũng thỏa mãn. Nhưng trong một môi trường mở, là hệ
thống mạng kết nối đến các máy khác thì phương pháp thứ ba là cần thiết để bảo vệ thông tin người
dùng và quản lý tài nguyên tại server. Kerberos hỗ trợ phương pháp thứ ba này. Các Kerberos giả
thiết về một kiến trúc client/server và tổ chức một hay nhiều server Kerbero để đưa ra dịch vụ chứng
thực.
Công bố đầu tiên về Kerberos [STEI88] liệt kê các yêu cầu kỹ thuật sau đây:
• Bảo mật: Kẻ xem trộm mạng không thể thu được thông tin cần thiết để thủ vai một
người dùng. Tổng quát hơn, Kerberos cần đủ mạnh để kẻ tấn công không tìm được điểm
yếu.
• Tin cậy: Với tất cả các dịch vụ dựa vào Kerberos để điều khiển truy xuất, thiếu hiệu lực
của dịch vụ Kerberos có nghĩa là thiếu đi tính sẵn dùng của dịch vụ. Do đó, Kerberos cần
thực sự tin cậy và bao hàm một kiến trúc server phân tán với một server làm nhiệm vụ dự
phòng cho server khác.
• Tính dễ dùng: Rất lý tưởng nếu người dùng không nhận biết được rằng thủ tục chứng
thực được thi hành, không nhiều hơn một đòi hỏi nhập một mật khẩu.
• Tính mở rộng: Hệ thống cần có khả năng hỗ trợ một số lớn các client và server. Điều
này đề nghị một kiến trúc module và phân tán.
Để thực hiện được các yêu cầu kỹ thuật nêu trên, Kerberos được xây dựng làm một bên thứ
ba tin cậy thi hành dịch vụ chứng thực dựa trên giao thức của Needham và Schroeder [NEED78], đã
thảo luận trong Chương 7. Sự tin cậy diễn ra khi các client và server thi hành chứng thực lẫn nhau
một cách gián tiếp. Giả thiết giao thức Kerberos được thiết kế hoàn hảo thì dịch vụ chứng thực là an
toàn nếu server Kerberos an toàn.
14.1.2 Kerberos Version 4
Phiên bản 4 của Kerberos sử dụng DES, trong một giao thức khá tỷ mỷ để có được dịch vụ
chứng thực. Xem xét toàn bộ giao thức, rất khó nhận thấy sự cần thiết của rất nhiều thành phần được
chứa trong đó. Vì thế, chúng ta chấp nhận một chiến lược được sử dụng bởi Bill Bryant trong dự án
Athena [BRYA88] và xây dựng nên một giao thức đầy đủ bằng cách trước hết tìm tới một số đối
thoại với các giả thuyết. Lần lượt từng đoạn đối thoại liên tiếp tăng thêm sự phức tạp để cung cấp an
ninh cho đối thoại trước đó.
Sau khi khảo sát giao thức, chúng ta nghiên cứu các khía cạnh trong phiên bản 4.

Đối thoại giản đơn về chứng thực

Trong một môi trường mạng không được bảo vệ, một client bất kỳ có thể yêu cầu dịch vụ của
bất kỳ server nào. Nguy cơ an ninh hiển nhiên là sự thủ vai bất hợp pháp. Một kẻ có thể giả làm một
client khác và chiếm quyền trên các máy server. Để đối phó với nguy cơ này, các server phải có khả
năng xác nhận thực thể client đang đòi dịch vụ. Mỗi server có thể yêu cầu thực thi tác vụ này đối với
mỗi giao tiếp client/server. Trong một môi trường mở, điều này đặt gánh nặng đáng kể lên từng
server.
Một cách khác là sử dụng server chứng thực (AS) mà nó biết mật khẩu của tất cả người dùng
và lưu trữ trong một cơ sở dữ liệu được kiểm soát chặt chẽ. Thêm nữa, AS chia xẻ một mật khóa duy
nhất cho mỗi server. Các mật khóa này được phân phối vật lý hay bằng cách an toàn nào đó. Xét đối
thoại mang tính giả thuyết sau:
(1) C  AS: IDC||PC||IDV
(2) AS  C: Ticket
(3) C  V: IDC||Ticket
Ticket = E(Kv, [IDC||ADC||IDV])
với
C = client
AS = server chứng thực
V = server
IDC = nhận dạng người dùng tại C
IDV = nhận dạng của V
PC = mật khẩu người dùng tại C
ADC = địa chỉ mạng của C
Kv = khóa bí mật chi xẻ bởi AS và V
Trong kịch bản này, người dùng đăng nhập hệ thống qua một trạm làm việc và yêu cầu truy
xuất server V. Module client C tại trạm làm việc yêu cầu mật khẩu của người dùng và gửi thông điệp
tới AS chứa ID của người dùng, ID của server và mật khẩu người dùng. AS kiểm tra trong cơ sở dữ
liệu của nó đối chiếu với mật khẩu của người dùng gửi tới và người dùng có quyền truy xuất server V
hay không. Nếu đạt cả hai phép kiểm tra, AS chấp nhận người dùng là tin cậy và phải làm cho server
tin điều đó. Để làm thế, AS tạo một ticket chứa ID của người dùng, địa chỉ mạng và ID của server.
Ticket này được mã hóa bằng khóa riêng đã chia xẻ giữa server và AS. Ticket này sau đó được gửi
trở lại cho C. Vì ticket được mã hóa nên C hay các đối tượng khác không thể sửa đổi.
Với ticket này, C có thể yêu cầu dịch vụ tại server V. C gửi thông điệp cho V chứa ID của C
và ticket. V giải mã ticket và xác minh ID của người dùng trong ticket với ID không mã hóa gắn
trong thông điệp. Nếu cả hai phù hợp với nhau, server coi người dùng đã được chứng thực và cung
cấp dịch vụ đã yêu cầu.
Từng thành phần trong thông điệp (3) rất quan trọng. Ticket được mã hóa chống giả mạo. ID
của server (IDV) được bao gồm trong ticket để server có thể xác minh ticket là đúng đắn. ID C trong
ticket biểu thị ticket này được phát hành thay mặt C. Sau cùng, AD C đóng vai trò chống lại các nguy
cơ sau. Đối phương có thể chặn thông điệp (2) chứa ticket, sau đó dùng ID C và truyền thông điệp (3)
đến một trạm khác. Server nhận ra ticket hợp lệ phù hợp với ID của người dùng và cấp quyền truy
xuất cho người dùng từ trạm làm việc đó. Để chống lại tấn công này, AS bao gồm trong ticket địa chỉ
mạng của trạm thực sự yêu cầu dịch vụ. Như thế, ticket chỉ hợp lệ nếu nó được truyền từ trạm đã
phát ra yêu cầu dịch vụ.

14.1.2.2 Kịch bản an toàn hơn

Mặc dù kịch bản trên giải quyết được một số vấn đề chứng thực trong một môi trường mạng
mở, vẫn còn tồn tại các vấn đề khác. Hai vấn đề nổi bật. Thứ nhất, chúng ta muốn tối thiểu hóa số lần
người dùng phải nhập mật khẩu. Giả sử mỗi ticket chỉ có thể được dùng một lần. Nếu người dùng C
đăng nhập ở một trạm làm việc vào buổi sáng và muốn duyệt mail ở một máy chủ mail, C phải cung
cấp mật khẩu để lấy một ticket vào máy chủ mail. Nếu C muốn kiểm tra hộp mail của anh ta vài ba
lần trong ngày, mỗi lần phải nhập lại mật khẩu. Chúng ta có thể cải thiện bằng cách cho phép dùng
lại các ticket. Với một phiên đăng nhập, trạm làm việc có thể lưu trữ ticket cho máy chủ mail sau khi
nó nhận được và sử dụng ticket thay mặt cho người dùng để truy xuất nhiều lần vào máy chủ.
Nhưng, dưới hình thức này còn tồn tại trường hợp khi một người dùng cần một ticket mới
cho mỗi dịch vụ khác nhau. Nếu người dùng muốn truy cập một print server, một mail server, file
server v.v… thì lần đầu tiên truy cập dịch vụ vẫn cần phải có một ticket mới và do đó lại đòi hỏi mật
khẩu người dùng.
Vấn đề thứ hai nữa là kịch bản đầu tiên đòi hỏi truyền mật khẩu dưới dạng plaintext [thông
điệp (1)]. Một kẻ nghe lén có thể bắt được mật khẩu và sử dụng bất cứ dịch vụ nào mà nạn nhân có
thể truy xuất.
Để giải quyết các vấn đề tăng thêm này, chúng ta giới thiệu một hình thức ngăn ngừa các mật
khẩu dạng plaintext và ra đời một loại server mới, gọi là server cấp ticket [ticket-granting server
(TGS)]. Kịch bản mới nhưng vẫn chỉ có tính cách giả thuyết này như sau:
Một lần khi người dùng đăng nhập:
 (1) C → AS: IDC||IDtgs
(2) AS → C: E(Kc, Tickettgs)
Một lần cho một loại dịch vụ:
(3) C →TGS: IDC||IDV||Tickettgs
(4) TGS → C: Ticketv
Một lần cho phiên dịch vụ:
(5) C →V: IDC||Ticketv
Tickettgs = E(Ktgs, [IDC||ADC||IDtgs||TS1||Lifetime1])
Ticketv = E(Kv, [IDC||ADC||IDv||TS2||Lifetime2])
Dịch vụ mới, TGS, phát các ticket cho người dùng đã được chứng thực bởi AS. Do đó, trước
hết yêu cầu AS một ticket vào server cấp ticket (Tickettgs). Module client trong máy trạm lưu lại
ticket này. Mỗi lần người dùng cần truy cập vào một dịch vụ mới thì module client trình ticket cho
TGS để chứng thực nó. TGS sẽ cấp một ticket cho dịch vụ cụ thể. Client lại lưu trữ ticket truy cập
dịch vụ này chho những lần người dùng muốn truy cập sau đó. Chúng ta hãy xem xét chi tiết hơn nữa
hình thức này:
1. Client thay mặt người dùng yêu cầu một ticket cấp-ticket cho AS bằng cách gửi ID và
mật khẩu của người dùng, cùng với ID của TGS, biểu thị yêu cầu sử dụng dịch vụ TGS.
2. AS đáp lại bằng một ticket được mã hóa bằng khóa mà nó lấy ra từ mật khẩu của người
dùng. Khi ticket này trở lại client, client yêu cầu mật khẩu một lần nữa, sinh ra khóa và
cố gắng giải mã thông điệp mới đến. Nếu mật khẩu phhù hợp, ticket được phục hồi.
Do chỉ có người dùng hợp lệ mới biết mật khẩu, chỉ anh ta mới có thể phục hồi ticket được
cấp bởi AS. Như thế, chúng ta đã sử dụng mật khẩu để có được sự ủy nhiệm từ Kerberos mà không
cần phải truyền mật khẩu dưới dạng plaintext. Trong ticket đã có chứa ID và địa chỉ mạng của người
dùng và ID của TGS. Điều này tương ứng với kịch bản thứ nhất. Ý tưởng là client có thể sdgg ticket
này để nhiều lần yêu cầu ticket cấp dịch vụ. Vậy ticket cấp-ticket được phép sử dụng lại. Tuy nhiên,
chúng ta không muốn kẻ nào đó bắt giữ được ticket và dùng nó.
Hãy xét kịch bản sau: đối phương bắt giữ được ticket đăng nhập và đợi đến khi người dùng
thực sự đăng xuất khỏi trạm làm việc. Khi đó, hắn chiếm quyền truy xuất vào trạm làm việc đó hoặc
cấu hình lại trạm của hắn bằng địa chỉ mạng của nạn nhân. Bây giờ hắn có khả năng dùng lại ticket
để lừa đảo TGS. Để chống lại điều này, ticket bao gồm một nhãn thời gian, biểu thị ngày, giờ ticket
được phát hành và một thời gian sống nhất định biểu thị khoảng thời gian hợp lệ của ticket (chẳng
hạn, tám giờ đồng hồ). Do đó, client bây giờ có một ticket dùng lại được và không cần làm phiền
người dùng về mật khẩu mỗi lần yêu cầu dịch vụ mới. Cuối cùng, lưu ý rằng ticket cấp-ticket được
mã hóa với một khóa bí mật chỉ được biết bởi AS và TGS. Điều này ngăn ngừa sự thay đổi ticket.
Ticket được mã hóa lại với một khóa dựa trên mật khẩu người dùng. Điều này bảo đảm rằng ticket
chỉ có thể phục hồi bởi chính người dùng và thế bảo đảm cả sự chứng thực.
 Bây giờ client đã có ticket cấp-ticket để truy cập vào bất cứ server nào được phép bằng các
bước 3 và 4:
3. Client thay mặt người dùng yêu cầu một ticket cấp-dịch vụ. Với mục đích này, client
truyền một thông điệp cho TGS, chứa ID của người dùng, ID của server chứa dịch vụ
mong muốn và ticket cấp-ticket.
4. TGS giải mã ticket gửi đến và xác minh ID trong ticket. Sự kiểm tra bao gồm cả bảo đảm
thời gian sống của ticket. Sau đó nó so sánh với ID và địa chỉ mạng của người dùng để
chứng thực. Nếu người dùng được chứng thực và có quyền truy cập server V, TGS sẽ cấp
ticket truy xuất dịch vụ trên server V.
Ticket cấp-dịch vụ có cấu trúc giống như ticket cấp-ticket. Quả vậy, do TGS là một server,
chúng ta luôn muốn có được sự chứng thực trên cùng các thành phần giữa client với TGS và client
với các server dịch vụ. Một lần nữa, ticket chứa một nhãn thời gian và một thời gian sống. Nếu người
dùng muốn truy xuất trở lại cùng một dịch vụ, thì client chỉ cần sử dụng ticket cấp-dịch vụ đã có
trước đó và không phải phiền đến người dùng phải cung cấp lại mật khẩu. Chú ý rằng ticket được mã
hóa với một mật khóa (Kv) chỉ TGS và server dịch vụ biết.
Sau cùng, với một ticket cấp-dịch vụ, client có thể truy xuất dịch vụ tương ứng:
5. Client thay mặt người dùng yêu cầu truy xuất dịch vụ. Để làm được như thế, client
truyền một thông điệp cho server mang theo ID người dùng và ticket cấp-dịch vụ. Server
thi hành chứng thực client thông qua mội dung của ticket.
Kịch bản mới này thỏa mãn hai đòi hỏi với chỉ một lần yêu cầu mật khẩu người dùng trong
phiên làm việc, đồng thời, bảo vệ được mật khẩu của người dùng.

Đối thoại chứng thực trong phiên bản 4

Mặc dù ngữ cảnh nêu trên đã tăng cường được khả năng an ninh hơn nhưng vẫn còn tồn tại
hai vấn đề. Vấn đề thứ nhất là thời gian hợp lệ của ticket cấp-ticket. Nếu thời gian quá ngắn (chẳng
hạn, vài phút), thì người dùng sẽ liên tục bị đòi hỏi nhập mật khẩu. Nếu dài, (chẳng hạn, vài giờ) thì
đối phương có cơ hội lớn hơn để mở các tấn công nhại. Kẻ nào đó có thể theo dõi trộm từ trên mạng
và bắt giữ một bản sao ticket cấp-ticket rồi chờ đợi cho đến khi người dùng tương ứng đăng xuất
khỏi mạng. Rồi hắn giả mạo người dùng địa chỉ hợp pháp và gửi thông điệp (3) cho TGS. Việc này
có thể giúp hắn có quyền truy xuất không hạn chế tới các tài nguyên và các tập tin của người dùng
đích thực.
Tương tự, nếu đối phương bắt giữ được ticket cấp-dịch vụ và sử dụng nó trước khi hết hạn thì
hắn có thể truy xuất tới dich vụ tương ứng.
Cho nên, chúng ta đi đến một đòi hỏi nữa. Một dịch vụ mạng (TGS hay một dịch vụ ứng
dụng) phải có khả năng chứng minh rằng người đang dùng ticket chính là người mà ticket ấy được
cấp cho.
Tồn tại thứ hai là có thể đòi hỏi server phải tự chứng thực chính nó với người dùng. Không
có phương tiện chứng thực như thế, đối phương có thể hiệu chỉnh sửa đổi cấu hình để các thông điệp
từ server lại được gửi thẳng về địa chỉ khác. Một server bị cấu hình sai sau đó sẽ ở vào vị trí như một
server thực sự, ngăn cản tất cả các thông tin từ người dùng và từ chối dịch vụ cần thiết và hợp pháp
của họ.
Chúng ta lần lượt nghiên cứu các vấn đề này trong khi tham chiếu tới bảng 14.1, nó thể hiện
nội dung giao thức Kerberos đích thực.
Trước hết, xét vấn đề mà các ticket cấp ticket bị bắt giữ và sự cần thiết phải xác định rằng
người dùng ticket đúng là client mà ticket đó được cấp cho. Nguy cơ ở đây là kẻ nào đó sẽ lấy trộm
ticket và dùng nó trước khi hết hạn sử dụng. Xoay quanh vấn đề này, chúng ta hãy giả thiết rằng AS
có thể cung cấp các thông tin bí mật cho cả client và TGS bằng một cách thức an toàn. Thì client có
thể tự chứng minh nhận dạng đối với TGS bằng cách bộc lộ thông tin bí mật, cũng bằng cách bí mật.
Một cách thức hiệu quả trong thi hành việc này là sử dụng khóa mã hóa như thông tin bí mật. Trong
Kerberos gọi nó là khóa phiên.
Bảng 14.1 Tóm tắt trao đổi thông điệp trong Kerberos Version 4

(a) Trao đổi dịch vụ chứng thực để nhận Tickettgs

(1) C AS: IDc||IDtgs||TS1

(2) AS C: E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])
Tickettgs = E(Ktgs, [Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2])

(b) Trao đổi dịch vụ cấp ticket để lấy TicketV

(3) C TGS: IDv||Tickettgs||Authenticatorc

(4) TGS C: E(Kc,tgs, [Kc,v||IDv||TS4||Ticketv])
Tickettgs = E(Ktgs, [Kc,tgs||IDC||ADC||IDtgs||TS2||Lifetime2])
Ticketv = E(Kv, [Kc,v||IDC||ADC||IDv||TS4||Lifetime4])
Authenticatorc = E(Kc,tgs, [IDC||ADC||TS3])

(c) Client/Server trao đổi chứng thực để lấy dịch vụ

(5) C V: Ticketv||Authenticatorc

(6) V C: E(Kc,v, [TS5 + 1]) (chứng thực lẫn nhau)

Ticketv = E(Kv, [Kc,v||IDc||ADc||IDv||TS4||Lifetime4])

Authenticatorc = E(Kc,v,[IDc||ADC||TS5])

Bảng 14.1a minh họa kỹ thuật phân phối khóa phiên. Như trước, client gửi thông điệp đến
AS để yêu cầu được truy xuất đến TGS. AS đáp lại bằng một thông điệp chứa ticket được mã hóa với
một khóa được lấy ra từ mật khẩu của người dùng (Kc). Thông điệp mã hóa này cũng chứa một bản
sao khóa phiên, Kc,tgs, mà các chỉ số dưới biểu thị rằng đây là khóa phiên cho C và TGS. Vì khóa
phiên này nằm bên trong thông điệp được mã hóa bằng Kc, chỉ client của người dùng mới đọc được.
Cũng khóa phiên đó được gói trong ticket và chỉ đọc được bởi TGS. Do đó, khóa phiên đã được
chuyển giao an toàn cho cả C và TGS.
Lưu ý về một số thông tin thêm vào cho pha đầu tiên của hội thoại. Thông điệp (1) gồm một
timestamp để AS biết được thông điệp là đúng lúc. Thông điệp (2) bao gồm một vài phần tử của
ticket dưới dạng C có thể đọc được. Nó cho phép C xác nhận rằng ticket này dành cho TGS và nắm
được thời gian hết hạn.
Được trang bị ticket và khóa phiên, C sẵn sàng tiếp cận TGS. Như trước, C gửi TGS một
thông điệp chứa ticket và ID của dịch vụ (thông điệp 3). Thêm nữa, C truyền thẻ chứng thực chứa ID
và địa chỉ người dùng client C với một timestamp. Không như ticket, dùng lại được, thẻ chứng thực
chỉ dùng một lần và có thời hạn sử dụng rất ngắn. TGS giải mã ticket bằng khóa đã chia xẻ với AS.
Ticket này biểu thị rằng C đã được hỗ trợ khóa phiên K c,tgs. Về bản chất, ticket nói rằng: “Người sử
dụng Kc,tgs phải là C”. TGS sử dụng khóa phiên giải mã thẻ chứng thực rồi kiểm tra tên và địa chỉ
trong thẻ với ticket cùng với đối chiếu địa chỉ mạng của thông điệp gửi đến. Nếu tất cả phù hợp thì
TGS được bảo đảm về người gửi ticket cũng chính là người sở hữu nó. Bản chất, thẻ chứng thực nói
“Vào thời điểm TS3, tôi sẽ sử dụng Kc,tgs”. Lưu ý rằng ticket không hề chứng minh nhận dạng của
người sử dụng nào nhưng là một cách để bàn giao mật khóa an toàn. Nó là thẻ chứng thực để chứng
minh nhận dạng client. Vì thẻ chứng thực chỉ sử dụng một lần và có thời hạn rất ngắn nên nguy cơ bị
lấy cắp cả ticket và thẻ chứng thực nhằm sử dụng sau đó đã được giải quyết.
Sự trả lời từ TGS, thông điệp (4), cùng dạng với thông điệp (2). Thông điệp được mã hóa
bằng khóa phiên được chia xẻ giữa TGS và C và bao hàm một khóa phiên nhằm chia xẻ giữa C và
server V, ID của V và timestamp cho ticket. Ticket cũng chứa cùng khóa phiên.
C bây giờ có thể sử dụng lại ticket dịch vụ vào V. Khi C trình ticket trong thông điệp (5), nó
cũng gửi kèm cả thẻ chứng thực. Server giải mã ticket, lấy khóa phiên và giải mã thẻ chứng thực.
Nếu đòi hỏi chứng thực lẫn nhau, server sẽ đáp lại thông điệp (6), trong đó gồm giá trị
timestamp trong thẻ chứng thực, được tăng lên 1 và được mã hóa bằng khóa phiên. C giải mã thông
điệp lấy timestamp đã tăng. Vì thông điệp được mã hóa bằng khóa phiên, C chắc chắn rằng đó không
phải là nhại một thông điệp cũ.
Sau cùng, client và server chia xẻ một mật khóa. Khóa này có thể được sử dụng trong các
thông điệp sau đó giữa đôi bên hoặc để trao đổi một khóa phiên mới.
Bảng 14.2 tóm tắt về các thành phần sử dụng trong giao thức Kerberos và hình 14.1 trình bày
tổng quan hoạt động
Bảng 14.2 Giải thích các phần tử trong giao thức Kerberos V4

(a) Cấp ticket trao đổi chứng thực

Thông điệp (1) Client yêu cầu cấp ticket

IDC Cho AS biết nhận dạng của người dùng trên client C.
IDtgs Cho AS biết người dùng muốn truy xuất TGS.
TS1 Cho phép AS kiểm tra đồng hồ tại client đã được đồng bộ với AS.

Thông điệp (2) AS cấp ticket

Kc Sự mã hóa dựa trên mật khẩu của người dùng, cho phép AS và client.
kiểm tra mật khẩu và bảo vệ nội dung thông điệp (2).
Kc,tgs Bản sao của khóa phiên mà client truy xuất được do AS để cấp quyền
trao đổi giữa client và TGS mà không yêu cầu chúng phải chia xẻ một
khóa lâu dài.
IDtgs Xác nhận rằng ticket này dành cho TGS.
TS2 Thông báo cho người dùng về thời điểm mà ticket được cấp.
Lifetime2 Thông báo cho client về thời hạn sử dụng của ticket.
Tickettgs Ticket được sử dụng bởi client để truy xuất TGS.

(b) Cấp ticket trao đổi dịch vụ

Thông điệp (3) Client yêu cầu ticket dịch vụ

IDV Cho TGS biết người dùng yêu cầu truy xuất server V.
Tickettgs Bảo đảm với AS rằng người dùng này đã được chứng thực bởi AS.
Authenticatorc Sinh ra bởi client để xác nhận tính hợp lệ của ticket.

Thông điệp (4) TGS cấp ticket dịch vụ

Kc,tgs Khóa chia xẻ bởi C và TGS bảo vệ nội dung thông điệp (4).
Kc,v Bản sao khóa phiên mà client truy xuất được do TGS tạo ra để cấp phép
trao đổi an toàn giữa client và server mà không đòi hỏi chúng phải chia
xẻ khóa lâu dài.
IDv Xác nhận ticket dành cho server V.
TS4 Báo cho client thời điểm cấp ticket.
Ticketv Ticket cho client truy xuất server V.
Tickettgs Dùng lại được, tránh cho người dùng phải nhập lại mật khẩu.
Ktgs Ticket được mã hóa với khóa này để chống quấy rối, chia xẻ bởi AS và
TGS.
Kc,tgs Bản sao của khóa phiên truy xuất được bởi TGS dùng để mã hóa thẻ
chứng thực, liên quan tới chứng thực ticket.
IDC Biểu thị quyền sở hữu chính đáng đối với ticket.
ADC Chống lại việc sử dụng ticket từ một trạm làm việc khác với trạm yêu cầu
cấp ticket.
IDtgs Bảo đảm cho server rằng đã giải mã ticket đúng đắn.
TS2 Báo cho TGS về thời điểm ticket được cấp.
Lifetime2 Chống tấn công nhại sau khi ticket hết hạn.
Authenticatorc Bảo đảm cho TGS rằng ticket đệ trình đúng là ticket được cấp cho client
với thời hạn rất ngắn để chống tấn công nhại.
Kc,tgs Thẻ chứng thực được mã hóa với khóa này, được chia xẻ bởi client và
TGS, để chống quấy rối.
IDc Phải phù hợp với ID trong ticket để chứng thực ticket.
ADc Phải phù hợp với địa chỉ trong ticket để chứng thực ticket.
TS3 Báo cho TGS về thời điểm sinh ra thẻ chứng thực này.

(c) Trao đổi chứng thực Client/Server

Thông điệp (5) Client yêu cầu dịch vụ

Ticketv Bảo đảm với server rằng người dùng này đã được chứng thực bởi AS.
Authenticatorc Được sinh ra bởi client để xác nhận tính hợp lệ của ticket.

Thông điệp (6) Tùy ý chứng thực server với client

Kc,v Bảo đảm với C rằng thông điệp đến từ V.

TS5 + 1 Bảo đảm với C rằng đây không phải là nhại.
Ticketv Sử dụng lại được để client không cần thiết phải yêu cầu một ticket mới từ
TGS để truy xuất tới cùng một server.
Kv Ticket được mã hóa với khóa này. Chỉ TGS và server biết, để chống
quấy rối.
Kc,v Bản sao khóa phiên mà client truy xuất được, được sử dụng để mã hóa
thẻ chứng thực nhằm chứng thực ticket.
IDC
Biểu thị quyền sở hữu đầy đủ với ticket.
ADc
Chống lại việc sử dụng ticket từ một trạm làm việc khác với trạm yêu cầu
cấp ticket.
IDv
Bảo đảm cho server rằng đã giải mã ticket đúng đắn.
TS4
Báo cho server thời điểm ticket được cấp.
Lifetime4
Chống tấn công nhại sau khi ticket hết hạn.
Authenticatorc
Bảo đảm cho TGS rằng ticket đệ trình đúng là ticket được cấp cho client
với thời hạn rất ngắn để chống tấn công nhại.
Kc,v
Thẻ chứng thực được mã hóa với khóa này, chỉ client và server biết, để
chống quấy rối.
IDC
Phải phù hợp với ID trong ticket để chứng thực ticket.
ADc
Phải phù hợp với địa chỉ trong ticket để chứng thực ticket.
TS5 Thông báo cho server về thời điểm thẻ chứng thực này được tạo ra.

Hình 14.1 Kerberos tổng quát

Miền Kerberos và đa Kerberos

Một môi trường dịch vụ Kerberos đầy đủ gồm một server Kerberos, các client, và các server
ứng dụng AS đòi hỏi như sau:
1. Server Kerberos phải có ID của người dùng và mã hash của mật khẩu của tất cả người
dùng trong vùng quản lý của nó. Tất cả người dùng đều phải đăng ký với server
Kerberos.
2. Server Kerberos phải chia xẻ mật khóa với từng server. Tất cả server phải đăng ký với
server Kerberos.

Một môi trường như thế được gọi là miền Kerberos (realm). Khái niệm về realm có thể trình
bày như sau. Một miền Kerberos là một tập nút được quản lý, và cùng chia xẻ một cơ sở dữ liệu
Kerberos. Cơ sở dữ liệu Kerberos được lưu trữ trong hệ thống máy tính master Kerberos, nó được
bảo vệ trong một hệ thống an ninh gồm con người và các phương tiện cần thiết. Cũng có thể các bản
sao chỉ đọc của cơ sở dữ liệu Kerberos được lưu trữ trong các hệ thống máy tính Kerberos khác. Tuy
nhiên, tất cả các thay đổi nội dung cơ sở dữ liệu đều phải tạo trực tiếp trên máy master. Thay đổi
hoặc truy xuất nội dung cơ sở dữ liệu Kerberos đòi hỏi phải có mật khẩu master Kerberos. Một khái
niệm có liên quan mật thiết đó là chủ Kerberos, là một dịch vụ hay người dùng được phép biết nội
dung máy Kerberos. Mỗi chủ Kerberos đều phải có tên. Tên chủ Kerberos gồm ba phần: tên người
dùng hoặc dịch vụ, một tên tham chiếu và một tên realm.
Các mạng theo mô hình client/server của các tổ chức hành chính khác nhau thường thiết lập
các miền riêng. Nghĩa là, các tổ chức này thường không tự tuân thủ các nguyên tắc hành chính để
người dùng và các server của họ phải đăng ký với một server Kerberos nằm ở đâu đó. Tuy nhiên,
người dùng trong một miền có thể cần được truy xuất tới các server miền khác, hoặc là các server
mong được cung cấp dịch vụ cho người dùng không chỉ thuộc miền nó quản lý. Điều đó tất yếu dẫn
đến sự cần thiết phải chứng thực.
Kerberos cung cấp một cơ chế cho phép chứng thực liên miền. Để hai realm có thể cung cấp
chứng thực liên miền, một đòi hỏi thứ ba được thêm vào:
3. Server Kerberos trong mỗi realm tham gia liên miền cần phải chia xẻ một mật khoá với
server thuộc realm khác. Hai server Kerberos phải đăng ký với nhau.
Hình thức này đòi hỏi rằng server Kerberos thuộc một miền phải tin tưởng server Kerberos
của miền kia trong qua trình chứng thực người dùng. Hơn nữa, các server tham gia của miền thứ hai
cũng phải tin tưởng server Kerberos server thuộc realm thứ nhất.
Với các quy tắc nền móng này, ta có thể mô tả cơ chế như sau (hình 14.2): Một người dùng
muốn truy cập dịch vụ trong một server thuộc realm khác cần đệ trình một ticket cho server đó.
Người dùng tuân theo thủ tục thường lệ để có quyền truy xuất tới TGS địa phương và xin ticket cấp-
ticket cho server phía xa để từ đó xin ticket cấp-dịch vụ của server trong vùng của TGS xa.
 Hình 14.2 Yêu cầu truy xuất dịch vụ từ một Realm khác

Chi tiết trao đổi được minh họa trong hình 14.2 như sau (hãy so sánh với bảng 14.1):
(1) C → AS: IDc||IDtgs||TS1
(2) AS → C: E(Kc, [Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])
(3) C → TGS: IDtgsrem||Tickettgs||Authenticatorc
(4) TGS → C: E(Kc,tgs, [Kc,tgsrem||IDtgsrem||TS4||Tickettgsrem])
(5) C → TGSrem: IDvrem||Tickettgsrem||Authenticatorc
(6) TGSrem → C: E(Kc,tgsrem, [Kc,vrem||IDvrem||TS6||Ticketvrem])
(7) C →Vrem: Ticketvrem||Authenticatorc
Ticket trình trước server xa (V rem) thể hiện realm đã chứng thực cho người dùng. Server xa
tuỳ ý chọn có hoặc không phục vụ yêu cầu tữ xa này.
 Một vấn đề đặt ra cho hình thức vừa rồi là nó không thể mở rộng ra nhiều realm. Nếu có N
realm, thì cần phải có N(N − 1)/2 cuộc trao đổi khoá mật khoá, cho nên mỗi server Kerberos của
realm cần phải liên kết được với tất cả server Kerberos của N – 1 realm khác.

14.1.3 Kerberos phiên bản 5

Kerberos Version 5 được miêu tả tỷ mỷ trong RFC 1510 bao gồm nhiều cải tiến so với phiên
bản 4 [KOHL94]. Để bắt đầu, chúng ta khái quát về các thay đổi từ phiên bản 4 lên phiên bản 5, sau
đó nghiên cứu phiên bản 5.

Khác biệt giữa phiên bản 4 và 5

Phiên bản 5 chủ yếu nhằm vào việc giải quyết các thiếu sót, hạn chế của phiên bản 4 gồm hai
lĩnh vực: các hạn chế về môi trường và sự lệ thuộc kỹ thuật. Chúng ta tóm tắt các cải tiến theo từng
lĩnh vực [KOHL94].
Kerberos Version 4 được phát triển để sử dụng trong môi trường dự án Athena, vì thế, nó
không nhằm vào tính đa chức năng như cần thiết. Điều này dẫn tới các thiếu sót liên quan đến môi
trường:
• Phụ thuộc hệ thống mã hoá: Phiên bản 4 đòi hỏi sử dụng DES. Điều này ẩn chứa những
hạn chế vốn có của DES cùng những hoài nghi về sức mạnh của DES. Trong phiên bản 5,
ciphertext được gắn thẻ nhận diện kiểu mã hoá, cho nên dùng hình thức mã hoá nào cũng
được. Các khoá mã hoá được gắn thẻ bằng kiểu và chiều dài, cho phép cùng một khoá có
thể sử dụng được với các thuật toán khác nhau, chấp nhận các chỉ định kỹ thuật của nhiều
kiểu loại thuật toán mã hoá.
• Phụ thuộc giao thức Internet: Phiên bản 4 cần sử dụng các địa chỉ giao thức Internet
Protocol (IP). Các kiểu địa chỉ khác như địa chỉ mạng ISO không được hỗ trợ. Phiên bản
5 được gắn thẻ bằng kiểu và chiều dài, cho phép dùng bất cứ loại địa chỉ mạng và chiều
dài nào.
• Trình tự byte trong thông điệp: Trong phiên bản 4, người gửi thông điệp phải có cách
thông báo ngay trong thông điệp để thể hiện kiểu trình tự sắp xếp địa chỉ là byte thấp nhất
đi trước hay byte cao nhất đi trước. Kỹ thuật này làm việc tốt nhưng lại không tuân theo
quy ước. Trong phiên bản 5, tất cả các cấu trúc thông điệp đều được định nghĩa bởi
Abstract Syntax Notation One (ASN.1) và Basic Encoding Rules (BER), nó cung cấp
một trình tự byte không mơ hồ.
• Thời gian sống của Ticket: Các giá trị Lifetime trong phiên bản 4 được ghi bằng một số
8-bit tính theo đơn vị năm phút. Do đó, thời gian sống tối đa có thể biểu biễn là 28 × 5 =
1280 phút, tức là chỉ khoảng 21 giờ. Con số này không thoả đáng trong một số ứng dụng
(ví dụ, một phép mô phỏng dài mà nó cần chứng thực hợp lệ liên tục của Kerberos trong
suốt thời gian thi hành dài). Trong phiên bản 5, các ticket gồm chứa các giá trị bắt đầu và
hết hạn một cách tường minh, cho phép ticket có thời gian sống tuỳ ý.
 • Chuyển tiếp chứng thực: Phiên bản 4 không cho phép chuyển tiếp một client sang host
khác. Tính năng chuyển tiếp này hữu ích ở chỗ server đã chứng thực cho client này sẽ
thay mặt client truy xuất tới các server khác. Ví dụ, một client gửi một yêu cầu tới một
server quản lý in ấn; server này truy xuất tới một server quản lý file bằng quyền truy xuất
của client. Phiên bản 4 không cung cấp kiểu chuyển tiếp chứng thực này, còn phiên bản 5
lại hỗ trợ nó.
• Chứng thực liên miền: Trong phiên bản 4, tính năng phối hợp giữa N miền (realm) đòi
hỏi quan hệ bậc N2 giữa các máy chủ Kerberos, như đã mô tả ở trước. Phiên bản 5 hỗ trợ
phương thức mà nó đòi hỏi ít quan hệ hơn.
Bên cạnh những hạn chế môi trường, còn có tính lệ thuộc kỹ thuật trong phiên bản 4. Hầu hết
các lệ thuộc này được mô tả trong [BELL90], và phiên bản 5 nỗ lực loại trừ các hạn chế này. Các hạn
chế lệ thuộc kỹ thuật bao gồm:
• Mã hoá kép: Quan sát bảng 14.1, các thông điệp (2) và (4), các ticket cung cấp cho
client được mã hoá hai lần, lần thứ nhất với mật khoá của server đích và lần thứ hai với
mật khoá mà client cũng biết. Lần mã hoá thứ hai này là không cần thiết, lãng phí tài
nguyên tính toán.
• Mã hoá PCBC: Việc mã hoá trong phiên bản 4 dùng một chế độ DES không chuẩn, gọi
là dây chuyền mật mã khối truyền lan (PCBC) (Phụ lục 14A). Chế độ này đã từng cho thấy sự
yếu kém trong việc chống lại một kiểu tấn công thay đổi thứ tự các khối ciphertext
[KOHL89]. PCBC được xây dựng với mục đích làm một thành phần của hoạt động mã
hoá cung cấp phép kiểm tra tính toàn vẹn. Phiên bản 5 cung cấp các cơ chế kiểm tra tính
toàn vẹn một cách cụ thể với chế độ hoạt động CBC chuẩn. Cụ thể là, một mã checksum
hay mã hash được đính kèm vào thông điệp trước khi nó được cung cấp cho CBC để mã
hoá.
• Các khoá phiên: Mỗi ticket bao gồm một khoá phiên được dùng bởi client để mã hoá mã
chứng thực gửi tới dịch vụ gắn liền với ticket đó. Thêm nữa, khoá phiên còn được client
dùng ngay sau đó để bảo về các thông điệp truyền đi trong phiên. Tuy nhiên, do cùng một
ticket được dùng nhiều lần để lấy dịch vụ từ một server nào đó, sẽ tồn tại nguy cơ khi kẻ
nào đó nhại lại các thông điệp từ phiên cũ tới client hoặc server. Trong phiên bản 5, rất có
khả năng cho một người dùng và server lấy một khoá phiên con, mà nó chỉ được dùng
cho một kết nối. Truy xuất mới của client sẽ lại dùng một khoá phiên con khác.
• Các tấn công mật khẩu: Cả hai phiên bản đều phải chịu các tấn công vào mật khẩu.
Thông điệp từ AS tới client gồm các thông tin được mã hoá bằng một khoá lấy từ mật
khẩu của client (Phụ lục 14A mô tả cách thức ánh xạ các mật khẩu thành các khoá mã
hoá). Đối phương có thể bắt thông điệp này và cố gắng giải mã nó bằng cách thử các mật
khẩu khác nhau. Nếu kết quả từ một phép thử là đúng đắn thì đối phương đã khám phá
được mật khẩu của client và sau đó sử dụng để chiếm chứng thực của server Kerberos.
Đây là kiểu tấn công giống như được mô tả trong Chương 18.
 Phiên bản 5 cung cấp một cơ chế gọi là chứng thực trước, làm tấn công mật khẩu trở nên
khó khăn hơn nhưng cũng không ngăn ngừa được.

Đối thoại chứng thực trong phiên bản 5

Bảng 14.3 tóm tắt quá trình đối thoại trong phiên bản 5. Đây là cách trình bày tốt nhất để so
sánh với phiên bản 4 (bảng 14.1).
Trước hết, xét việc trao đổi dịch vụ chứng thực. Thông điệp (1) là một yêu cầu của client lấy
ticket-cấp ticket. Giống như trước, nó gồm của người dùng và TGS. Một số thành phần được thêm
mới như sau:
• Realm: Thể hiện miền của người dùng.
• Options: Sử dụng để yêu cầu các cờ cụ thể được lập khi ticket được gửi về.
 Times: Client dùng nó để yêu cầu trong nội dung ticket:
 from: Thời gian bắt đầu hiệu lực của ticket .
 till: Thời gian hết hạn của ticket.
• rtime: Thời gian đề nghị được gia hạn thêm.
• Nonce: Một giá trị ngẫu nhiên để đưa vào trong thông điệp (2) nhằm chống tấn công
nhại.
Thông điệp (2) gửi lại một ticket-cấp ticket, thông tin nhận dạng client và một khối đã mã
hoá bằng khoá lấy từ mật khẩu người dùng. Khối này bao gồm khoá phiên để dùng giữa client và
TGS, các thời gian như đã yêu cầu bằng thông điệp (1), giá trị nonce lấy từ thông điệp (1) và thông
tin nhận dạng TGS. Bản thân ticket cũng bao gồm khoá phiên, thông tin nhận dạng client, các giá trị
thời gian yêu cầu, và các cờ phản ánh tình trạng của ticket cùng các lựa chọn yêu cầu. Các cờ này
cho một chức năng mới và hữu ích đối với phiên bản 5. Tạm thời chúng ta chưa bàn tới các cờ này,
chỉ tập trung bàn cấu trúc tổng thể của giao thức phiên bản 5.
Bây giờ chúng ta sẽ so sánh quá trình trao đổi ticket-cấp dịch vụ giữa phiên bản 4 và 5. Ta
thấy rằng thông điệp (3) của cả hai phiên bản đều bao hàm một mã chứng thực, một ticket và tên dịch
vụ yêu cầu. Thêm nữa, trong phiên bản 5 còn gồm cả các thời gian yêu cầu, các lựa chọn và một
nonce, tất cả chúng mang chức năng giống như thông điệp (1). Mã chứng thực mang bản chất giống
như phiên bản 4.
Thông điệp (4) có cấu trúc giống như thông điệp (2), nó gửi về một ticket cùng với thông tin
mà client cần có, khối thông tin này được mã hoá bằng khoá phiên mà giờ đây đã được chia xẻ giữa
clien và TGS.
Sau cùng, đối với trao đổi chứng thực client/server, một số đặc điểm mới xuất hiện trong
phiên bản 5. Trong thông điệp (5), client có thể yêu cầu chứng thực lẫn nhau như một lựa chọn. Mã
chứng thực gồm các đặc điểm mới sau đây:
 Bảng 14.3 Tóm tắt quá trình trao đổi
thông điệp trong Kerberos phiên bản 5

(a) Trao đổi dịch vụ chứng thực để lấy ticket-cấp ticket

(1) C → AS Options||IDc||Realmc||IDtgs||Times||Nonce1

(2) AS → C Realmc||IDC||Tickettgs||E(Kc, [Kc,tgs||Times||Nonce1||Realmtgs||IDtgs])

Tickettgs = E(Ktgs, [Flags||Kc,tgs||Realmc||IDc||ADc||Times])

(b) Trao đổi dịch vụ cấp Ticket để lấy ticket-cấp dịch vụ

(3) C → TGS Options||IDv||Times||||Nonce2||Tickettgs||Authenticatorc

(4) TGS → C Realmc||IDc||Ticketv||E(Kc,tgs, [Kc,v||Times||Nonce2||Realmv||IDv])

Tickettgs = E(Ktgs, [Flags||KC,tgs||Realmc||IDC||ADC||Times])
Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDC||ADc||Times])
Authenticatorc = E(Kc,tgs, [IDC||Realmc||TS1])

(c) Trao đổi chứng thực Client/Server để nhận dịch vụ

(5) C → V Options||Ticketv||Authenticatorc

(6) V → C EKc,v[TS2||Subkey||Seq#]
Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDC||ADC||Times])
Authenticatorc = E(Kc,v,[IDC||Realmc||TS2||Subkey||Seq#])

• Subkey: Lựa chọn của client về một khoá mã hoá dùng để bảo vệ trong phiên làm việc.
Nếu bỏ qua trường này, thì khoá phiên lấy từ ticket (Kc,v) được sử dụng.
• Sequence number: Một trường tuỳ ý chỉ ra số thứ tự bắt đầu dùng bởi server đối với các
thông điệp gửi tới client trong phiên này. Các thông điệp được đánh số tuần tự để tránh
tấn công nhại.
Nếu đòi hỏi chứng thực lẫn nhau, thì server đáp trả bằng thông điệp (6). Thông điệp này bao
gồm nhãn thời gian lấy từ mã chứng thực. Lưu ý rằng trong phiên bản 4, nhãn thời gian được tăng
lên 1. Điều này không cần thiết trong phiên bản 5 bởi vì bản chất tự nhiên của dạng thức các thông
điệp không cho phép đối phương tạo được thông điệp (6) mà không nắm được khoá mã hoá. Trường
khoá con subkey, nếu có mặt, thì nó sẽ có hiệu lực thay cho trường khoá con trong thông điệp (5),
nếu như trường này có mặt. Trường số thứ tự tuỳ chọn chỉ ra số thứ tự bắt đầu dùng bởi client.

14.1.3.3 Các cờ Ticket

Trường flags được dùng trong phiên bản 5 hỗ trợ thêm chức năng mở rộng so với phiên bản
4. Bảng 14.4 tóm tắt các cờ mà chúng có thể được dùng trong một ticket.
 Cờ INITIAL biểu lộ rằng ticket này được một AS phát ra chứ không phải của một TGS. Khi
một client yêu cầu một ticket-cấp dịch vụ từ TGS, nó trình một ticket-cấp ticket đã lấy được từ AS.
Trong phiên bản 4, đây là cách duy nhất để xin ticket-cấp dịch vụ. Phiên bản 5 cung cấp thêm khả
năng lấy ticket-cấp dịch vụ trực tiếp cho client ngay từ AS. Sự tiện lợi của khả năng này như sau:
Một server, chẳng hạn như server đổi mật khẩu, có thể muốn biết mật khẩu client đã kiểm tra gần đây
là gì.
Bảng 14.4 Các cờ trong Kerberos phiên bản 5

INITIAL Ticket sinh từ giao thức AS, nó không dựa vào một ticket-cấp ticket.

PRE-AUTHENT Trong chứng thực ban đầu, client được chứng thực bởi KDC trước khi
được cấp ticket.

HW-AUTHENT Giao thức dùng trong chứng thực ban đầu dùng phần cứng mong được sử
dụng độc quyền chỉ bởi tên client đã chỉ ra.

RENEWABLE Cho TGS biết rằng ticket này có thể dùng để xin thay thế một ticket sẽ hết
hạn vào một ngày sau.

MAY-POSTDATE Cho TGS biết rằng có thể một ticket được phát ra có ngày tháng chậm hơn
(postdated) dựa trên ticket-cấp ticket này.

POSTDATED Biểu thị rằng ticket này đã được đề ngày tháng muộn; server cuối có thể
phải xác minh trường thời gian chứng thực authtime để biết chứng thực ban
đầu đã xảy ra khi nào.

INVALID Ticket này chưa được hợp thức và nó phải được KDC hợp thức hoá trước
khi dùng.

PROXIABLE Cho TGS biết rằng một ticket-cấp dịch vụ mới mang địa chỉ mạng khác có
thể đã được cấp dựa trên ticket này.

PROXY Biểu thị rằng ticket này là của một proxy.

FORWARDABLE Cho TGS biết rằng một ticket-cấp dịnh vụ mới với một địa chỉ mạng khác
có thể đã được cấp dựa trên ticket-cấp ticket này.

FORWARDED Biểu thị rằng ticket này hoặc đã được chuyển tiếp hoặc được phát ra dựa
trên sự chứng thực đòi hỏi một ticket-cấp ticket chuyển tiếp.

Cờ PRE-AUTHENT nếu được lập, nó báo hiệu rằng khi AS nhận được yêu cầu ban đầu,
thông điệp (1), nó chứng thực cho client trước khi cấp một ticket. Dạng thức của việc chứng thực
trước này chưa được chỉ ra cụ thể. Ví dụ, việc thi hành chứng thực trước trong phiên bản 5 ở MIT
ngầm định là nhãn thời gian được mã hoá. Khi một người dùng muốn lấy ticket, nó phải gửi tới AS
một khối chứng thực trước, nó chứa số ngẫu nhiên, một số hiệu phiên bản và một nhãn thời gian,
được mã hoá bằng khoá lấy từ mật khẩu người dùng. AS giải mã khối này nhưng sẽ không gửi lại
một ticket-cấp ticket trừ khi nhãn thời gian trong khối chứng thực trước vẫn còn trong phạm vi khống
chế được (khoảng thời gian do sai lệch đồng hồ và các mức trễ của mạng). Một khả năng khác là
dùng một thẻ thông minh tạo ra liên tiếp các thay đổi với mật khẩu đã bao hàm trong các thông điệp
chứng thực trước. Các mật khẩu được sinh ra bởi các thẻ này có thể dựa vào mật khẩu của người
dùng nhưng được thẻ biến đổi đi sao cho trở thành các mật khẩu bất kỳ. Cách này chống lại một kiếu
tấn công dựa vào việc đoán các mật khẩu dễ. Nếu một thẻ thông minh hay một thiết bị như thế được
sử dụng, nó sẽ được báo bằng cờ HW-AUTHENT.
Khi một ticket có thời gian sống dài, có khả năng bị lấy trộm và dùng trái phép bởi một kẻ
nào đó. Nếu thời gian sống ngắn nguy cơ sẽ ít hơn nhưng đặt gánh nặng cho tác vụ xin và cấp phát
các ticket mới. Đối với một ticket-cấp ticket, client có thể phải lưu trữ mật khoá người dùng mà đó rõ
ràng là một khả năng rủi ro, hoặc phải liên tục đòi mật khẩu người dùng. Cách phù hợp hơn trong
việc sử dụng các ticket là chúng có thể được phép thay mới hoặc gia hạn. Một ticket được lập cờ
RENEWABLE bao gồm hai loại thời gian hết hạn: một dùng để khẳng định thời gian hết hạn ticket
này và thời gian kia là thời hạn cuối cùng của các ticket gia hạn hoặc xin mới dựa trên ticket này.
Một client muốn gia hạn thì trình nó cho TGS để xin một thời hạn mới. Nếu thời hạn mới nằm trong
khoảng thời gian hạn chế cuối cùng thì TGS có thể cấp cho một ticket mới với thời hạn phiên làm
việc mới cùng một giá trị thời hạn sau cùng muộn hơn nữa. Ưu điểm của cơ chế này là ở chỗ TGS có
thể từ chối cấp một ticket nếu nó đã được báo cáo bị đánh cắp.
Client có thể yêu cầu TGS cung cấp một ticket-cấp ticket mang cờ MAYPOSTDATE. Sau đó
client này có thể dùng ticket để xin ticket có cờ POSTDATED và INVALID từ TGS. Rồi tiếp nữa,
client có thể đệ trình ticket có cờ POSTDATED để kích hoạt hiệu lực. Hình thức này rất có ích trong
khi thi hành một tập tin bó lệnh (batch) trong một thời gian dài của một server mà nó thường xuyên,
định kỳ xin ticket. Client có thể xin nhiều ticket cho phiên làm việc hiện tại mỗi lần xin, các ticket
này có các giá trị thời hạn dài dần ra. Ban đầu, trừ ticket đầu tiên, các ticket cùng xin khác đều chưa
được hợp thức hoá. Khi việc thi hành đi đến điểm giới hạn thời gian đầu tiên, client dùng ticket có
thời hạn hợp lệ phù hợp để tiếp tục công việc. Bằng phương pháp này, client không phải liên tục
dùng ticket-cấp ticket để xin ticket-cấp dịch vụ.
Trong phiên bản 5 một server có khả năng đóng vai trò như một proxy thay mặt client với
đầy đủ tính tin cậy và quyền hợp pháp của client để yêu cầu dịch vụ từ một server khác. Nếu một
client muốn được dùng cơ chế này, nó yêu cầu một ticket-cấp ticket bằng việc lập cờ PROXIABLE.
Khi ticket này được trình trước TGS, TGS cho phép cấp một ticket-cấp dịch vụ với một địa chỉ mạng
khác mang cờ PROXY. Một ứng dụng nếu nhận được một ticket như thế có thể tự nó quyết định
chấp nhận hay đòi hỏi thêm chứng thực (Tham khảo [NEUM93b]).
Khái niệm proxy là một trường hợp đặc biệt hữu ích của thủ tục chuyển tiếp. Nếu một ticket
được lập cờ FORWARDABLE, một TGS có thể cấp một ticket-cấp ticket mang một địa chỉ mạng
khác và cờ FORWARDED được lập. Ticket này sau đó được trình trước TGS xa. Tính năng này cho
phép một client có thể truy xuất tới một server thuộc miền khác mà không cần đòi hỏi mỗi server
Kerberos phải duy trì một mật khoá tương ứng với mỗi server Kerberos của mọi miền. Ví dụ, các
miền có thể được xây dựng theo cấu trúc trình tự của một đồ thị hình cây. Khi đó, một client có thể
theo các nút chung để chứng thực lên và lại lần lượt xuống theo nhánh dưới khác của đồ thị để đến
được realm đích. Mỗi bước lên hay xuống như thế đều cần chuyển tiếp một ticket-cấp ticket tới TGS
tiếp theo trên đường đi.