Freigeben über

Kerberos: что нового?

  • Artikel

Протокол Kerberos достаточно хорошо описан в документе «How the Kerberos Version 5 Authentication Protocol Works». Реализация протокола Kerberos в Windows Server 2003 компанией Microsoft достаточно близка к стандарту RFC 1510. С тех пор прошло 10 лет. Успели выйти Windows Server 2008, 2008 R2, 2012, готовится к выходу Windows Server 2012 R2. Сам стандарт обновился до версии RFC 4120, к которому уже согласовано большое количество дополнений. К сожалению, я нигде не видел (возможно плохо искал) документа, описывающего изменения произошедшие в протоколе Kerberos и в его реализации компанией Microsoft. Поэтому попробую восполнить этот пробел.

Так как меня интересует реализация конкретного вендора, то изменения прежде всего будут привязаны к операционным системам Windows.

Windows Server 2008/Windows Vista

Улучшения следующие (отсюда и отсюда):

  • Поддержка алгоритма шифрования AES как для самого протокола аутентификации (TGT, сервисные билеты, сессионные ключи) так и для механизма клиент-серверного взаимодействия (сообщений Generic Security Service).
  • В связи с появлением роли контролеров домена только для чтения (RODC) появились отдельные учётные записи krbtgt для каждого такого контроллера с ограниченной областью действия.
  • OCSP Stapling. Позволяет снизить нагрузку на сеть при аутентификации по сертификатам, благодаря тому, что контроллер домена кеширует ответы OCSP респондера.

Сам стандарт обновился с RFC 1510 до RFC 4120. Пункт, описывавший в RFC 1510 разрешённые алгоритмы шифрования был вынесен в 2 новых стандарта – RFC 3961 и RFC 3962. OCSP Stapling описан в RFC 4557.

Из интересного относительно алгоритмов шифрования:

The following encryption and checksum mechanisms MUST be supported:

Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962]
Checksums: HMAC-SHA1-96-AES256 [RFC3962]

The following mechanisms from [RFC3961] and [RFC3962] SHOULD be supported:

Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

Относительно процедуры предварительной аутентификации:

The PA-ENC-TIMESTAMP method MUST be supported by clients, but whether it is enabled by default MAY be determined on a realm-by-realm basis. If the method is not used in the initial request and the error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an acceptable method, the client SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-authentication method.

Эта процедура реализована в Windows Server 2008/Windows Vista.

Теперь посмотрим немного подробнее на улучшения.

В свойствах учётной записи появились 2 новых пункта, связанные с AES:

kerb01

Реализовано за счёт нового аттрибута msDS-SupportedEncryptionType.

Что означают эти галки? По умолчанию они не выставлены и в учётной записи msDS-SupportedEncryptionType не задан. Это значит, что при запросе сервисного билета (сервис запускается в контексте учётной записи), по-умолчанию для его шифрования будет использоваться RC4. При включении этих опций соответствующий алгоритм шифрования будет добавлен в список поддерживаемых алгоритмов при шифровании сервисного билета.

Процедура запроса TGT увеличилась на два шага. Теперь, по умолчанию, клиент Windows Server 2008/Windows Vista в первом запросе AS-REQ НЕ отправляет в поле paData метод PA-ENC-TIMESTAMP со штампом локального времени системы клиента, зашифрованным хешем пароля пользователя.

- Kerberos: AS Request Cname: user Realm: testlab Sname: krbtgt/testlab</pre>   - AsReq: Kerberos AS Request    - KdcReq: KRB_AS_REQ (10)     - PaData: + SequenceOfHeader: + PaData: PA-PAC-REQUEST (128)

В ответ KDC возвращает KRB_ERROR c KDC_ERR_PREAUTH_REQUIRED (так как по-умолчанию преаутентификация должна быть пройдена), который содержит метод PA-ETYPE-INFO2 с указанием алгоритмов шифрования, которые поддерживает KDC.

- Kerberos: KRB_ERROR  - KDC_ERR_PREAUTH_REQUIRED (25)   - KrbError: KRB_ERROR (30)    - EData:     - MethodData: - Padata: PA-ETYPE-INFO2 (19)       - PaEtypeInfo2:        - EtypeInfo2Entry: + Etype: aes256-cts-hmac-sha1-96 (18)        - EtypeInfo2Entry: + Etype: rc4-hmac (23)        - EtypeInfo2Entry: + Etype: des-cbc-md5 (3)        - EtypeInfo2Entry: + Etype: des-cbc-crc (1)      + Padata: PA-ENC-TIMESTAMP (2)      + Padata: PA-PK-AS-REQ (16)      + Padata: PA-PK-AS-REP_OLD/ PA_PK_AS_REQ_WINDOWS_OLD/ PA_PK_AS_REP_WINDOWS_OLD (15)

Клиент отправляет AS-REQ повторно. В этот раз в запросе используется PA-ENC-TIMESTAMP с зашифрованным временем. Для шифрования выбирается самый сильный алгоритм из тех, которые прислал сервер на предыдущем шаге (в нашем случае это AES256).

- Kerberos: AS Request Cname: user Realm: testlab Sname: krbtgt/testlab   - AsReq: Kerberos AS Request    - KdcReq: KRB_AS_REQ (10)     - PaData:      - PaData: PA-ENC-TIMESTAMP (2)       - KrbEncTimestamp: Encrypted Timestamp Pre-authentication        - PaEncTsEnc: + EType: aes256-cts-hmac-sha1-96 (18)    - ReqBody:     - Etype: + EType: aes256-cts-hmac-sha1-96 (18) + EType: aes128-cts-hmac-sha1-96 (17) + EType: rc4-hmac (23) + EType: des-cbc-md5 (3) + EType: des-cbc-crc (1) + EType: rc4-hmac-exp (24) + EType: Unknown Encryption Type (0xff79)

Кроме этого в теле запроса (ReqBody) содержится последовательность поддерживаемых клиентом алгоритмов шифрования (как описано в RFC 4537). В дальнейшем будет использоваться наиболее сильный из тех, который поддерживают и клиент и KDC (в случае с Vista/Server 2008 это будет AES 256 по умолчанию). Процедура согласования алгоритмов шифрования очень подробно описана здесь.

Windows Server 2008 R2/Windows 7

Улучшения следующие (взято здесь, здесь и здесь):

  • Алгоритм шифрования DES по-умолчанию выключен. Используются AES256-CTS-HMAC-SHA1-96, AES128-CTS-HMAC-SHA1-96, RC4-HMAC.
  • Поддержка ECC (elliptic curve cryptography) при аутентификации по смарт-картам, использующим сертификаты X.509. Каких либо дополнительных настроек нет. Но оборудование должно поддерживать ECC.
  • Forest Search Order. Позволяет аутентифицироваться между разными лесами (областями Kerberos) по коротким именам (леса).

Отказ от использования DES (и части других слабых криптографических алгоритмов) прописан в RFC 6649. Впрочем, Windows никогда не использовала DES, если это специально не настраивалось через соответствующий атрибут учётной записи. Более старые версии (Windows 2000/2003/XP) использовали RC4, новые (Windows 2008/Vista/2008R2/7) используют AES. Поддержка ECC описана в RFC 5349.

При поднятии уровня домена до Windows Server 2008 R2 немного меняется процедура обработки атрибута msDS-SupportedEncryptionType. Если он пустой (по-умолчанию), то при шифровании сервисного билета будет использоваться AES (а не RC4, как в случае с Windows Server 2008).

В групповых политиках появились следующие ключи связанные с Kerberos:

  • Use forest search order
  • Require strict target SPN match on remote procedure calls

В первом указываются области Kerberos, в которых будет вестись поиск при использовании короткого имени области. Подробнее можно посмотреть здесь.

Кроме этого появилась дополнительная настройка безопасности, в которой можно выбрать используемые Керберосом алгоритмы шифрования – «Network Security: Configure Encryption types allowed for Kerberos»:

kerb04

Если эта настройка не включена, то по умолчанию будут использоваться AES и RC4 (DES по-умолчанию выключен, как я писал выше). Включая эту политику, можно задействовать произвольный набор алгоритмов шифрования для протокола Керберос.

Например, можно сильно затянуть безопасность, включив только AES256_HMAC_SHA1 (не забываем, что это приведёт к тому, что клиенты, не знающие про AES, например Windows XP, не смогут работать в домене). В этом случае число алгоритмов шифрования сильно уменьшится. KRB_ERROR вернёт:

- Kerberos: KRB_ERROR  - KDC_ERR_PREAUTH_REQUIRED (25)   - KrbError: KRB_ERROR (30)    - EData:     - MethodData:      - Padata: PA-ETYPE-INFO2 (19)       - PaEtypeInfo2:        - EtypeInfo2Entry: + Etype: aes256-cts-hmac-sha1-96 (18)        - EtypeInfo2Entry: + Etype: des-cbc-md5 (3)

При запросе билета к host/srv клиент явно заявит в EType только про поддержку AES:

- Kerberos: TGS Request Realm: TESTLAB.ORG Sname: host/windows7.testlab.org   - TgsReq: Kerberos TGS Request    - KdcReq: KRB_TGS_REQ (12)     - ReqBody:      - Etype: + EType: aes256-cts-hmac-sha1-96 (18)

Windows Server 2012/Windows 8

Улучшения следующие (взято здесь и здесь):

  • Kerberos Armoring (Flexible Authentication Secure Tunneling, FAST). Механизм защиты пользовательских данных в процессе преаутентификации. Описан в стандарте RFC 6113. Позволяет защищать KRB_AS_REQ/KRB_ERROR сессионным ключём рабочей станции, на которой происходит аутентификация пользователя. При этом, следует помнить, что механизм не применим к защите процедуры преаутентифкации самой рабочей станции.
  • Ограниченное делегирование (constrained delegation) в разных доменах/лесах. Процедура ограниченного делегирования была реализована ещё в Windows Server 2003 за счёт введения дополнительного аттрибута msDS-AllowedToDelegateTo. Но было достаточно жёсткое ограничение – механизм работал только в рамках одного домена. В Windows Server 2012 это ограничение снято. Более того, механизм работает и за пределами одного леса. То есть, фронт-энд и бэк-энд могут находиться в разных лесах. Новый аттрибут msDS-AllowedToActOnBehalfOfOtherIdentity отвечает за новый сценарий работы ограниченного делегирования. Подробнее здесь и здесь.
  • Поддержка утверждений (claims) – нового типа авторизационных данных, которые позволяют использовать помимо стандартных данных типа логина/пароля более широкий набор идентификационных данных и правил доступа. Подробно о claim’ах и о том, как с ними работать писал Дмитрий Буланов здесь, здесь и здесь.
  • Compound authentication – расширение FAST, которое позволяет клиентам использовать TGT, выданные устройствам.
  • Сжатие ресурсных групп. В предыдущих версиях Windows при выпуске TGT он содержал в поле PAC набор универсальных и глобальных групп, в которые входил пользователь. При этом, процедуре сжатия подвергались общие части SID (SID Namespace) групп, которые находились в домене пользователя. То есть по факту SID Namespace хранился только в одном экземпляре. В Windows Server 2012 сжимаются так же локальные группы в ресурсном домене и группы из SID History. Подробнее о процедуре сжатия можно посмотреть здесь, здесь и здесь. По умолчанию она включена. Но её можно выключить на контроллере домена через ключ реестра DisableResourceGroupsFields в HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kdc\Parameters. При единице сжатие выключено.
  • Увеличение размера токена. Токен теперь можно увеличить до 48Кб. Либо через правку реестра (ключ MaxTokenSize в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters), либо через групповые политики.

В групповых политиках появились следующие ключи, связанные с Kerberos:

  • KDC support for claims, compound authentication and Kerberos armoring – включение поддержки claim’ов, compound authentication и Kerberos armoring на стороне KDC.
  • Warning for large Kerberos tickets – включает появление предупреждений в логе контроллера домена, в случае когда в процессе аутентификации будут использоваться токены больше указанного размера.
  • Specify KDC proxy servers for Kerberos clients – указывает прокси-серверы KDC, которые должен использовать клиент, если он не может найти контроллер домена.
  • Disable revocation checking for the SSL certificate of KDC proxy servers – позволяет отключить проверку списка отзыва сертификатов SSL для прокси-серверов KDC.
  • Fail authentication requests when Kerberos armoring is not available
  • Support compound authentication – включение поддержки для compound authentication.
  • Set maximum Kerberos SSPI context token buffer size – позволяет задать максимальный размер токена.
  • Kerberos client support for claims, compound authentication and Kerberos armoring – включение поддержки claim’ов, compound authentication и Kerberos armoring на стороне клиента.

Продолжая закручивать гайки попробуем включить Kerberos armoring и посмотреть что получится. По-прежнему, следует помнить, что старые клиенты отвалятся, так как не умеют его использовать. Для включения надо задействовать следующие ключи:

  • KDC support for claims, compound authentication and Kerberos armoring – должна применяться к контроллерам домена, рекомендую использовать Always provide claims
  • Kerberos client support for claims, compound authentication and Kerberos armoring – должна применяться к клиентам (рабочим станциям и пользователям)
  • Fail authentication requests when Kerberos armoring is not available

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

kerb05

Аутентификация для рабочей станции пройдёт штатно, а вот с аутентификацией пользователей картина будет следующая:

kerb06

Какой пользователь и к какому сервису обращается не видно. Заглянем в сами пакеты.

Первый AS-REQ:

- Kerberos: AS Request   - AsReq: Kerberos AS Request    - KdcReq: KRB_AS_REQ (10)     - PaData: - PaData: PA-FX-Fast (136)       - PaFxFastRequest:        - ArmoredData:         - Armor:          + ArmorType: FX_FAST_ARMOR_AP_REQUEST (1)

Видно, что в PaData помещён только метод PA-FX-Fast, который по факту содержит зашифрованный сессионным ключом рабочей станции набор данных, которые при выключенном Kerberos armoring находятся в теле запроса в незашифрованном виде (имя клиента, сервиса, область Kerberos итд).

Согласно RFC 6113 (п.5.4.2) в AS-REQ PA-FX-Fast выглядит следующим образом:

PA-FX-FAST-REQUEST ::= CHOICE {armored-data [0] KrbFastArmoredReq,…}

Где KrbFastArmoredReq содержит:

KrbFastArmoredReq ::= SEQUENCE {
armor        [0] KrbFastArmor OPTIONAL,
— Contains the armor that identifies the armor key.
— MUST be present in AS-REQ.
req-checksum [1] Checksum,
— For AS, contains the checksum performed over the type
— KDC-REQ-BODY for the req-body field of the KDC-REQ
— structure;
— For TGS, contains the checksum performed over the type
— AP-REQ in the PA-TGS-REQ padata.
— The checksum key is the armor key, the checksum
— type is the required checksum type for the enctype of
— the armor key, and the key usage number is
— KEY_USAGE_FAST_REQ_CHKSUM.
enc-fast-req [2] EncryptedData, — KrbFastReq —
— The encryption key is the armor key, and the key usage
— number is KEY_USAGE_FAST_ENC.
…
}

KrbFastReq это:

KrbFastReq ::= SEQUENCE {
fast-options [0] FastOptions,
— Additional options.
padata       [1] SEQUENCE OF PA-DATA,
— padata typed holes.
req-body [2] KDC-REQ-BODY,
— Contains the KDC request body as defined in Section
— 5.4.1 of [RFC4120].
— This req-body field is preferred over the outer field
— in the KDC request.
…
}

То есть механизм защиты преаутентификационных данных, реализованный в Windows Server 2012 полностью соответствует RFC 6113. В последнем описании есть интересный пункт FastOption, в котором, например, можно указать, чтобы данные пользователя при использовании FAST не скрывались:

FastOptions ::= KerberosFlags
— reserved(0),
— hide-client-names(1)

Но по-умолчанию, этого не происходит и KDC по факту обрабатывает первичный запрос как запрос от анонимного пользователя. Процедура обработки таких запросов описана в RFC 6112:

The Kerberos response defined in [RFC4120] contains the client identity in cleartext. This makes traffic analysis straightforward. The hide-client-names option is designed to complicate traffic analysis. If the hide-client-names option is set, the KDC implementing PA-FX-FAST MUST identify the client as the anonymous principal [RFC6112] in the KDC reply and the error response.

Что интересно, высылаемый в ответ пакет KRB_ERROR так же малоинтересен злоумышленнику, так как он тоже зашифрован и все «полезные» данные прячет в этом же методе:

- Kerberos: KRB_ERROR  - KDC_ERR_PREAUTH_REQUIRED (25)   - KrbError: KRB_ERROR (30)    + ErrorCode: KDC_ERR_PREAUTH_REQUIRED (25)    - EData:     - MethodData: - Padata: PA-FX-Fast (136)       - PaFxFastReply:        - ArmoredData:         - EncFastRep:          + EType: aes256-cts-hmac-sha1-96 (18)

Вот как это описано в RFC 6113:

The KDC MUST include all the padata elements such as PA-ETYPE-INFO2 and padata elements that indicate acceptable pre-authentication mechanisms [RFC4120] in the KrbFastResponse structure.

Следующие запросы/ответы выглядят точно так же. Весь обмен ценной информацией идёт через шифрованный канал, реализованный методом PA-FX-Fast.

Полезные ссылки:
Encryption Type Selection in Kerberos Exchanges
Windows Configurations for Kerberos Supported encryption Type
Windows Logon Options in Vista/2008: Part One of Two
Windows Server 2008 Group Policy settings for interoperability with non-Microsoft Kerberos realms
Hunting down DES in order to securely deploy Kerberos
How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 1
How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2

Comments

  • Anonymous
    January 01, 2003
    Неправильно написал. Контроллер домена кеширует не списки отозванных сертификатов, а ответы OCSP респондера. Исправил в тексте. Спасибо за поправку.