Рассмотрим получение билета, гарантирующего билет.

Рассмотрим протокол версии 5.

Получение билета, гарантирующего билет

C
AS: Options, IDC, RealmC, IDtgs, Times, Nonce1
AS
C: RealmC, IDC, Tickettgs, EKc [ KC,tgs, Times, Nonce1, Realmtgs, IDtgs]

Tickettgs = EKtgs [ Flags, KC,tgs, RealmC, IDC, ADC, Times]

Получение билета, гарантирующего сервис
C
TGS: Options, IDS, Times, Nonce2, Tickettgs, AuthenticatorC
TGS
C: RealmC, IDC, TicketS, EKc,tgs [ KC,S, Times Nonce2, RealmS, IDS]

Tickettgs = EKtgs [ Flags, KC,tgs, RealmC, IDC, ADC, Times]

TicketS = EKs [ Flags, KC,S, RealmC, IDC, ADC, Times]

AuthenticatorC = EKc,tgs [ IDC, RealmC, TS1]

Получение сервиса
C
S: Options, TicketS, AuthenticatorC
S
C: EC, S [TS2, Subkey, Seq#]

TicketS = EKs [ Flags, KC,S, RealmC, IDC, ADC, Times]

AuthenticatorC = EKc, s [ IDC, RealmC, TS1, Subkey, Seq#]

Рассмотрим получение билета, гарантирующего билет. Сообщение (1) является запросом клиентского модуля на билет, гарантирующий билет. Как и прежде, оно включает идентификаторы пользователя и TGS. Добавлены следующие новые элементы:

Realm: определяет область пользователя.
Options: используется для запроса основных флагов, которые должны быть установлены в возвращаемом билете.
Times: используется клиентом для запроса следующих установок времени в билете:
- from: требуемое начальное время для запрашиваемого билета.
- till: требуемое время окончания для запрашиваемого билета.
- rtime: требуемое время обновления.
Nonce: случайное число, повторяемое в сообщении 2, гарантирующее, что ответ своевременный и повтором оппонента не является.

Сообщение (2) возвращает билет, гарантирующий билет, который содержит информацию для клиента, и блок, зашифрованный с использованием ключа шифрования, основанного на пользовательском пароле. Этот блок включает ключ сессии, который будет использоваться между клиентом и TGS, время, указанное в сообщении 1, nonce из сообщения 1 и определяемую TGS информацию. Сам билет включает ключ сессии, идентифицирующую информацию клиента, требуемое значение времени и флаги, которые отражают статус данного билета и требуемые опции.

Эти флаги вводят важные новые функциональности в версии 5.

Сравним получение билета, гарантирующего сервис, в версиях 4 и 5. Сообщение (3) в обеих версиях включает аутентификатор, билет и имя требуемого сервиса. Дополнительно версия 5 включает требуемое время, опции билета и nonce. Аутентификатор тот же самый, что используется в версии 4.

Сообщение (4) имеет ту же структуру, что и сообщение (2); оно возвращает билет и информацию, необходимую клиентскому модулю, зашифрованную ключом сессии, разделяемым к настоящему времени клиентским модулем и TGS.

Наконец, для получения сервиса в версии 5 появилось несколько новых возможностей. В сообщении (5) клиентский модуль может запросить опцию, которая требует взаимной аутентификации. Аутентификатор включает несколько следующих новых полей:

Подключ: выбор клиентом ключа шифрования, который используется для защиты данной конкретной прикладной сессии. Если данное поле опущено, используется ключ сессии из билета KC, S.
Sequence number: дополнительное поле, которое определяет начальный номер последовательности, используемый сервером в сообщениях, посылаемых клиенту в течение данной сессии. Сообщения могут быть пронумерованы для предотвращения replay-атак.

Если требуется взаимная аутентификация, сервер отвечает сообщением (6). Это сообщение включает отметку времени из аутентификатора. Заметим, что в версии 4 отметка времени возрастала на единицу. Это не является необходимым в версии 5, так как формат сообщения такой, что злоумышленник не может создать сообщение (6), не зная соответствующих ключей шифрования. Поле подключа, если оно присутствует, переопределяет поле подключа, если оно присутствует, в сообщении (5). Дополнительное поле номера последовательности определяет стартовый номер последовательности, используемый клиентом.

Содержание раздела