GSSAPI: петля контекста безопасности

Question

Примеры Oracle GSSAPI Java и различные RFC SPNEGO / GSSAPI IETF указывают, что как инициатор GSS (клиент), так и акцептор (сервер) должны иметь цикл для установления контекста безопасности и что клиенту может потребоваться сделать несколько проходовс токенами GSS до установления контекста безопасности.

• Пример Oracle GSSAPI: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/BasicClientServer.html

• Структура цикла согласования универсальной службы безопасности (GSS):https://tools.ietf.org/html/rfc7546

• Проверка подлинности Kerberos на основе SPNEGO и HTTP-аутентификация NTLM в Microsoft Windows: https://tools.ietf.org/html/rfc4559

Например, RFC4559 приводит следующий пример:

Пропуск 1: Сбой, поскольку запрос не имеет токена:

C: GET dir / index.html

S: HTTP / 1.1 401 Несанкционированный

S: WWW-Authenticate: переговоры

Пропуск 2: Сбой, но запрос имеет токен

C: GET dir / index.html

C: Авторизация: переговоры a87421000492aa874209af8bc028

S: HTTP / 1.1401 Несанкционированный

S: WWW-Аутентификация: переговоры 749efa7b23409c20b92356

Пропуск 3: Успех

C: GET dir / index.html

C: Авторизация: согласование 89a8742aa8729a8b028

S: HTTP / 1.1 200 Успех

S: WWW-Authenticate: согласование ade0234568a4209af8bc0280289eca

Здесь устанавливается контекст безопасности и, таким образом,запрос аутентифицирован на третьем проходе. то есть при втором проходе от клиента (C) к серверу (S) с токеном.

Вопрос 1: Почему перед защитой может потребоваться несколько проходов от инициатора к получателю с токенамиконтекст успешно установлен? Почему прохождение 2 выше не удалось, а прохождение 3 - успешно? Меняется ли что-либо на инициаторе или на акцепторе между этими двумя проходами?

Вопрос 2: Мой инстинкт заключается в том, что и петли инициатора, и акцептора должны иметь защиту от бесконечного зацикливания. Например, инициатор может прервать работу, если контекст не установлен x попытками. Существуют ли какие-либо практические правила / метрики для количества проходов, которые можно разумно ожидать для установления контекста безопасности? например, если контекст безопасности не был установлен 5-м проходом -> abort.

Вопрос 3: В примерах Oracle GSSAPI клиент и сервер обмениваются данными через сокеты. Сервер создает объект GSSContext, который выделен одному клиенту, сохраняется до закрытия сервера и, таким образом, доступен для нескольких проходов для установления контекста безопасности.

Но как это может работать для Http RESTful WebServerс несколькими клиентами? Я предполагаю, что:

a) каждый проход запроса для установления контекста безопасности должен выполняться для одного и того же объекта GSSContext (а не для нового экземпляра GSSContext).

b)Http-сервер должен устанавливать новый экземпляр GSSContext для каждого нового клиентского запроса. (т. е. объект GSSContext не должен использоваться совместно / повторно для нескольких клиентов / запросов).

Если мои предположения верны, сервер должен различать:

i) следующий проход для существующего запросадля которого контекст безопасности еще не установлен. -> следует использовать существующий объект и цикл GSSContext.

ii) первый проход совершенно нового запроса (либо от того же, либо от другого клиента). -> должны использоваться новый объект и цикл GSSContext.

Answer 1

Используя Negotiate в качестве примера протокола, полезно рассмотреть, как он работает.

1. Сервер указывает клиенту, что он может поддерживать согласование.
2. Клиент соглашается и делает вывод о том, что сервер может поддерживать.
3. Клиент создает токен на основе того, что, по его мнению, сервер поддерживает (например, Kerberos), а затем создает список других возможныхтипы токенов (например, NTLM).
4. Клиент отправляет на сервер и токен, и список.
5. Сервер либо принимает исходный токен, либо решает выбрать что-то еще из списка.
6. Сервер указывает клиенту, что он хочет что-то еще.
7. Затем клиент отправляет другой токен предпочтительного типа.
8. Сервер принимает или отклоняет клиент и соответствующим образом отвечает клиенту. .

Для этого требуется до трех циклов и может произойти сбой или полное выполнение после одного. Другие протоколы могут делать все, что хотят.

Возможно, вы захотите отследить количество обращений и убить его после произвольно большого числа. Требуемые ресурсы не так высоки, но под нагрузкой это может привести к истощению системы.