| Network Working Group M. Swift
Request for Comments: 3244 University of Washington
Category: Informational J. Trostle
Cisco Systems
J. Brezak
Microsoft
February 2002
Протоколы Microsoft Windows 2000 Kerberos Смены Пароля
(Change Password) и Установки Пароля (Set Password)
Статус данного документа
Этот документ создан в информационных целях для сообщества Internet.
Он не определяет никакого стандарта Internet. Распространение этого
документа не ограничивается.
Авторское право
Copyright (C) The Internet Society (2002). Все права защищены.
Резюме
Этот документ описывает протоколы Установки и Смены Пароля Microsoft
2000 Kerberos. Протокол смены пароля Windows 2000 Kerberos использует
стандартный протокол смены пароля Kerberos. Смена пароля это ответ на
запрос по протоколу, который включает заголовок KRB_PRIV, который
содержит новый пароль пользователя.
1. Введение
Протокол смены пароля Windows 2000 Kerberos использует стандартный
протокол смены пароля Kerberos. Смена пароля это ответ на запрос по
протоколу, который включает заголовок KRB_PRIV, который содержит
новый пароль пользователя. Оригинальный протокол смены пароля не
позволяет администратору установить пароль для нового пользователя.
Эта возможность была бы полезной в некоторых случаях, и данное
предложение дополняет протокол смены пароля возможностью установки
пароля. Изменения следующие: добавить новый флаг, определяющий
установлен ли пароль, в тело запроса, не требуя его наличия в
билете Kerberos, использовать новый номер версии протокола, и
добавить три новых кода.
2. Протокол
Служба слушает UDP и TCP запросы на 464 порту. Протокол состоит из
отдельного сообщения запроса и следующего за ним отдельного сообщения
ответа на запрос. Для протокола UDP каждое сообщение должно полностью
содержаться в единственном UDP пакете.
Для протокола TCP сообщению предшествуют 4 заголовка октета, которые
определяют его длину.
Сообщение запроса
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| длина сообщения | номер версии протокола |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REQ длина | AP_REQ данные /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV сообщение /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Все 16 битные поля определены в big-endian порядке.
поле длины сообщения: содержит количество байтов в сообщении, включая
это поле.
номер версии протокола: содержит шестнадцатеричную константу 0xff80
(big-endian целая).
AP-REQ длина: длина AP-REQ данных, в байтах. Если длина равна нулю,
то последнее поле содержит сообщение об ошибке KRB-ERROR вместо
сообщения KRB-PRIV.
AP-REQ данные: (см. [1]) AP-REQ сообщение предназначается для
основной службы kadmin/changepw@REALM, где REALM - REALM
пользователя желающего установить/сменить пароль. Аутификатор в
AP-REQ должен включать ключ подсеанса. (Примечание: ключ подсеанса
должен быть псевдослучайно сгенерированным и никогда не
использоваться для многократной аутификации.) Чтобы включить
возможность установки пароля не требуется чтобы флаг был поставлен
в билете службы Kerberos.
KRB-PRIV сообщение (см. [1]) Это поле пользовательских данных,
зашифрованных используя ключ, полученный от аутификатора в поле
данных AP-REQ. Поля usec и seq-number KRB-PRIV сообщения присутствуют
и имеют такое же значение, как и аутификатор в поле данных AP-REQ
(поле seq-number в аутификаторе будет существовать). Сервер
игнорирует необязательное поле r-address в KRB-PRIV сообщении, если
оно определено.
Компонент пользовательских данных сообщения имеет следующую ASN.1
структуру, закодированную как строка октета:
ChangePasswdData ::= SEQUENCE {
newpasswd[0] OCTET STRING,
targname[1] PrincipalName OPTIONAL,
targrealm[2] Realm OPTIONAL
}
Сервер должен проверить AP-REQ сообщение, авторизован ли клиент-
инициатор, указанный в билете, устанавливать/менять пароль (или сам
клиент, или тот, который указан в поле targname в билете, если это
поле присутствует), и расшифровать новый пароль. Сервер также
проверяет требуется ли начальное значение поля для этого запроса, и
отвечает сообщением с кодом 0x0007, если значение не установлено, но
должно быть. Ответ с кодом 0x0005 означает то, что авторизация
прошла неудачно. Для соблюдения обратной совместимости сервер должен
быть готов игнорировать поля следующие за полем targrealm, если он
их не понимает.
Поле newpasswd содержит пароль в незашифрованном (чистом) виде,
сервер применяет политики безопасности пароля, определенные
администратором. Затем сервер шифрует пароль и хранит его в базе
данных KDC. Если все прошло удачно сервер посылает клиенту сообщение
с кодом 0x0000 (см. ниже).
Сообщение ответа
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| длина сообщения | номер версии протокола |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REP длина | AP_REP данные /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV сообщение /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Все 16 битные поля определены в big-endian порядке.
поле длины сообщения: содержит количество байтов в сообщении, включая
это поле.
номер версии протокола: содержит шестнадцатеричную константу 0x0001
(big-endian целая). (Сообщение ответа имеет такой же формат как и
оригинальной протокол смены пароля.)
AP-REP длина: длина AP-REP данных, в байтах. Если длина равна нулю,
то последнее поле содержит сообщение об ошибке KRB-ERROR вместо
сообщения KRB-PRIV.
AP-REP данные: это ответ на пакет запроса AP-REQ
KRB-PRIV сообщение: Сообщение KRB-PRIV должно быть зашифровано с
использованием ключа полученного от аутификатора в поле данных
AP-REQ.
Сервер отвечает KRB-PRIV сообщением. Если сервер не может
расшифровать AP-REQ или KRB-PRIV сообщение, то ответом будет
сообщение об ошибке KRB-ERROR. Примечание: в отличии от стандартного
протокола смены пароля версии 1, сообщение KRB-ERROR будет послано
назад без любых инкапсуляций.
Пользовательские данные KRB-PRIV сообщения или компонент данных
сообщения KRB-ERROR состоит из следующей информации.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| код результата | строка результата /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
код результата (16 бит) (коды результата 0-4 из оригинального
протокола смены пароля):
Код результата должен иметь одно из следующих значений
(целое, big-endian):
KRB5_KPASSWD_SUCCESS 0 результат успешен (в KRB-ERROR
отсутствует)
KRB5_KPASSWD_MALFORMED 1 запрос неправильно сформирован
KRB5_KPASSWD_HARDERROR 2 во время запроса произошла
аппаратная ошибка (например
устройство занято во время
запроса)
KRB5_KPASSWD_AUTHERROR 3 ошибка во время аутификации
KRB5_KPASSWD_SOFTERROR 4 ошибка программного обеспечения
KRB5_KPASSWD_ACCESSDENIED 5 неавторизованный запрос
KRB5_KPASSWD_BAD_VERSION 6 версия протокола не
поддерживается
KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 требуется флаг инициализации
В случае какой либо другой причины кодом ответа будет 0xFFFF.
Несмотря на то что всего ненулевых несколько кодов результата
определены, код ответа может быть другим. В этом случае они должны
приниматься клиентом и считаться неуспешными.
строка результата:
Это поле содержит информацию которая может быть полезной
пользователю, такую, например, как возврат по неудовлетворению
политикам безопасности. Строка имеет кодировку UTF-8. Данное поле
может быть пустым, если сервер не имеет дополнительной информации
для пользователя, если присутствует - пользователю будет отослано
это сообщение.
3. Соображения безопасности
Политики безопасности паролей должны быть такими, чтобы максимально
исключить возможность взлома пароля методом перебора. Администратор
имеющий полномочия менять пароли другим пользователям должен быть
доверенным лицом, и, также, следить за тем чтобы его пароль не попал
в чужие руки.
4. Ссылки
[1] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
5. Авторские адреса
Mike Swift
University of Washington
Seattle, WA
EMail: mikesw@cs.washington.edu
Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
EMail: john3725@world.std.com
John Brezak
Microsoft
1 Microsoft Way
Redmond, WA 98052
EMail: jbrezak@microsoft.com
6. Авторское право
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
| ||
Andy © 2002-2004, 2009-2021