Архивное хранение
OCSP Responder может выбрать сохранение информации об отмене после истечения срока действительности сертификата. Дата, полученная путем вычитания сохраненного внутреннего значения из времени producedAt в ответе, определяется как дата архивации сертификата.
Приложения, которым требуется OCSP, должны использовать дату архивного хранения для получения доказательства того, что цифровая подпись была (или не была) надежна на момент, когда она была создана, даже если сертификат в настоящее время уже недействителен.
OCSP-серверы, которые предоставляют поддержку таких исторических ссылок, должны включать в ответы расширение данных archive cutoff. Если оно включено, то данное значение должно быть предоставлено как OCSP singleExtensions расширение, идентифицируемое id-pkix-ocsp-archive-cutoff и имеющее синтаксис GeneralizedTime.
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } ArchiveCutoff ::= GeneralizedTime
В качестве иллюстрации можно привести такой пример: для сервера, функционирующего с семилетним сохранением внутренней политики, если статус некоторого сертификата был создан в момент времени t1, значение для ArchiveCutoff в ответе будет (t1 - 7 лет).
ASN.1 спецификация для OCSP ответа
OCSP-ответ состоит, как минимум, из поля responseStatus, указывающего полученный статус запроса. Если значение responseStatus является одним из кодов ошибки, responseBytes не установлены.
OCSPResponse ::= SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } OCSPResponseStatus ::= ENUMERATED { successful (0), -- ответ содержит подтверждение -- действительности malformedRequest (1), --неправильно отформатированный запрос internalError (2), --внутренняя ошибка tryLater (3), --попытаться снова позднее --(4) не используется sigRequired (5), --запрос должен быть подписан unauthorized (6) --неавторизованный запрос }
Значение responseBytes состоит из OBJECT IDENTIFIER и синтаксиса ответа, определяющего, что OID представляется как OCTET STRING.
ResponseBytes ::= SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING }
Для основного OCSP отвечающего responceType будет id-pkix-ocsp-basic.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
OCSP отвечающие должны иметь возможность создавать ответы с типом id-pkix-ocsp-basic. Соответственно OCSP клиенты должны иметь возможность получать и обрабатывать ответы с типом id-pkix-ocsp-basic.
Значение ответа должно иметь DER-представление BasicOCSPResponse.
BasicOCSPResponse ::= SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Значение подписи должно вычисляться для хэша DER-представления ResponseData.
ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, responderID ResponderID, producedAt GeneralizedTime, responses SEQUENCE OF SingleResponse, responseExtensions [1] EXPLICIT Extensions OPTIONAL } ResponderID ::= CHOICE { byName [1] Name, byKey [2] KeyHash } KeyHash ::= OCTET STRING -- SHA-1 хэш открытого ключа Responder'а -- (включая поля тега и длины) SingleResponse ::= SEQUENCE { certID CertID, certStatus CertStatus, thisUpdate GeneralizedTime, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL } CertStatus ::= CHOICE { good [0]IMPLICIT NULL, revoked [1]IMPLICIT RevokedInfo, unknown [2]IMPLICIT UnknownInfo } RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } UnknownInfo ::= NULL -- данное поле может быть изменено
Данные активации
Данные активации указывают на значения данных, отличные от ключей, которые требуются для функционирования криптографических модулей и которые должны быть защищены. Считается, что защита данных активации потенциально необходима для выпускающего СА, субъекта САs, RАs и конечных участников. Подобное рассмотрение потенциально должно быть адресовано всему жизненному циклу данных активации, от создания до архивации и уничтожения. Для каждого из типов участников выше перечислены все вопросы, на которые необходимо ответить относительно данных активации, а не относительно ключей.
Делегирование полномочий OCSP Responder'у
Ключ, которым подписывается информация о статусе сертификата, не должен быть тем же самым ключом, которым подписан сертификат. Выпускающий сертификаты явно делегирует OCSP Responder выпуск сертификатов. Сертификат OCSP Responder содержит уникальное значение для extendedKeyUsage. Данный сертификат должен быть выпущен непосредственно для Responder ответственным за это СА.
Детали протокола
Используется ASN.1-синтаксис. Для вычисления подписи подписываемые данные представлены с использованием ASN.1 DER.
Другие аспекты управления ключом
Следует рассмотреть и другие аспекты управления ключом для выпускающего СА, репозиториев, субъектов САs, RAs и субъектов конечных участников.
Для каждого из этих типов участников должны быть получены ответы на следующие вопросы:
Архивируется ли открытый ключ? Если да, то кто является агентом архивации и какие средства управления безопасностью предусмотрены для системы архивации? Система архивации должна обеспечивать контроль целостности, отличный от цифровых подписей, т.к. период архивации может быть больше, чем период криптоанализа для ключа, и архив требует дополнительной защиты, которая не обеспечивается цифровыми подписями.Каковы периоды использования или время жизни архива для открытого и закрытого ключа, соответственно?
Идентификация и аутентификация
Данный компонент описывает процедуры, используемые для аутентификации претендента на сертификат перед тем как СА или RA выпустит его. Также описывается аутентификация участников, которые запрашивают новые ключи или отмену. Данный компонент адресован и практикам именования, включая распознавание собственных имен и разрешение конфликтов имен.
Данный компонент имеет следующие подкомпоненты:
Начальная регистрация. Типы имен, связанные с субъектом.Являются имена значимыми или нет.Правила интерпретации различных форм имени.Должны ли имена быть уникальными.Как разрешается конфликт имен.Признание, аутентификация и роль торговых марок.Как субъект должен доказывать обладание соответствующим закрытым ключом для зарегистрированного открытого ключа.Требования аутентификации для идентификации организации субъекта (СА, RA или конечного участника).Требования аутентификации для персональных действий от имени субъекта (СА, RA или конечного участника), включая:Число требуемых элементов идентификации.Как СА или RA проверяют действительность предоставленных элементов идентификации.Должен ли конкретный человек персонально присутствовать для аутентификации СА или RA.Как аутентифицируется конкретный человек в качестве представителя организации.
Процедура создания нового ключа - описывает процедуры идентификации и аутентификации для процедуры создания нового ключа для каждого типа субъекта (СА, RA и конечного участника).Создание нового ключа после отмены - описывает процедуры идентификации и аутентификации при создании нового ключа для каждого типа субъекта (СА, RA и конечного участника) после того, как сертификат субъекта был отменен.Запрос отмены - описывает процедуры идентификации и аутентификации для запроса отмены для каждого типа субъекта (СА, RA и конечного пользователя).
Исключительные случаи
В случае ошибок OCSP Responder может вернуть соответствующее сообщение. Оно не подписывается. Ошибки могут быть следующих типов:
MalformedRequestInternalErrorTryLaterSigRequiredUnauthorized
Сервер создает malformedRequest ответ, если полученный запрос не соответствует OCSP-синтаксису.
Ответ internalError указывает, что OCSP Responder перешел в несогласованное внутреннее состояние. Запрос должен быть повторен с другим Responder.
Если OCSP Responder функционирует, но не может вернуть статус запрошенного сертификата, ответ tryLater может указывать на то, что сервис существует, но временно не может выдать ответ.
Ответ sigRequired возвращается в том случае, когда сервер для создания ответа требует, чтобы клиент подписал запрос.
Ответ unauthorized возвращается в том случае, когда клиент не авторизован выполнять данный запрос для данного сервера.
Компрометация ключа СА
Если OCSP Responder знает, что закрытый ключ конкретного СА компрометирован, он может возвращать статус отмены для всех сертификатов, выпущенных данным СА.
Квалификаторы политики
Поле расширения CertificatePolicies предназначено для дополнительной, не зависящей от политики информации, которая содержится в поле квалификатора. Стандарт Х.509 не указывает цель, для которой данное поле используется, и не задает синтаксис для данного поля. Типы квалификаторов политики могут регистрироваться любой организацией.
В настоящий момент определены следующие типы квалификаторов политики:
Квалификатор CPS Pointer содержит указатель на регламент практики сертифицирования (CPS), опубликованный СА. Указатель является URI.Квалификатор User Notice содержит текстовую строку, которая показывается пользователю сертификата перед тем, как он задействует сертификат.
Квалификаторы политики могут применяться для поддержки определения общих или параметризируемых определений политики сертификата. Являясь базовым определением политики сертификата, типы квалификаторов политики могут определять способ предоставления на основе сертификата конкретных дополнительных деталей политики.
Множество постановлений
Множество постановлений определяет регламент практики сертификации.
Например, CPS может выражаться в виде сочетания следующих элементов:
Список политик сертификата, поддерживаемых CPS.Каждой политики сертификата в (1) существует набор постановлений, которые уточняют политику сертификата деталями, обусловленными данной политикой; такие постановления предназначены для установления того, как конкретный CPS реализует требования конкретной политики сертификата.Множество постановлений, которые содержат утверждения, относящиеся к регламенту сертификации СА независимо от политики сертификата.
Утверждения, приведенные в (2) и (3), могут уточнить условия применяемости определения политики сертификата, но не должны конфликтовать с другими условиями определения политики сертификата.
Регламент сертификационной практики должен состоять примерно из следующих компонентов:
введение;общие постановления;идентификация и аутентификация;требования функционирования;управление физической, административной безопасностью и безопасностью персонала;управление технической безопасностью;профиль сертификата и CRL;oписание администрирования.
Далее компоненты могут быть поделены на подкомпоненты.
Nonce
Nonce криптографически связывает запрос и ответ для предотвращения replay-атак. И в запросе, и в ответе nonce должен идентифицироваться идентификатором объекта id-pkix-ocsp-nonce, значением nonce является extnValue.
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Обязательные и дополнительные криптографические алгоритмы
Клиенты, которые запрашивают сервис OCSP, должны иметь возможность обрабатывать ответы, подписанные с использованием ключей DSA. Клиенты также должны иметь возможность обрабатывать подписи RSA. Отвечающие OCSP должны поддерживать алгоритм хэширования SHA-1.
Общие постановления
Данный компонент описывает все используемые предположения и состоит из следующих подкомпонентов:
Обязательства - содержит для каждого типа участника все используемые постановления, относящиеся к обязательствам участника по отношению к другим участникам. Обязательства СА и/или RA: уведомление подписчика, который является субъектом выпущенного сертификата, о выпуске сертификата;уведомление о выпуске сертификата других участников, которые не являются субъектами сертификата;уведомление об отмене или приостановке сертификата подписчика, чей сертификат отменен или приостановлен;уведомление об отмене или приостановке сертификата других участников, которые не являются субъектами отмененного или приостановленного сертификата.
Обязательства подписчика: точность представлений в приложении сертификата;защита закрытого ключа участника;ограничения использования закрытого ключа и сертификата;уведомление о компрометации закрытого ключа.
Обязательства доверяющей группы: цели, для которых используется сертификат;ответственность при проверке цифровой подписи;ответственность при проверке отмены и приостановки;признание применяемых законов и полномочий.
Обязательства репозитория: своевременное опубликование сертификатов и информации об отмене.
Ответственность.Финансовая отчетность.Интерпретация и претворение в жизнь.Оплата.Опубликование и хранение: обязательства СА, касающиеся опубликования информации, относящейся к его практикам, сертификатам и текущему статусу сертификатов;частота опубликования;управление доступом к опубликованным информационным объектам, включая определения политики сертификата, CPS, сертификаты, статус сертификата и CRLs;требования, относящиеся к использованию репозиториев.
Согласованный аудит.Политика конфиденциальности: типы информации, конфиденциальность которых должна обеспечиваться СА или RA;типы информации, которые не считаются конфиденциальными;кто имеет право сообщать о причинах отмены и приостановки сертификатов;политика по сообщению информации об официальном вводе в действие законов;условия, при которых СА или RA могут раскрыть информацию;любые другие условия, при которых конфиденциальная информация может быть раскрыта.
Права интеллектуальной собственности.
Обсуждение проблем безопасности
Для того чтобы данный сервис был эффективным, использующие сертификаты системы должны соединяться с провайдером сервиса статуса сертификата. В случае если такое соединение не может быть получено, использующие сертификаты системы могут задействовать обработку CRL в качестве запасного варианта.
Уязвимость отказа сервиса при большом потоке запросов является очевидной. Вычисление криптографической подписи оказывает существенное влияние на время создания ответа, в результате чего ситуация обостряется. Неподписанные ответы об ошибках открывают протокол для других подобного рода атак, когда злоумышленник посылает ложные сообщения об ошибках.
Использование заранее вычисленных ответов допускает replay-атаки, в которых старый (хороший) ответ повторяется до даты своего истечения, но после того, как сертификат был отменен. Развертывание OCSP должно быть тщательно просчитано для получения преимуществ от заранее вычисленных ответов, чтобы не допустить вероятность replay-атак в противовес большой цене, связанной с вычислениями.
Запросы не содержат Responder, к которому они обращаются. Это позволяет атакующему повторить запрос к любому количеству OCSP Responder.
Использование кэширования НТТР в некоторых сценариях развертывания может привести к непредсказуемым результатам, если промежуточные серверы некорректно сконфигурированы или известно, что возможны ошибки при управлении кэшем.
Обзор протокола
Рассмотрим протокол, используемый для определения текущего статуса сертификата без использования CRLs.
В противоположность периодической проверке CRL иногда бывает необходимо получать текущую информацию о статусе сертификата. В качестве примера таких случаев можно привести пересылку ценных бумаг большого достоинства или масштабных фондовых продаж.
OCSP необходим приложениям для определения состояния отмены указанного сертификата в текущий момент времени. OCSP может использоваться для обеспечения требований, касающихся получения более своевременной информации об отмене, чем это возможно с использованием CRLs. Данный протокол также может применяться для получения дополнительной информации о статусе. Клиент OCSP выполняет запрос статуса и приостанавливает решение о признании сертификата действительным до тех пор, пока не получит ответ.
Данный протокол определяет данные, которые необходимы для осуществления операций обмена между приложением, проверяющим статус сертификата, и сервером, предоставляющим этот статус.
OCSP поверх НТТР
Опишем форматирование, которое должно быть выполнено, если запрос и ответ используют НТТР.
Отвечающие уполномоченные органы
Ключ, которым подписана информация о статусе сертификата, не должен быть тем же самым ключом, которым подписан сертификат. Тем не менее, необходимо гарантировать, что участник, подписавший данную информацию, авторизован делать это. Следовательно, выпускающий сертификат должен либо сам подписать ответы OCSP, либо явно делегировать соответствующие полномочия другому участнику. Делегирование подписывания OCSP должно быть выполнено путем включения id-kp-OCSPSigning в расширение extendedKeyUsage сертификата, подписывающего OCSP-ответ. Данный сертификат должен быть выпущен непосредственно СА.
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
Проверка отмены сертификата Responder
Так как Responder предоставляет информацию о статусе для одного или более САs, клиенты OCSP должны знать, как проверить, не отменен ли сертификат отвечающего уполномоченного органа. САs могут выбрать один из трех способов решения проблемы:
СА может определить, что клиент OCSP может доверять отвечающему в течение времени жизни сертификата отвечающего. СА делает это посредством включения расширения id-pkix-ocsp-nocheck. Это должно быть некритичное расширение. САs, выпускающие такие сертификаты, должны осознавать, что компрометация ключа Responder'а так же опасна, как и компрометация ключа СА, используемого для подписывания CRLs. СА могут выпускать данный тип сертификата с очень коротким сроком действия и часто обновлять его.
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } СА может указать, как проверять отмену сертификата Responder. Это можно сделать с помощью точек распределения CRL, если проверка должна быть выполнена с использованием CRL.СА может не указывать какой-либо метод проверки отмены для сертификата Responder'а, в этом случае локальная политика безопасности клиента OCSP определяет, следует проверять сертификат на отмену или нет.
Ответы OCSP
Ответы OCSP могут быть нескольких типов. Ответ OCSP состоит из типа ответа и байтов самого ответа. Существует один базовый тип ответа OCSP, который должен поддерживаться всеми клиентами и серверами OCSP. Далее мы будем рассматривать только данный базовый тип ответа.
Все сообщения окончательного ответа должны быть подписаны. Ключ, используемый для подписи ответов, должен принадлежать одному из следующих участников:
СА, который выпустил сертификат, указанный в запросе.Responder, чьему открытому ключу доверяет запрашивающая сторона.Responder, назначенный СА (Уполномоченный орган для OCSP-ответов), который имеет специально маркированный сертификат, выпущенный непосредственно СА. Сертификат указывает, что Responder может выпускать OCSP-ответы для данного СА.
Сообщение окончательного ответа состоит из:
Версии синтаксиса ответа.Имени Responder.Ответов для каждого из сертификатов в запросе.Необязательных расширений.OID алгоритма подписи.Подписи, вычисленной для хэша ответа.
Ответ для каждого сертификата в запросе состоит из:
Идентификатора целевого сертификата.Значения статуса сертификата.Интервала действительности ответа.Необязательных расширений.
Определены следующие варианты статуса сертификата в окончательных ответах:
GoodRevokedUnknown
Состояние good определяет положительный ответ на запрошенный статус. Как минимум, данный положительный ответ указывает, что сертификат не отменен, но это не обязательно означает, что он был хотя бы выпущен или что время, в которое был сделан запрос, находится в интервале действительности сертификата. Расширения ответа могут использоваться для передачи дополнительной информации или предположений, сделанных Responder относительно статуса сертификата, таких как положительное утверждение о выпуске, действительности и т.д.
Состояние revoked указывает, что сертификат отменен (либо постоянно, либо временно).
Состояние unknown указывает, что отвечающий не знает о сертификате, который был запрошен.
Ответы OCSP могут быть нескольких типов. Ответ OCSP состоит из типа ответа и байтов самого ответа. Существует один базовый тип ответа OCSP, который должен поддерживаться всеми клиентами и серверами OCSP. Далее мы будем рассматривать только данный базовый тип ответа.
Все сообщения окончательного ответа должны быть подписаны. Ключ, используемый для подписи ответов, должен принадлежать одному из следующих участников:
СА, который выпустил сертификат, указанный в запросе.Responder, чьему открытому ключу доверяет запрашивающая сторона.Responder, назначенный СА (Уполномоченный орган для OCSP-ответов), который имеет специально маркированный сертификат, выпущенный непосредственно СА. Сертификат указывает, что Responder может выпускать OCSP-ответы для данного СА.
Сообщение окончательного ответа состоит из:
Версии синтаксиса ответа.Имени Responder.Ответов для каждого из сертификатов в запросе.Необязательных расширений.OID алгоритма подписи.Подписи, вычисленной для хэша ответа.
Ответ для каждого сертификата в запросе состоит из:
Идентификатора целевого сертификата.Значения статуса сертификата.Интервала действительности ответа.Необязательных расширений.
Определены следующие варианты статуса сертификата в окончательных ответах:
GoodRevokedUnknown
Состояние good определяет положительный ответ на запрошенный статус. Как минимум, данный положительный ответ указывает, что сертификат не отменен, но это не обязательно означает, что он был хотя бы выпущен или что время, в которое был сделан запрос, находится в интервале действительности сертификата. Расширения ответа могут использоваться для передачи дополнительной информации или предположений, сделанных Responder относительно статуса сертификата, таких как положительное утверждение о выпуске, действительности и т.д.
Состояние revoked указывает, что сертификат отменен (либо постоянно, либо временно).
Состояние unknown указывает, что отвечающий не знает о сертификате, который был запрошен.
Ответ Pre-production
OCSP Responder может заранее создать подписанные ответы, указывающие статус сертификата в заданное время. Время, когда было известно, что статус корректный, должно быть отражено в поле thisUpdate ответа. Время, когда или до которого доступна более новая информация, отражается в поле nextUpdate, тогда как время, когда был создан ответ, указано в поле produceAt ответа.
Политика сертификата
Когда СА выпускает сертификат, он предоставляет проверяющей стороне доказательство того, что данный открытый ключ связан с конкретным участником (субъектом сертификата). Однако степень доверия утверждению СА со стороны пользователя сертификата должна быть оценена пользователем сертификата. Различные сертификаты выпускаются, следуя разным процедурам и практикам, и могут быть предназначены для различных приложений и/или целей.
Стандарт Х.509 определяет политику сертификата как "именованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности". Сертификат Х.509 v3 может содержать индикацию политики сертификата, которая может применяться пользователем сертификата при принятии решения о том, можно ли задействовать сертификат для той или иной цели.
Политика сертификата, которую должны распознавать как выпускающий, так и пользователь сертификата, представлена в сертификате уникальным зарегистрированным Object Identifier. Процесс регистрации должен следовать стандартам ISO/IEC и ITU. Участник, который регистрирует Object Identifier, также публикует текстовую спецификацию политики сертификата. В сертификате обычно декларируется единственная политика сертификата или, возможно, небольшое число различных политик.
Политики сертификата также являются основой для аккредитации САs. Каждый СА аккредитуется для одной или более политик сертификата, которые он должен реализовывать. Когда один СА выпускает кросс-сертификат для другого СА, выпускающий кросс-сертификат СА должен оценить множество политик этого СА, которые он имеет возможность использовать.
используются для поддержки политик
Следующие поля расширения в сертификате Х. 509 используются для поддержки политик сертификата:
Расширение CertificatePolicies,Расширение PolicyMappings,Расширение PolicyConstraints.
Примеры политики сертификата
В качестве примера предположим, что некая организация определила две политики сертификата - одну для использования в общих целях (General-Purpose), другую для проведения финансовых транзакций (Commercial-Grade).
Будем считать, что политика General-Purpose предназначена для защиты передаваемой информации (например, e-mail) или для аутентифицированных соединений от браузеров к серверам. Пара ключей может создаваться, храниться и управляться с использованием дешевых, основанных на ПО систем. При такой политике сертификат может автоматически выпускаться для любого сотрудника, который перешлет подписанный запрос сертификата системному администратору организации.
Политика Commercial-Grade используется для защиты финансовых транзакций. Для такой политики требуется, чтобы пара сертифицированных ключей создавалась и хранилась в соответствующих криптографических аппаратных токенах. Сертификаты и токены предоставляются сотрудникам. Требуется, чтобы эти авторизованные лица сами приходили в офис безопасности, выполняли некоторые формальные процедуры идентификации, подписывали обязательство по защите токена и т.п.
Расположение сервиса
OCSP сервер может функционировать в режиме, в котором он получает запросы и перенаправляет их другому OCSP-серверу, про который известно, что он имеет полномочия для указанного сертификата. Для данной цели определено расширение запроса serviceLocator.
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } ServiceLocator ::= SEQUENCE { issuer Name, locator AuthorityInfoAccessSyntax OPTIONAL }
Расширение CertificatePolicies
Расширение CertificatePolicies имеет два варианта - один с полем, помеченным как некритичное, другой с полем, помеченным как критичное. Назначение поля в этих двух случаях различается.
Некритичное поле CertificatePolicies перечисляет политики сертификата, которые СА объявляет применимыми. Однако использование сертификата не ограничивается целями, указанными в применимых политиках. Некритичное поле CertificatePolicies предназначено для использования приложениями следующим образом. Каждое приложение заранее сконфигурировано так, что оно "знает", какая политика ему требуется.
При обработке сертификационного пути политика сертификата, которая принимается использующим сертификат приложением, должна присутствовать в каждом сертификате в пути, т.е. и в СА-сертификате, как и в сертификатах конечных участников.
Если поле CertificatePolicies помечено как критичное, оно предназначено для той же цели, которая описана выше, но также имеет дополнительную роль. Она указывает, что использование сертификата ограничено одной из указанных политик, например СА декларирует, что сертификат может применяться только в соответствии с положениями одной из перечисленных политик сертификата. Это поле предназначено для защиты СА от ущерба при несоответствующем использовании сертификата.
Расширение PolicyConstraints
Расширение PolicyConstraints поддерживает две дополнительные функции. Первая состоит в возможности для СА требовать, чтобы явные индикации политики сертификата были представлены во всех следующих сертификатах в сертификационном пути. Сертификаты в начале сертификационного пути могут рассматриваться пользователем сертификата как часть доверенного домена, например, САs являются доверенным для всех целей, следовательно, нет необходимости указывать конкретную политику сертификата в расширении CertificatePolicies. Такие сертификаты не содержат явного указания политики сертификата. Однако если СА в доверенном домене сертифицирует внешний домен, он может указать требование явной политики сертификата в следующих сертификатах в сертификационном пути.
Другая дополнительная функция поля PolicyConstraints для СА состоит в возможности запретить отображение политик для следующих САs в сертификационном пути. Это может послужить мерой предосторожности, чтобы запретить отображение политики при сертификации вне домена. Это может помочь контролировать риски при транзитивном доверии, например, домен А доверяет домену В, домен В доверяет домену С, но домен А не хочет быть вынужденным доверять домену С.
Расширение PolicyMappings
Расширение PolicyMapping может использоваться только в сертификатах СА. Данное поле позволяет СА указать, что некоторые политики в его собственном домене могут считаться эквивалентными некоторым другим политикам в домене субъекта СА.
Например, предположим, что между корпорациями существует соглашение на кросс-сертификацию открытых ключей. Далее предположим, что обе корпорации имеют ранее определенные политики безопасности для защиты финансовых транзакций, которые называются по-разному. Можно видеть, что простое создание кросс-сертификатов не обеспечивает необходимой интероперабельности, так как приложения компаний сконфигурированы таким образом, чтобы принимать свои собственные политики безопасности. Одно из возможных решений состоит в том, чтобы переконфигурировать все финансовые приложения на нужную политику и заново выпустить все сертификаты с другой политикой. Другое решение состоит в использовании поля PolicyMapping. Тогда данное поле должно быть включено в кросс-сертификат.
Расширения
Опишем некоторые стандартные расширения, основываясь на модели расширений, применяемой в сертификатах Х.509 v3. Поддержка всех расширений не обязательна как для клиентов, так и для Responder. Для каждого расширения укажем его синтаксис и обработку, выполняемую OCSP Responder. Также перечислим все расширения, которые включаются в соответствующий ответ.
Регламент практики сертификации
Термин регламент практики сертификации (CPS) может быть определен следующим образом: детальное описание практики, при которой СА выпускает сертификаты. Данное определение можно дополнить следующими комментариями.
Регламент практик сертификации может быть оформлен как декларация СА о деталях системы и регламентах функционирования и поддержки выпуска сертификатов. Это также может быть часть контракта между СА и его подписчиками. CPS включает несколько документов, содержащих законы, частные контракты и/или декларации.
Доверяющий участник знает или, по крайней мере, предупрежден о содержании сертификата, используемого им для проверки цифровой подписи, включая документы, на которые имеется ссылка в сертификате. Следовательно, желательно вставлять ссылку на регламент сертификационной практики в сертификат.
Регламент сертификационной практики должен указывать на стандарты, в соответствии с которыми СА осуществляет свою деятельность, а также на потенциальную технологическую совместимость сертификатов, выпущенных СА.
Семантики thisUpdate, nextUpdate и producedAt
Ответы могут содержать три значения времени - thisUpdate, nextUpdate и producedAt. Смысл этих полей следующий:
ThisUpdate: время, когда стало известно, что статус корректный.NextUpdate: время, не позднее которого будет доступна более новая информация о статусе сертификата.ProducedAt: время, когда OCSP Responder подписал данный ответ.
Если nextUpdate не установлено, это означает, что более новая информация об отмене доступна постоянно.
Синтаксис ответа
Опишем ASN.1-спецификацию ответов. Реальное форматирование сообщения может зависеть от используемого механизма транспорта (НТТР, SMTP, LDAP и т.д.).
Синтаксис запроса
OCSPRequest ::= SEQUENCE { tbsRequest TBSRequest, optionalSignature [0] EXPLICIT Signature OPTIONAL } TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, requestList SEQUENCE OF Request, requestExtensions [2] EXPLICIT Extensions OPTIONAL } Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } Version ::= INTEGER { v1(0) } Request ::= SEQUENCE { reqCert CertID, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- хэш DN выпускающего issuerKeyHash OCTET STRING, -- хэш открытого ключа -- выпускающего serialNumber CertificateSerialNumber }
IssuerNameHash является хэшем уникального имени выпускающего. Хэш должен вычисляться поверх DER-представления поля имени выпускающего в проверяемом сертификате. IssuerKeyHash является хэшем открытого ключа выпускающего. Хэш должен быть вычислен поверх значения (включая тег и длину) поля открытого ключа субъекта в сертификате выпускающего. Хэш-алгоритм, используемый для вычисления обоих хэшей, указывается в hashAlgorithm. SerialNumber является последовательным номером сертификата, для которого запрашивается статус.
Содержание множества постановлений
Сначала опишем содержание множества постановлений. Соответственно, темы, рассматриваемые здесь, являются кандидатами на включение в определение политики сертификата или CPS.
Тем не менее, нет необходимости включать каждый раздел в конкретную политику сертификата или CPS. Скорее конкретная политика сертификата или CPS может указать "нет условий" для компонента, подкомпонента или элемента, для которых она не выдвигает требований. В этом случае список тем может рассматриваться как контрольный список при создании политики сертификата или CPS. Рекомендуется, чтобы все компоненты и подкомпоненты были включены в политику сертификата или CPS, даже если там определено "нет условий". Это защищает от случайного пропуска темы и обеспечивает возможность сравнения различных политик или CPSs.
В определении политики сертификата возможен пропуск нескольких компонентов, подкомпонентов и/или элементов, и указание, что необходимая информация будет определена в квалификаторе политики. Такие определения политики сертификата можно рассматривать как параметризованные определения. Множество постановлений должно определять требуемые типы квалификаторов политики и специфицировать все используемые значения по умолчанию.
Содержимое сертификата
Для того чтобы передавать клиентам OCSP точку доступа к информации, САs должны включать расширение AuthorityInfoAccess в сертификаты, которые могут быть проверены с использованием OCSP.
САs, которые поддерживают OCSP-сервис, либо размещающие его локально, либо предоставляющие его внешним клиентам с помощью Responder, должны обеспечивать включение значения URI accessLocation и значения OID id-ad-ocsp для accessMethod в последовательность AccessDescription выпускаемых сертификатов.
Значение поля accessLocation в сертификате субъекта определяет транспорт (например, НТТР), используемый для доступа к OCSP Responder, и может содержать другую относящуюся к транспорту информацию (например, URI).
Создание и инсталляция пары ключей
Создание и инсталляция пары ключей должна рассматриваться для САs, RAs и конечных участников. Для каждого из этих типов участников необходимо получить ответы на следующие вопросы:
Кто создает пару открытый-закрытый ключи участника?Каким образом закрытый ключ безопасно доставляется участнику?Как открытый ключ участника безопасно доставляется выпускающему сертификат?Если участник является СА (выпускающий или субъект), то как открытый ключ участника безопасно доставляется пользователям?Каковы размеры ключей?Кто создает параметры открытого ключа?Качество параметров проверяется при создании ключа?Создание ключа выполняется аппаратно или программно?Для каких целей может использоваться ключ или для каких целей должно быть ограничено применение ключа?
Ссылки на CRL
Может потребоваться для отвечающего OCSP указать CRL, в котором можно найти отмененный или приостановленный сертификат. Это может быть полезно, когда OCSP используется для взаимодействия между репозиториями, а также в качестве механизма аудита. CRL может указываться с помощью URL (по которому CRL доступен), номера (номер CRL) или времени (время, когда соответствующий CRL был создан). Эти расширения специфицируются как singleExtensions. Идентификатор для данного расширения есть id-pkix-ocsp-crl, значением должно быть CrlID.
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } CrlID ::= SEQUENCE { crlUrl [0] EXPLICIT IA5String OPTIONAL, crlNum [1] EXPLICIT INTEGER OPTIONAL, crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
Для crlUrl IA5String указывает URL, по которому доступен CRL. Для crlNum INTEGER определяет значение расширения номера CRL соответствующего CRL. Для crlTime GeneralizedTime определяет время, когда был выпущен соответствующий CRL.
Типы принимаемых ответов
Клиент OCSP может захотеть указать типы ответов, которые он распознает. Для того чтобы сделать это, он должен использовать расширение с OID id-pkix-ocsp-response и значением AccepttableResponses. Данное расширение включается в одно из requestExtensions в ответах. OIDs, включенные в AccepttableResponses, являются OIDs различных типов ответов, которые данный клиент может принимать (например, id-pkix-ocsp-basic).
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
Как отмечалось выше, OCSP отвечающий должен уметь создавать ответы типа id-pkix-ocsp-basic. Соответственно, OCSP клиенты должны уметь получать и обрабатывать ответы типа id-pkix-ocsp-basic.
Требования принятия подписанного ответа
Для того чтобы считать подписанный ответ действительным, клиенты OCSP должны убедиться, что:
Сертификат, указанный в полученном ответе, соответствует тому, который был определен в запросе.Подпись в ответе действительна.Идентификация подписавшего соответствует ожидаемому получателю запроса.Подписавший в настоящий момент авторизован подписывать ответы.Время, когда статус был указан как корректный (thisUpdate), считается неустаревшим.Время, когда или до которого доступна более новая информация о статусе сертификата (nextUpdate), при этом оно должно быть больше текущего времени. Данная информация не является обязательной.
Требования выполнения
Данный компонент используется для спецификации требований, накладываемых на действия СА, субъектов САs, RАs или конечных участников в зависимости от различных выполняемых действий.
Данный компонент состоит из следующих подкомпонентов:
Применение сертификата - используется для установления требований, относящихся к регистрации субъекта и запроса на выпуск сертификата.Выпуск сертификата - используется для установления требований, относящихся к выпуску сертификата, и уведомления претендента об этом выпуске.Получение сертификата - используется для установления требований, относящихся к получению сертификата и к последующей его публикации.Приостановка и отмена сертификата. Условия, при которых сертификат может быть отменен.Кто может запросить отмену сертификата участника.Процедуры, используемые для запроса отмены сертификата.Допустимый период задержки запроса отмены для субъекта.Условия, при которых сертификат может быть приостановлен.Кто может запросить приостановку сертификата.Процедуры запроса приостановки сертификата.Как долго может продолжаться приостановка.Если используется механизм CRL, то частота выпуска.Требования доверяющим группам к проверке CRLs.Возможность on-line проверки отмены/статуса.Требования к доверяющим группам выполнять on-line проверки отмены/статуса.Другие доступные формы объявления об отмене.Требования для доверяющих групп проверять другие формы объявлений об отмене.Любые варианты приведенных выше условий, когда приостановка или отмена являются результатом компрометации ключа (в противовес другим причинам приостановки или отмены).
Процедуры аудита безопасности. Типы записываемых событий.Частота, с которой записи аудита сохраняются и обрабатываются.Срок хранения записей аудита.Процедура выполнения аудита: Кто может просматривать записи аудита.Защита от модификации записей аудита.Защита от удаления записей аудита.
Процедуры back up записей аудита.Является система анализа аудита для участника внутренней или внешней.Оповещается ли субъект, который вызвал событие аудита, о действиях аудита.Предполагаемые уязвимости.
Архивация записей. Типы зарегистрированных событий.Период хранения архива.Защита архива: Кто может просматривать архив.Защита от модификации архива.Защита от удаления архива.
Процедуры back up архива.Требования к отметкам времени записей. Система хранения архива является внутренней или внешней.Процедуры для получения и проверки архивной информации.
Изменение ключа.Компрометация и восстановление. Используемые процедуры восстановления, если вычислительные ресурсы, ПО или данные испорчены наверняка или предположительно. Эти процедуры описывают, как переустановить безопасное окружение, в котором отменены сертификаты или ключ участника, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.Процедуры восстановления, которые используются, если открытый ключ участника отменен. Эти процедуры описывают, как переустановить безопасное окружение, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.Процедуры восстановления, использующиеся в том случае, если открытый ключ скомпрометирован. Эти процедуры описывают, как переустановить безопасное окружение, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.Процедуры, СА, используемые для обеспечения безопасности при восстановлении безопасного окружения либо на исходном сайте, либо на удаленном сайте. Например, процедуры защиты от кражи секретных материалов.
Завершение функционирования СА.
В каждом подкомпоненте может потребоваться отдельное рассмотрение для выпускающего СА, репозитория, субъекта САs, RAs и конечных участников.
Управление безопасностью компьютера
Данный подкомпонент используется для описания управления безопасностью компьютера, такого как: использование базового понятия доверенных вычислений, дискреционное управление доступом, метки, мандатное управление доступом, переиспользование объектов, аудит, идентификация и аутентификация, доверенный путь, тестирование безопасности и тестирование проникновения. Может также рассматриваться гарантирование продукта.
Для компьютерных систем может потребоваться оценка безопасности компьютера. Оценка может быть основана, например, на различных используемых критериях (Common Criteria - СС). Данный подкомпонент может быть также адресован требованиям для анализа оценки продукта, тестирования, профилирования, сертификации продукта и/или аккредитации продукта в соответствии с выполняемой деятельностью.
Управление безопасностью жизненного цикла
Данный подкомпонент адресован контролю за разработкой системы и контролю управления безопасностью.
Контроль разработки системы включает безопасность окружения разработки, безопасность персонала разработки, безопасность управления конфигурацией при сопровождении продукта, методологию разработки ПО, модульность, многоуровневость, использование надежного проектирования и технологий реализации.
Контроль управления безопасностью включает выполнение средств и процедур, гарантирующих, что функциональные системы и сети остаются безопасно сконфигурированными. Эти средства и процедуры включают проверку целостности ПО и аппаратуры для гарантии их безопасного функционирования.
Данный компонент также может быть адресован оценке безопасности жизненного цикла, основанного на методологии разработки доверенного ПО (TSDM) уровня IV и V и независимого аудита безопасности жизненного цикла.
Управление криптографическим модулем
Данный подкомпонент адресован следующим аспектам криптографического модуля: идентификация границы криптографического модуля, ввод/вывод, роли и сервисы, машина конечных состояний, физическая безопасность, безопасность ПО, безопасность системы функционирования, согласованность алгоритма, электромагнитная совместимость и самотестируемость.
Время
Поля thisUpdate и nextUpdate определяют рекомендуемый интервал повторной проверки действительности. Данный интервал соответствует {thisUpdate, nextUpdate} интервалу в CRLs. Ответы, у которых значение nextUpdate меньше значения локального системного времени, должны считаться ненадежными.
Ответы, у которых время thisUpdate больше, чем локальное системное время, должны считаться ненадежными. Ответы, у которых значение nextUpdate не установлено, эквивалентны CRL с отсутствием времени для nextUpdate.
Время producedAt - это время, когда ответ был подписан.
Рассмотрим общие принципы написания политик
Рассмотрим общие принципы написания политик сертификата или понятие регламента сертификационной практики для СА. В частности, рассмотрим список тем, которые следует охватить при определении политики сертификата и регламента сертификационной практики.
Сертификат открытого ключа связывает значение открытого ключа с информацией, которая идентифицирует участника (такого как персона, организация, account или сайт), использующего соответствующий закрытый ключ (данный участник считается "субъектом" сертификата). Сертификат применяется "пользователем сертификата" или "доверяющей группой", которой необходимо задействовать открытый ключ из сертификата. Степень доверия пользователя сертификата осуществленному в сертификате связыванию зависит от нескольких факторов. Эти факторы определяются регламентом, которому следует СА при аутентификации субъекта и выпуске сертификата; политикой функционирования, использующей управление безопасностью СА; обязательствами по отношению к субъекту (например, в отношении защиты закрытого ключа); законодательными обязательствами СА.
Сертификат Х.509 v3 может содержать поля, декларирующие, что для данного сертификата применялись одна или более политик сертификата. Соответственно, политика сертификата есть "поименованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности". Политика сертификата может применяться пользователем сертификата при решении вопроса о том, может ли доверять сертификату и содержащейся в нем информации для конкретного приложения.
Детальное описание регламента, которому следует СА при выпуске и управлении сертификатами, содержится в регламенте сертификационной практики (Certification Practice Statement - CPS), публикуемом СА.
Рассмотрим взаимосвязь между политиками сертификата и CPS.
Определим элементы, которые могут потребоваться при создании политики сертификата или CPS.
Мы ограничимся обсуждением понятий политики сертификата (как определено в Х.509) и CPS. В частности, опишем типы информации, которые могут быть включены в определение политики сертификата или CPSs. Хотя предполагается использование формата сертификата Х.509 версии 3, не обязательно ограничиваться применением только данного формата сертификата. Более того, считается, что данная основа может быть адаптирована для других форматов сертификата.
Рассмотрим общие принципы написания политик сертификата или понятие регламента сертификационной практики для СА. В частности, рассмотрим список тем, которые следует охватить при определении политики сертификата и регламента сертификационной практики.
Сертификат открытого ключа связывает значение открытого ключа с информацией, которая идентифицирует участника (такого как персона, организация, account или сайт), использующего соответствующий закрытый ключ (данный участник считается "субъектом" сертификата). Сертификат применяется "пользователем сертификата" или "доверяющей группой", которой необходимо задействовать открытый ключ из сертификата. Степень доверия пользователя сертификата осуществленному в сертификате связыванию зависит от нескольких факторов. Эти факторы определяются регламентом, которому следует СА при аутентификации субъекта и выпуске сертификата; политикой функционирования, использующей управление безопасностью СА; обязательствами по отношению к субъекту (например, в отношении защиты закрытого ключа); законодательными обязательствами СА.
Сертификат Х.509 v3 может содержать поля, декларирующие, что для данного сертификата применялись одна или более политик сертификата. Соответственно, политика сертификата есть "поименованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности". Политика сертификата может применяться пользователем сертификата при решении вопроса о том, может ли доверять сертификату и содержащейся в нем информации для конкретного приложения.
Детальное описание регламента, которому следует СА при выпуске и управлении сертификатами, содержится в регламенте сертификационной практики (Certification Practice Statement - CPS), публикуемом СА.
Рассмотрим взаимосвязь между политиками сертификата и CPS.
Определим элементы, которые могут потребоваться при создании политики сертификата или CPS.
Мы ограничимся обсуждением понятий политики сертификата (как определено в Х.509) и CPS. В частности, опишем типы информации, которые могут быть включены в определение политики сертификата или CPSs. Хотя предполагается использование формата сертификата Х.509 версии 3, не обязательно ограничиваться применением только данного формата сертификата. Более того, считается, что данная основа может быть адаптирована для других форматов сертификата.
Взаимосвязь между политикой сертификата и регламентом сертификационной практики
Понятия политики сертификата и CPS пришли из различных источников и были разработаны по разным причинам. Однако их взаимосвязь важна.
CPS является детальным описанием СА своей практики, которое должно быть принято во внимание подписчиками и пользователями сертификата. Хотя уровень детализации для разных CPSs может быть различным, обычно они бывают более развернутыми, чем определения политики сертификата. Действительно, CPS может быть всеобъемлющим, ясным документом, дающим точное описание предоставляемых сервисов, описывающим процедуры управления жизненным циклом сертификата и уровень детализации, который осуществляет CPS для конкретной реализации предоставляемого сервиса.
Хотя такая детализация может быть необходима и делает регламент заслуживающим доверия при отсутствии аккредитации или каких-то других метрик качества, детальный CPS не может служить подходящим базисом для интероперабельности САs, функционирующих в различных организациях. Политики сертификата скорее являются средством выражения общей основы интероперабельности. СА с единственным CPS могут поддерживать несколько политик сертификата (используемых для различных прикладных целей и/или в различных пользовательских сообществах). Также несколько различных САs с неидентичными CPSs могут поддерживать одну и ту же политику сертификата.
Определение политики сертификата описывает общие характеристики данной политики сертификата и указывает типы приложений, в которых она может использоваться. Различные департаменты или агентства, которые функционируют в качестве САs с разными CPSs, могут поддерживать данную политику сертификата. В то же время такие САs могут поддерживать и другие политики сертификата.
Основное различие между политикой сертификата и CPS заключается в следующем:
Большинство организаций, которые выполняют роль публичных или межорганизационных САs, документируют свои регламенты. CPS является одним из организационных способов защиты себя и своей позиции при деловых отношениях с подписчиками и другими участниками.С другой стороны, не существует особых причин, чтобы политика сертификата применялась только в одной организации. Если конкретная политика сертификата широко распространена, имеются основания для автоматического принятия сертификата во многих системах, включая системы, не требующие участия человека, и системы, которые управляются людьми, но независимо решают вопрос действительности представленных сертификатов.
Замечания о синтаксисе запроса
Первая причина использования хэша открытого ключа СА в дополнение к хэшу имени СА, идентифицирующему выпускающего, состоит в том, что, возможно, два САs используют одно и то же имя (Name) (отсутствие уникальности имени рекомендуется, но не гарантируется). Тем не менее два САs никогда не будут иметь один и тот же открытый ключ, если они явно не решили разделять один и тот же закрытый ключ или ключ одного из них был компрометирован.
Поддержка любого указанного здесь расширения не является обязательной. Флаг критичности не должен быть установлен ни для кого из них. Далее мы рассмотрим несколько полезных расширений. Могут быть также определены дополнительные расширения. Нераспознанные расширения должны игнорироваться (если только они не критичны).
Запрашивающий может подписать OCSP-запрос. В этом случае подпись вычисляется поверх tbsRequest-структуры. Если запрос подписан, то запрашивающий должен указать свое имя в поле requestorName. Также для подписанных запросов запрашивающий может включить сертификаты, которые помогут OCSP Responder проверить подпись запрашивающего.
Запрос
Запрос OCSP содержит следующие данные:
Версия протокола.Запрос сервиса.Идентификация целевого сертификата.Необязательные расширения, которые могут быть обработаны OCSP Responder.
При получении запроса OCSP Responder определяет, что:
Сообщение является правильно форматированным.Responder сконфигурирован для предоставления запрошенного сервиса.Запрос содержит информацию, необходимую Responder.
Если хотя бы одно из этих условий не выполнено, OCSP Responder создает сообщение об ошибке; в противном случае он возвращает окончательный ответ.
Запрос OCSP содержит следующие данные:
Версия протокола.Запрос сервиса.Идентификация целевого сертификата.Необязательные расширения, которые могут быть обработаны OCSP Responder.
При получении запроса OCSP Responder определяет, что:
Сообщение является правильно форматированным.Responder сконфигурирован для предоставления запрошенного сервиса.Запрос содержит информацию, необходимую Responder.
Если хотя бы одно из этих условий не выполнено, OCSP Responder создает сообщение об ошибке; в противном случае он возвращает окончательный ответ.
НТТР, лежащий в основе OCSP-запросов, может использовать либо GET, либо POST метод для submit-запросов. Для возможности НТТР-кэширования небольшие запросы (меньше 255 байтов) могут пересылаться с использованием GET. Если НТТР-кэширование не требуется или размер запроса превышает 255 байтов, запрос должен пересылаться с использованием POST. Если требуется защита, то OCSP-транзакции, применяющие НТТР, могут быть защищены с помощью TLS/SSL или другого протокола более низкого уровня.
OCSP-запрос, использующий метод GET, конструируется следующим образом:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}
где {url} может быть получено из значения AuthorityInfoAccess или локальной конфигурации OCSP-клиента.
OCSP-запрос, использующий метод POST, конструируется следующим образом: заголовок Content-Type имеет значение application/ocsp-request, а тело сообщения является бинарным значением DER-представления OCSPRequest.
Запросы
Здесь описывается ASN.1-спецификация запроса. Реальное форматирование сообщения может зависеть от используемого механизма транспорта (НТТР, SMTP, LDAP и т.д.).
Защита закрытого ключа
Необходимо рассмотреть требования для защиты закрытого ключа для выпускающего СА, репозиториев, субъектов САs, RAs и субъектов конечных участников. Для каждого из этих типов участников нужно ответить на следующие вопросы:
Какие стандарты, если они есть, требуются для модулей, используемых для создания ключей? Если так, то каким должен быть уровень модуля?Находятся ли закрытые ключи под управлением нескольких человек?Является ли закрытый ключ распределенным? Если да, то кто является распределенными агентами, которые формируют распределенные ключи, и каково безопасное управление распределенных систем?Выполняется ли back up для закрытого ключа. Если да, то кто является back up агентом, который формирует back up ключ, и каково безопасное управление back up систем?Выполняется ли архивация закрытого ключа? Если да, то кто является агентом архивации, какая форма архивации ключа выполняется и каково безопасное управление системой архивации?Кто вводит закрытый ключ в криптографический модуль? В какой форме? Как закрытый ключ хранится в модуле?Кто может активизировать (использовать) закрытый ключ? Какие действия должны быть выполнены для активации закрытого ключа? После того как ключ активирован, он активирован на неопределенный срок, активирован для одного раза или активирован на определенный период времени?Кто может деактивировать закрытый ключ и как, автоматически или по истечении времени?Кто может уничтожить закрытый ключ?
Хотя рассмотренный сценарий усиливает безопасность
Хотя рассмотренный сценарий усиливает безопасность по сравнению с первым сценарием, остаются еще две проблемы. Первая проблема состоит в том, что время жизни связано с билетом, гарантирующем билет. Если это время жизни очень короткое (т.е. минуты), то пароль у пользователя будет запрашиваться повторно. Если время жизни большое (т.е. часы), то оппонент имеет больше возможностей для совершения различных replay-атак. Злоумышленник должен просматривать сеть и перехватить билет, гарантирующий билет, и затем ждать, когда законный пользователь выйдет. Затем оппонент может подделать сетевой адрес законного пользователя и послать сообщение шага (3) к TGS. Это откроет ему неограниченный доступ к ресурсам и файлам законного пользователя.
Аналогично, если оппонент перехватил билет, гарантирующий сервис, и использует его прежде, чем истечет время его действия, он имеет доступ к соответствующему сервису.
Таким образом, можно сформулировать следующее дополнительное требование. Сетевой сервис (т.е. TGS или прикладной сервис) должны иметь возможность убедиться в том, что билет использует тот, кто получил его.
Вторая проблема состоит в том, что должна быть возможность аутентификации самих серверов для пользователей. Без подобной аутентификации оппонент может изменить конфигурацию таким образом, чтобы сообщение к серверу перенаправлялось по другому адресу. Этот ложный сервер будет затем выполнять действия в качестве реального сервера, перехватывать любую информацию от пользователя или не предоставлять ему необходимый сервис.
Сначала рассмотрим проблему перехвата билетов, гарантирующих билеты, и необходимость гарантировать, что представленный билет является тем же самым билетом, который был выдан клиенту. Для решения этой проблемы AS должен безопасным способом обеспечить как клиентский модуль, так и TGS некоторой секретной информацией. После этого клиентский модуль может доказать TGS свою идентичность, предоставляя безопасным способом эту секретную информацию. Здесь может использоваться некий разделяемый секрет, который в дальнейшем будет применяться в качестве ключа шифрования.
Этот разделяемый секрет называется ключом сессии.
Рассмотрим технологию распределения ключа сессии.
Обмен с аутентификационным сервисом для получения билета, гарантирующего билет
C
IDC: идентификатор пользователя.
IDtgs: идентификатор TGS.
TS1: отметка времени, позволяет AS проверить, синхронизированы ли часы клиента с часами AS.
AS
Tickettgs = EKas,tgs [KC,tgs, IDC, ADC, IDtgs, TS2, LТ2 ]
Tickettgs: билет, используемый клиентом для доступа к TGS.
Kc: ключ шифрования, основанный на пользовательском пароле, применение которого позволяет AS и клиентскому модулю аутентифицировать пользователя и защитить содержимое сообщения (2).
КC, tgs: ключ сессии, созданный AS для обеспечения безопасного обмена между клиентским модулем и TGS.
Kas,tgs: ключ, которым зашифрован билет и который известен только AS и TGS.
IDtgs: подтверждение того, что данный билет предназначен для TGS.
ADC: адрес пользователя, предотвращает использование билета с любой рабочей станции, кроме той, с которой он был первоначально получен.
TS2: время создания билета.
LТ2: время жизни билета.
Обмен с сервисом, гарантирующим билет, для получения билета, гарантирующего сервис
C
IDS: идентификатор сервера S.
Tickettgs: гарантирует TGS, что данный пользователь аутентифицирован AS.
Authenticatorc: создается клиентом для подтверждения законности ключа.
AuthenticatorC = EKc,tgs [IDC, ADC, TS3 ]
TS3: время создания аутентификатора.
TGS
TicketS = EKtgs,s [KC,S, IDC, ADC, IDS, TS4, LТ4]
TicketS: билет, используемый клиентом для доступа к серверу S.
Кtgs,s: ключ, разделяемый S и TGS.
КC,S: ключ сессии, который создается TGS для обеспечения безопасного обмена между клиентским модулем и сервером без необходимости разделения ими постоянного ключа.
IDS: доказательство того, что этот ключ предназначен для сервера S.
TS4: время создания билета.
LТ4: время жизни билета.
Клиент/серверный аутентификационный обмен для получения сервиса
C
TicketS = EKtgs,s [KC, S, IDC, ADC, IDS, TS4, LТ4 ]
AuthenticatorC = EKc [IDC, ADC, TS5 ]
TicketS: гарантирует серверу, что данный клиент аутентифицирован AS.
Authenticatorc: создается клиентом для подтверждения законности ключа.
TS5: время создания аутентификатора.
S
TS5 + 1: гарантирует С, что не было replay-атак.
Прежде всего, клиентский модуль посылает сообщение к AS с требованием доступа к TGS. AS отвечает сообщением, зашифрованным ключом, полученным из пароля пользователя, который содержит билет. Зашифрованное сообщение также содержит ключ сессии КC,tgs, где индексы определяют, что это ключ сессии между С и TGS. Таким образом, ключ сессии безопасно передан как С, так и TGS.
К первой фазе сценария добавлено несколько дополнительных элементов информации. Сообщение (1) включает отметку времени, так что AS знает, что сообщение своевременно. Сообщение (2) включает несколько элементов билета в форме, доступной С. Это необходимо С для подтверждения того, что данный билет предназначен для TGS и для определения момента истечения срока его действия.
Теперь, имея билет и ключ сессии, С может обратиться к TGS. Как и раньше, С посылает TGS сообщение, которое включает билет и идентификатор требуемого сервиса (сообщение (3)). Дополнительно С передает аутентификатор, который включает идентификатор и адрес пользователя С, а также отметку времени. В отличие от билета, который является переиспользуемым, аутентификатор применяется только один раз и не имеет времени жизни (LT). Теперь TGS расшифровывает билет с помощью ключа, который он разделяет с AS. Этот билет содержит ключ сессии КС,tgs. В действительности билет устанавливает, что любой, кто использует КС,tgs, должен быть С.
TGS задействует ключ сессии для дешифрования аутентификатора. TGS может затем сравнить имя и адрес из аутентификатора с тем, которое содержится в билете, и с сетевым адресом входящего сообщения. Если все совпадает, то TGS может быть уверен, что отправитель билета является настоящим его собственником. В действительности аутентификатор устанавливает, что до времени TS3 возможно использование KС,tgs. Заметим, что билет не доказывает чью-либо идентичность, а является способом безопасного распределения ключей. Аутентификатор является доказательством идентификации клиента. Так как аутентификатор может быть использован только один раз, опасности, что оппонент украдет аутентификатор для пересылки его позднее, не существует.
Сообщение (4) от TGS имеет вид сообщения (2). Сообщение зашифровано ключом сообщения, разделяемым TGS и С, и включает ключ сессии, который разделяется С и сервером S, идентификатор S и отметку времени билета. Билет включает тот же самый ключ сессии.
С теперь имеет переиспользуемый билет, гарантирующий сервис S. Когда С представляет этот билет, как и в сообщении (5), он также посылает аутентификатор. Сервер может расшифровать билет, получить ключ сессии и расшифровать аутентификатор.
Если требуется взаимная аутентификация, сервер посылает сообщение (6), в котором возвращает значение отметки времени из аутентификатора, увеличенное на единицу и зашифрованное ключом сессии. С может расшифровать это сообщение для получения увеличенной отметки времени. Так как сообщение может быть расшифровано ключом сессии, С уверен, что оно может быть создано только S. Это гарантирует С, что replay-атаки не было.
Наконец, в завершение клиент и сервер разделяют секретный ключ. Этот ключ может быть использован для шифрования будущих сообщений между ними или для обмена новым случайным ключом сессии.
Более безопасный аутентификационный протокол
Хотя описанный сценарий и решает часть проблем аутентификации в открытых сетевых окружениях, многие проблемы все еще остаются. В частности, следует решить следующие две задачи. Во-первых, сделать так, чтобы пользователю приходилось вводить пароль минимальное количество раз. Пока предполагается, что каждый билет может использоваться только один раз. Если пользователь С хочет проверить свою почту на почтовом сервере, он должен предоставить пароль для получения билета на почтовый сервер. Если С хочет проверить почту несколько раз в течение дня, каждое обращение к почтовому серверу требует повторного ввода пароля. Эту процедуру можно усовершенствовать, разрешив переиспользовать билеты. При первой входной сессии рабочая станция может запомнить полученный билет сервера и использовать его от имени пользователя в дальнейшем при доступе к этому серверу.
Однако при такой схеме пользователю необходим новый билет для каждого нового сервера. Если пользователь хочет получить доступ к серверу печати, почтовому серверу, файловому серверу и т.д., то при первом доступе к каждому серверу будет требоваться ввод пароля.
Вторая проблема состоит в том, что ранее рассмотренный сценарий включает незашифрованную передачу пароля в первом сообщении. Оппонент может перехватить пароль и использовать любой доступный данному пользователю сервис.
Для решения этих проблем рассмотрим схему, которая не допускает незашифрованных паролей, и введем новый сервер, называемый сервером предоставления билетов (ticket-granting server - TGS). Этот сценарий состоит в следующем:
Один раз при входе пользователя:
C
Один раз для каждого типа сервиса:
C
Один раз для каждого доступа к сервису:
C
Tickettgs = EKtgs [IDC, ADC, IDtgs, TS1, LT1] TicketS = EKs [IDC, ADC, IDS, TS2, LT2]
Пользователь первым делом получает билет, гарантирующий билет, Tickettgs от AS. Этот билет хранится в модуле клиента на рабочей станции пользователя.
Сервер TGS выдает билеты пользователям, которые перед этим были аутентифицированы AS. Каждый раз, когда пользователю требуется новый сервис, клиентский модуль обращается к TGS, используя предоставленный AS билет, и TGS выдает билет для конкретного сервиса. Клиентский модуль хранит каждый гарантирующий сервис билет и использует его для аутентификации на сервере всякий раз, когда требуется конкретный сервис. Рассмотрим данную схему подробнее:
Клиентский модуль запрашивает билет, гарантирующий билет, посылая идентификатор пользователя к AS вместе с идентификатором TGS, который будет в дальнейшем использоваться для получения билета, гарантирующего сервис.
AS в ответ присылает билет, зашифрованный ключом, полученным из пароля пользователя. Когда этот ответ поступает в клиентский модуль, он просит пользователя ввести свой пароль, создает ключ и пытается расшифровать полученное сообщение. Если используется корректный пароль, то билет успешно извлекается.
Так как только законный пользователь должен знать пароль, только законный пользователь и может получить билет. Таким образом, пароль используется для получения доверительной грамоты от Kerberos без передачи пароля в незашифрованном виде. Сам билет включает идентификатор и сетевой адрес пользователя и идентификатор TGS. Это соответствует первому сценарию. Необходимо, чтобы такой билет мог использоваться клиентским модулем для запроса нескольких билетов, гарантирующих предоставление сервиса. Следовательно, билет, гарантирующий билет, с одной стороны, должен быть переиспользуемым. Но с другой стороны, необходимо добиться того, чтобы оппонент не мог перехватывать этот билет и использовать его. Рассмотрим следующий сценарий: оппонент перехватывает билет и ждет до тех пор, пока пользователь не завершит регистрацию на своей рабочей станции. Тогда оппонент пытается получить доступ к этой рабочей станции или сконфигурировать свою рабочую станцию с тем же сетевым адресом, что и у законного пользователя. После этого оппонент будет иметь возможность переиспользовать билет для обмана TGS.
Чтобы этого не произошло, билет включает отметку времени, определяющую дату и время, когда был получен билет, и время жизни, определяющую величину времени, в течение которого билет является действительным (например, 8 часов). Таким образом, теперь клиентский модуль имеет переиспользуемый билет, и нет необходимости требовать от пользователя ввода пароля для получения нового сервиса. В заключении заметим, что билет, гарантирующий билет, шифруется секретным ключом, известным только AS и TGS. Это предотвращает модификацию билета. Билет повторно зашифровывается ключом, основанным на пароле пользователя. Это гарантирует, что билет может быть восстановлен только законным пользователем, прошедшим аутентификацию.
Теперь, когда клиентский модуль имеет билет, гарантирующий билет, доступ к любому серверу можно получить, выполнив шаги (3) и (4):
Клиентский модуль запрашивает билет, гарантирующий сервис. Для этой цели клиентский модуль передает TGS сообщение, содержащее идентификатор пользователя, идентификатор требуемого сервиса и билет, гарантирующий билет.
TGS расшифровывает входящий билет и проверяет успешность дешифрования по наличию своего идентификатора. Также необходимо убедиться, что время жизни данного билета не истекло. Затем TGS сравнивает идентификатор пользователя и его сетевой адрес со значениями, полученными из билета. После этого TGS выдает билет, гарантирующий доступ к нужному сервису.
Билет, гарантирующий сервис, имеет ту же структуру, что и билет, гарантирующий билет. Этот билет также содержит отметку времени и время жизни. Если пользователь захочет получить доступ к тому же самому сервису позднее, клиентский модуль может просто использовать ранее полученный билет, гарантирующий сервис, и нет необходимости повторно запрашивать пароль пользователя. Заметим, что билет зашифрован с помощью секретного ключа EKs, известного только TGS и серверу, что предотвращает его изменение.
Наконец, с билетом, гарантирующим сервис, клиентский модуль может получить доступ к соответствующему сервису:
Клиентский модуль запрашивает доступ к сервису от имени пользователя. С этой целью клиентский модуль передает сообщение серверу, содержащее идентификатор пользователя и билет, гарантирующий сервис. Сервер аутентифицирует пользователя, используя содержимое билета.
Этот новый сценарий позволяет сделать так, чтобы за время работы пользователя пароль запрашивался только один раз, и обеспечивает защиту пароля пользователя.
Флаги билета
Поле флагов, введенное в билеты в версии 5, поддерживает расширенную функциональность по сравнению с версией 4. Рассмотрим флаги, которые могут быть определены в билете (см. таб. 20.1).
Флаг INITIAL определяет, что данный билет получен от AS, а не от TGS. Когда клиент требует билет, гарантирующий сервис, от TGS, он предоставляет билет, гарантирующий билет, полученный от AS. В версии 4 это был способ, в конечном счете, получить билет, гарантирующий сервис. Версия 5 предоставляет дополнительную возможность, чтобы клиент мог получить билет, гарантирующий сервис, непосредственно от AS. Это применяется в таких, например, случаях, когда сервер изменения пароля хочет убедиться, что пароль клиента был только что проверен.
Флаг PRE-AUTHENT, если установлен, определяет, что когда AS получит первоначальный запрос (сообщение 1), он аутентифицирует клиента, прежде чем выдать билет. Строгая форма этой предаутентификации остается неспецифицированной. Например, реализация MIT версии 5 имеет предаутентификацию в виде зашифрованной отметки времени. В этом случае клиентский модуль посылает AS предаутентификационный блок, содержащий случайное число, номер версии и отметку времени и зашифрованный с использованием пароля пользователя. AS расшифровывает блок и посылает билет, гарантирующий билет, если отметка времени находится в допустимом диапазоне. Другая возможность применения данного флага состоит в использовании смарт-карт, создаваемых с постоянно меняющимся паролем, который включается в предаутентификационное сообщение. Пароли, создаваемые картой, могут быть основаны на пользовательских паролях, но затем быть преобразованы смарт-картой так, чтобы в действительности использовались одноразовые пароли. Это предотвращает атаки, основанные на легко вскрываемых паролях. Если используется смарт-карта или аналогичное устройство, это определяется флагом HW-AUTHENT.
Когда билет имеет долгое время жизни, существует опасность его кражи и последующего использования оппонентом в допустимый период.
Если используется короткое время жизни для уменьшения подобной угрозы, то может возникнуть потребность в получении новых билетов. В случае билета, гарантирующего билет, клиент может хранить секретный ключ пользователя, который не подвержен риску, или повторно запрашивать у пользователя пароль. Компромисс состоит в использовании возобновляемых билетов. Билет с установленным флагом RENEWABLE включает два срока истечения: один для данного билета и один является самым поздним допустимым значением для истекаемого времени. Если новое время находится в пределах самого позднего допустимого значения, TGS может выдать новый билет с новым временем сессии и определить время его истечения. Преимущество данного механизма состоит в том, что TGS может отказаться обновлять билет, помечая его как украденный.
Клиент может выдать запрос на предоставление AS билета, гарантирующего билет, с установленным флагом MAY-POSTDATE. Клиент может затем использовать этот билет для запроса билета от TGS с установленными флагами POSTDATED и INVALID. Впоследствии клиент может подать подтверждение на просроченный билет, чтобы сделать его действительным. Эта схема может использоваться для выполнения долгих пакетных заданий на сервере, который периодически требует билет. Клиент может один раз получить некоторое число билетов для данной сессии с несколькими значениями времени. Все, кроме первого билета, первоначально являются недопустимыми. При наступлении момента, когда требуется новый билет, клиент может сделать соответствующий билет действительным. При таком подходе клиент не будет повторно использовать свой билет, гарантирующий билет, для получения билета, гарантирующего сервис.
В версии 5 стало возможным, чтобы сервер являлся proxy для клиента, в результате чего устанавливаются верительные грамоты и привилегии клиента при запросе сервиса от другого сервера. Если клиент хочет использовать данный механизм, он требует билет, гарантирующий билет, с установленным флагом PROXIABLE. Когда такой билет предоставляется от TGS, TGS разрешает получать билет, гарантирующий сервис, с различных сетевых адресов; этот последний билет имеет установленный флаг PROXY.
Приложение, получившее такой билет, может принять его или требовать дополнительной аутентификации с тем, чтобы обеспечить след аудита.
Концепция proxy является ограниченным случаем более сильной процедуры перенаправления. Если в билете установлен флаг FORWARDABLE, TGS может выдать запрашивающему билет, гарантирующий билет с различными сетевыми адресами, и установить флаг FORWARDED. Этот билет может затем быть представлен удаленному TGS. Такая возможность позволяет клиенту получить доступ к серверу из другой области без требования того, чтобы каждый Kerberos поддерживал секретный ключ с серверами Kerberos во всех других областях. Например, области могут быть структурированы иерархически. Тогда клиент может просматриваь дерево вверх до общего узла и затем спускаться обратно до нужной целевой области. Каждый шаг прохода включает перенаправление билета, гарантирующего билет, к следующему TGS в пути.
| INITIAL | Данный билет получен с использованием AS-протокола и не получен на основе билета, гарантирующего билет |
| PRE-AUTHENT | При начальной аутентификации клиент был аутентифицирован прежде, чем был выдан билет |
| HW-AUTHENT | Протокол, используемый для начальной аутентификации, требует использования аппаратуры, ожидая ввода исключительно имени клиента |
| RENEWABLE | Говорит TGS о том, что данный используемый билет получен взамен билета, время действия которого истекло. |
| MAY-POSTDATE | Говорит TGS о том, что просроченный билет мог быть получен на основании данного билета, гарантирующего билет |
| POSTDATED | Определяет, что данный билет является просроченным; конечный сервер может проверить поле authtime, чтобы посмотреть, когда произошла первоначальная аутентификация. |
| INVALID | Определяет, что данный билет является недействительным и что прежде чем он будет использоваться, его действительность должна быть подтверждена у TGS |
| PROXIABLE | Говорит о том, что новый билет, гарантирующий сервис, с другим сетевым адресом может быть получен на основе существующего билета |
| PROXY | Определяет, что данный билет является агентом на другой сервис (proxy) |
| FORWARDABLE | Говорит TGS, что новый билет, гарантирующий билет, может быть получен на основе данного билета, гарантирующего билет |
| FORWARDED | Определяет, что данный билет является либо forwarded, либо получен на основе аутентификации, включающей forwarded билет, гарантирующий билет |
Kerberos
Kerberos является аутентификационным сервисом, разработанным как часть проекта Athena в MIT. В настоящее время Kerberos реализован также в Windows 2000. Kerberos решает следующую задачу: предположим, что существует открытое распределенное окружение, в котором пользователи, работающие за своими компьютерами, хотят получить доступ к распределенным в сети серверам. Серверы должны иметь возможность предоставлять доступ только авторизованным пользователям, т.е. аутентифицировать запросы на предоставление тех или иных услуг. В распределенном окружении рабочая станция не может быть доверенной системой, корректно идентифицирующей своих пользователей для доступа к сетевым серверам. В частности, существуют следующие угрозы:
Пользователь может получить физический доступ к какой-либо рабочей станции и попытаться войти под чужим именем.Пользователь может изменить сетевой адрес своей рабочей станции, чтобы запросы, посылаемые с неизвестной рабочей станции, приходили с известной рабочей станции.Пользователь может просматривать трафик и использовать replay-атаку для получения доступа на сервер или разрыва соединения законных пользователей.
Во всех этих случаях неавторизованный пользователь может получить доступ к сервисам и данным, не имея на то права. Для того чтобы не встраивать тщательно разработанные протоколы аутентификации на каждый сервер, Kerberos создает централизованный аутентифицирующий сервер, в чьи функции входит аутентификация пользователей для серверов и серверов для пользователей. В отличие от большинства схем аутентификации, Kerberos применяет исключительно симметричное шифрование, не используя шифрование с открытым ключом.
Существует две версии Kerberos. Наиболее широко используется версия 4. Версия 5, в которой исправлены некоторые недостатки версии 4, описана в RFC 1510.
Сначала кратко рассмотрим основной подход Kerberos. Затем будет описан аутентификационный протокол, используемый в версии 4. При этом мы рассмотрим суть подхода Kerberos, опуская некоторые детали, важные для устранения более тонких угроз безопасности. Затем рассмотрим версию 5.
в качестве алгоритма симметричного шифрования
Версия 4 Kerberos в качестве алгоритма симметричного шифрования использует DES. Рассматривая протокол в целом, трудно оценить необходимость многих содержащихся в нем элементов. Поэтому сначала рассмотрим простейший вариант протокола, затем будем добавлять отдельные элементы для ликвидации конкретных уязвимостей.
и предоставляет ряд улучшений по
Версия 5 Kerberos описана в RFC 1510 и предоставляет ряд улучшений по сравнению с версией 4. Сначала сделаем общий обзор изменений в версии 5 относительно версии 4, а затем рассмотрим протокол версии 5.
Области Kerberos
Полнофункциональное окружение Kerberos, состоящее из сервера Kerberos, некоторого числа клиентов и некоторого числа прикладных серверов, требует следующего:
Сервер Kerberos должен иметь в своей базе данных идентификаторы и пароли всех зарегистрированных пользователей, т.е. все пользователи регистрируются на сервере Kerberos.
Сервер Kerberos должен разделять секретный ключ с каждым сервером, т.е. все серверы регистрируются на сервере Kerberos.
Такое окружение называется областью (realm). Сети из клиентов и серверов в различных административных организациях обычно образовывают различные области. Однако пользователи из одной области могут нуждаться в доступе к серверам из других областей, и некоторые серверы готовы предоставлять сервисы пользователям из других областей, если эти пользователи будут аутентифицированы.
Kerberos предоставляет механизм для поддержки такой аутентификации между областями. Для двух областей, поддерживающих межобластную аутентификацию, добавлено следующее требование:
Сервер Kerberos для каждой из взаимодействующих областей разделяет секретный ключ с сервером Kerberos в другой области. Другими словами, два сервера Kerberos регистрируют друг друга.
Схема требует, чтобы сервер Kerberos в одной области доверял серверу Kerberos в другой области аутентифицировать своих пользователей. Более того, серверы во второй области также должны быть согласны доверять серверу Kerberos в первой области.
Если эти основополагающие условия выполняются, можно ввести следующий механизм доступа пользователей к серверам из других областей. Пользователю, который хочет получить сервис на сервере из другой области, необходим билет для этого сервера. Клиентский модуль следует обычным процедурам получения доступа к локальному TGS и затем запрашивает билет, гарантирующий билет, для удаленного TGS (TGS в другой области). Затем клиентский модуль вызывает удаленный TGS для получения билета, гарантирующего сервис, на требуемый сервер в области, которую обслуживает удаленный TGS.
Протокол обмена является следующим:
C
Билет, предоставляемый удаленному серверу Srem, кроме всего остального, содержит идентификатор области, в которой пользователь был аутентифицирован. Сервер определяет, является ли данный удаленный запрос законным.
При таком подходе традиционная проблема состоит в том, что если существует N областей, то должно быть [N (N - 1)]/2 безопасных обменов ключей, чтобы каждый Kerberos области мог взаимодействовать со всеми остальными Kerberos.
Причины создания Kerberos
Если пользователи используют не соединенные в сеть компьютеры, то пользовательские и системные ресурсы и файлы можно уберечь от злоумышленников, обеспечив физическую защиту каждого компьютера. Когда пользователи обслуживаются централизованной системой разделения времени, безопасность должна обеспечивать именно она. Операционная система может проводить политику управления доступом на основе идентификатора пользователя и поддерживать строго определенную процедуру входа для идентификации и аутентификации пользователя.
В условиях сетевого взаимодействия подобные сценарии неприемлемы. Наиболее общим случаем является распределенная архитектура, состоящая из рабочих станций пользователя (клиентов) и распределенных серверов. В подобном окружении могут использоваться три подхода к обеспечению безопасности:
Аутентификация пользователя на своей рабочей станции.Аутентификация пользователя на каждом сервере, к которому он должен иметь доступ.Аутентификация пользователя на специальном сервере, который выдает соответствующий билет (Ticket) для доступа на сервер.
В небольших закрытых окружениях, в которых все системы работают в единственной организации, первой и, возможно, второй стратегии оказывается достаточно. Но в более открытом окружении, где поддерживаются сетевые соединения между компьютерами, для защиты информации и ресурсов пользователей необходим третий подход. Этот третий подход поддерживается Kerberos. Kerberos предполагает наличие распределенной архитектуры клиент/сервер и использует один или более серверов Kerberos для предоставления аутентификационных сервисов.
Kerberos должен удовлетворять следующим требованиям:
Безопасность: при просмотре трафика у оппонента не должно быть возможности получить необходимую информацию для того, чтобы сыграть роль законного пользователя.Надежность: для всех сервисов, которые используют Kerberos для управления доступом, отсутствие сервера Kerberos означает отсутствие поддерживаемых сервисов. Следовательно, Kerberos должен иметь высокую надежность и реализовывать распределенную серверную архитектуру, в которой одна система может быть вспомогательной для другой.Прозрачность: в идеале пользователь не должен знать, что имеет место аутентификация, кроме того случая, когда требуется ввести пароль.Масштабируемость: система должна иметь возможность поддерживать большое число клиентов и серверов. Это требование означает, что Kerberos должен иметь модульную, распределенную архитектуру.
Для реализации этих требований Kerberos использует трехсторонний аутентификационный диалог, основанный на протоколе Нидхэма и Шредера. Такая система является доверенной в том случае, если клиенты и серверы доверяют Kerberos быть посредником при аутентификации. Этот аутентификационный диалог безопасен в той же степени, в какой безопасен сам сервер Kerberos.
Простой аутентификационный протокол
В незащищенном сетевом окружении любой клиент может использовать любой сервер в качестве сервиса. В этом случае существует очевидный риск для системы безопасности. Оппонент может попытаться представиться другим клиентом и получить неавторизованные привилегии на сервере. Для того чтобы избежать этой опасности, сервер должен иметь возможность проверить идентификацию клиента, который запрашивает сервис. Практически не представляется возможным, чтобы каждый сервер выполнял эту задачу при соединении с каждым клиентом.
Альтернативой является использование аутентификационного сервера AS, который знает пароли всех пользователей и хранит их в специальной базе данных. Кроме того, AS разделяет уникальный секретный ключ с каждым сервером. Эти ключи распределяются физически или некоторым другим безопасным способом. Рассмотрим следующий протокол, который является скорее гипотетичеким:
C
AS
C
Где:
С - клиент;
AS - аутентификационный сервер;
S - сервер;
IDC - идентификатор пользователя на С;
IDS - идентификатор S;
РС - пароль пользователя на С;
ADC - сетевой адрес С;
KS - секретный ключ шифрования, разделяемый AS и S.
В данном сценарии предполагается, что пользователь входит на рабочую станцию и хочет получить доступ к серверу S. Клиентский модуль С на пользовательской рабочей станции запрашивает пользовательский пароль и затем посылает сообщение AS, которое включает идентификатор пользователя, идентификатор сервера и пароль пользователя. AS проверяет в своей базе данных правильность пароля пользователя и то, что данному пользователю разрешен доступ к серверу S. Если обе проверки выполнены успешно, AS считает, что пользователь аутентифицирован, и должен теперь убедить сервер, что это так. Для того, чтобы это сделать, AS создает билет (ticket), который содержит идентификатор пользователя, сетевой адрес, с которого вошел пользователь, и идентификатор сервера. Этот билет шифруется с использованием секретного ключа, разделяемого AS и S.
Он посылается С. Так как билет зашифрован, его не может изменить ни С, ни оппонент.
Имея данный билет, С может теперь обращаться к S за сервисом. Для этого он посылает серверу сообщение, содержащее идентификатор C и билет. S расшифровывает билет и проверяет, совпадают ли идентификатор пользователя в билете и незашифрованный идентификатор пользователя в сообщении. Если это соответствие выполняется, то сервер считает пользователя аутентифицированным и предоставляет соответствующий сервис.
Каждая часть сообщения (3) важна. Билет зашифрован для предотвращения изменения или подделки. Идентификатор сервера IDS включается в билет, чтобы сервер мог убедиться, что он расшифровал билет корректно. IDC включается в билет, чтобы определить, что данный билет послан от имени С. Наконец, АDC служит для предотвращения следующей угрозы. Оппонент может перехватить билет, передаваемый в сообщении (2), затем использовать имя IDC и передать сообщение в форме (3) с другой рабочей станции. Сервер получит законный билет, который соответствует пользователю ID, и предоставит доступ пользователю с другой рабочей станции. Для предотвращения подобной атаки AS включает в билет сетевой адрес, с которого приходит первоначальный запрос. Теперь билет действителен только в том случае, если он передан с той же самой рабочей станции, с которой первоначально запрашивался.
предназначена для преодоления недостатков
Версия 5 предназначена для преодоления недостатков проектирования и технических недоработок версии 4.
Версия 4 Kerberos была разработана для использования в окружении проекта Athena и, следовательно, не предназначалась для использования в общих целях. Это привело к следующим недостаткам проектирования:
Зависимая система шифрования: версия 4 требует использования DES. Сначала существовали экспортные ограничения DES, в настоящий момент основным недостатком является сомнение в силе DES. В версии 5 зашифрованный текст помечен типом шифрования, что позволяет задействовать любой алгоритм симметричного шифрования. Ключ шифрования помечен типом и длиной, что также позволяет применять различные алгоритмы.Зависимость от Internet-протоколов: версия 4 требует использования IP-адресации. Другие типы адресов, такие как сетевые адреса ISO, не поддерживаются. В версии 5 сетевой адрес помечен типом и длиной, что позволяет задействовать любой тип сетевого адреса.Упорядочивание байтов сообщения: в версии 4 отправитель сообщения использует упорядочивание байтов по своему выбору и помечает сообщение, чтобы определить, левый или правый байт расположен в младшем адресе. В версии 5 структура всех сообщений определяется на основании ASN.1 и DER, что обеспечивает однозначную последовательность байтов.Время жизни билета: в версии 4 значения времени жизни хранятся в 8-битовых блоках по 5 минут. Таким образом, максимальное время жизни, которое может быть получено, есть 28 · 5 = 1280 минут или меньше 21 часа. Для некоторых приложений этого может быть недостаточно. В версии 5 билет включает явное время начала и время конца, допуская произвольное время жизни билета.Перенаправление аутентификации: версия 4 не позволяет, чтобы доверительные грамоты, полученные для одного клиента, были перенаправлены другому хосту и использовались другим клиентом. Эта особенность не дает клиенту возможность получить доступ к серверу, чтобы затем сервер получил доступ к другому серверу от имени данного клиента.
Например, клиент сделал запрос на сервер печати, после чего необходим доступ к файл-серверу за файлом клиента, с помощью доверительной грамоты клиента. Версия 5 обеспечивает такую возможность.Аутентификация между областями: в версии 4 взаимосвязь N областей требует последовательности из N2 взаимосвязей Kerberos-to-Kerberos. Версия 5 поддерживает метод, который требует меньшего числа взаимосвязей.
Существуют также следующие технические недостатки в самом протоколе версии 4:
Двойное шифрование: сообщения 2 и 4, которые поставляют клиентам билеты, зашифрованы дважды, один раз секретным ключом сервера назначения, а затем опять секретным ключом, известным клиенту. Второе шифрование не является обязательным и вычислительно расточительно.Ключи сессии: каждый билет включает ключ сессии, который используется клиентом для шифрования аутентификатора, посылаемого серверу. Дополнительно ключ сессии может впоследствии использоваться клиентом и сервером для защиты сообщений, передающихся в течение данной сессии. В версии 5 появилась возможность вести переговоры о ключе подсессии, который используется только для одного соединения. Для нового соединения будет применяться новый ключ шифрования.Атаки на пароль: одним из слабых мест, присущих обеим версиям, являются атаки на пароль. Сообщение от AS клиенту включает нечто, зашифрованное ключом, основанным на пароле клиента. Оппонент может перехватить это сообщение и попытаться расшифровать его, используя различные пароли. Если результат дешифрования будет иметь корректный формат, то это означает, что оппонент раскрыл пароль клиента и может последовательно использовать его для получения доверительной грамоты от Kerberos. Версия 5 обеспечивает механизм, называемый предаутентификацией, который затрудняет атаки на пароли, но не предотвращает их.
