Безопасное сетевое взаимодействие (часть 1)

Аутентификационный протокол версии 5

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

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

1. C -> AS: Options, ID_C, Realm_C, ID_tgs, Times, Nonce₁
2. AS -> C: Realm_C, ID_C, Ticket_tgs, E_Kc [ K_C,tgs, Times, Nonce₁, Realm_tgs, ID_tgs]

   Ticket_tgs = E_Ktgs [ Flags, K_C,tgs, Realm_C, ID_C, AD_C, Times]

   Получение билета, гарантирующего сервис
3. C -> TGS: Options, ID_S, Times, Nonce₂, Ticket_tgs, Authenticator_C
4. TGS -> C: Realm_C, ID_C, Ticket_S, E_Kc,tgs [ K_C,S, Times, Nonce₂, Realm_S, ID_S]

   Ticket_tgs = E_Ktgs [ Flags, K_C,tgs, Realm_C, ID_C, AD_C, Times]

   Ticket_S = E_Ks [ Flags, K_C,S, Realm_C, ID_C, AD_C, Times]

   Authenticator_C = E_Kc,tgs [ ID_C, Realm_C, TS₁]

   Получение сервиса
5. C -> S: Options, Ticket_S, Authenticator_C
6. S -> C: E_{C, S} [TS₂, Subkey, Seq#]

   Ticket_S = E_Ks [ Flags, K_C,S, Realm_C, ID_C, AD_C, Times]

   Authenticator_C = E_{Kc, s} [ ID_C, Realm_C, TS₁, 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) клиентский модуль может запросить опцию, которая требует взаимной аутентификации. Аутентификатор включает несколько следующих новых полей:

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

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