ГОСТ Р ИСО/МЭК 17826-2015
IETF RFC 2616 и IETF RFC 2617 определяют требования к аутентификации HTTP, которая обычно начина
ется запросом HTTP от клиента, например. <GET Request-URI> (где Request-URI - запрошенный ресурс). Если
запрос клиента не включает заголовок «Authorization», и авторизация обязательна, сервер отвечает кодом 401
Unauthorized и строкой заголовка WWW-Authenticate.
Клиент HTTP должен затем ответить с использованием подходящей строки заголовка Authorization в следу ющем
запросе. Формат строк заголовка WWW-Authenticate и Authorization зависит от типа необходимой аутенти
фикации (базовой или дайджест). Если аутентификация пройдена успешно. HTTP сервер возвращает код 200 ОК.
Базовая аутентификация включает отсыпку имени пользователя и пароля в открытом виде, и должна поэто
му использоваться только в защищенной сети или в сочетании с механизмом, обеспечивающим конфиденциаль
ность. например. TLS (см. А.4). Дайджест-аутентификация отсылает безопасный хеш пользовательского имени и
пароля (и другой необходимой информации, включая контрольное слово), так что пароль не показывается. Ответ
401 Unauthorized не должен включать выбор аутентификации.
Аутентификация клиента на сервере CDMI основана на сервисе аутентификации (локальном и’или внеш
нем). Могут поддерживаться различные схемы аутентификации, включая узловые. Kerberos. PKI и другие, рассмо
трение сервисов аутентификации находится за рамками настоящего стандарта.
А.4 HTTP над TLS (HTTPS)
CDMI может также включать механизм для обеспечения безопасности передачи данных no HTTP, когда дан
ные. пересылаемые между сервером и клиентом предварительно шифруются. Эта безопасностьдостигается пере
дачей HTTP поверх TLS (т.е. HTTPS); URI безопасного соединения начинается с https:// вместо http;//. Важно,
что клиент CDMI взаимодействует с сервером CDMI по HTTPS через порт TCP 443 (порт TCP 80 используется
для HTTP). Приложение А.5 описывает важные детали, связанные с TLS.
Если TLS используется для обеспечения безопасности HTTP, клиент и сервер обычно проводят аутентифи
кацию объектов. Особенности этой процедуры зависят от использованной системы шифрования, которая указыва ет
на алгоритм шифрования и алгоритм построения дайджеста для использования при TLS соединении. В широко
распространенном сценарии в качестве основы однонаправленной аутентификации объекта использованются сер
тификаты на стороне сервера, которым клиент доверяет. Допускается как отсутствие аутентификация (например,
анонимная аутентификация), так и наоборот, может требоваться взаимная аутентификация клиента и сервера.
А.5 Безопасность уровня транспорта (TLS)
Серверы CDMI должны реализовать протокол TLS; однако, его использование клиентами опционально. TLS
1.0 должен быть реализован согласно RFC 2246. TLS 1.1 описан в RFC 4346, a TLS 1.2-8 RFC 5246.
Первичная задача протокола TLS - предоставить защиту информации и целостность данных при взаимо
действии двух приложений. TLS позволяет клиент-серверным приложениям осуществлять обмен даными. избегая
перехвата данных, несанкционированного вмешательства или подделки сообщений. TLS располагается поверх
надежного протокола транспортного уровня (например. TCP) и используется для передачи сообщений различных
протоколов более высокого уровня (например. HTTP).
TLS предоставляет аутентификацию оконечных точек и безопасный обмен данными в сети посредством ис
пользования криптографии. Обычно лишь сервер проходит аутентификацию, а клиент нет: таким образом, конеч
ный пользователь (человек или приложение) уверен в том. с чем установлено соединение. Взаимная аутентифика
ция требует, с малочиспенными исключениями, предоставления клиентом цифровою сертификата.
TLS включает три основные фазы:
- согласование сторонами поддерживаемого алгоритма;
- обмен ключами и аутентификация:
- симметричное шифрование и аутентификация сообщений.
Во время первой фазы клиент и сервер обмениваются сведеними о поддерживаемых криптосистемах (см.
А.5.1), определяя, какой шифр должен быть использован, схемы обмена ключами и алгоритмы аутентификации,
а также алгоритмы аутентификации сообщений (MAC). Обмен ключами и аутентификация, как правило, пред
ставлены алгоритмами шифрования открытым ключом. MAC конструируются из алгоритмов криптографических
хэш-функций.
А.5.1 Криптосистемы
TLS объединяет алгоритмы создание ключа, конфиденциальности, подписи и хэширования в криптосистему.
Каждой криптосистеме ставится в соответствие 16-битное число, индекс криптосистемы.
П р и м е р - Согласование ключей RSA. RSA подпись, конфиденциальност ь посредст вом Advanced
Encryption Standard (AES) в режиме Cipher Block Chaining (CBC), и алгоритм хэш ирования Secure Hash
Algorithm (SHA-1) соответствуют в TLS шестнадцатеричному числу {OxOOOF}.
TLS сессия всегда начинается клиентом, который начинает обмен пакетами шифрования, отсылая сообще
ние установления соединения, содержащее набор поддерживаемых криптосистем (в виде их индексов). Сервер
отвечает сообщением, содержащим индекс криптосистемы, выбранной из списка клиента, или строкой «abort»
как
152