Network Working Group Request for Comments: 2554 Category: Standards Track
J. Myers
Netscape Communications
March 1999
Расширение сервиса SMTP для аутентификации
SMTP Service Extension for Authentication
Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Введение
Этот документ определяет расширение сервиса SMTP [ESMTP], посредством которого клиент SMTP может указать серверу механизм аутентификации, провести обмен данными протокола аутентификации и дополнительно согласовать уровень защиты для последующих транзакций протокола. Это расширение является вариантом SASL1 [SASL].
2. Используемые в документе соглашения
В примерах строки "C:" и "S:" показывают строки, передаваемые клиентом и сервером, соответственно.
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), следует (SHOULD), не следует (SHOULD NOT), возможно (MAY) в данном документе должны интерпретироваться в соответствии с документом "Ключевые слова для обозначения уровня требований в RFC" [KEYWORDS].
3. Расширение для аутентификации
(1)  Имя расширения сервиса SMTP - Authentication
(2)  Ключевое слово EHLO, связанное с этим расширением, - AUTH
(3)  Ключевое слово AUTH EHLO содержит в качестве параметра список разделенных пробелами имен поддерживаемых механизмов SASL.
(4)  Определяется новая команда (verb) SMTP – AUTH.
(5)  Дополнительный параметр, использующий ключевое слово AUTH, добавляется к команде MAIL FROM и максимальный размер этой команды расширяется до 500 символов.
(6)  Данное расширение подходит для протокола подачи сообщений [SUBMIT].
4. Команда AUTH
AUTH mechanism [initial-response] Аргументы
Строка, идентифицирующая механизм аутентификации SASL. В строку может также включаться необязательный отклик, представленный в формате base64.
Ограничения
После успешного выполнения команды AUTH в той же сессии не могут вводиться дополнительные команды AUTH. После успешного выполнения команды AUTH сервер должен отвергать любые последующие команды AUTH с возвратом кода 503.
Команды AUTH не допускаются в процессе выполнения почтовых транзакций.
Обсуждение
Команда AUTH показывает серверу механизм аутентификации. Если сервер поддерживает запрошенный механизм, он выполняет обмен данными протокола аутентификации и идентифицирует пользователя. В дополнение к этому может согласовываться уровень защиты для последующих транзакций протокола. Если запрошенный механизм аутентификации не поддерживается, сервер отвергает команду AUTH с возвратом кода 504.
Обмен данными протокола аутентификации состоит из последовательности запросов (challenge) сервера и откликов (answer) клиента, определяемых используемым механизмом аутентификации. Запрос сервера (server challenge), называемый также индикацией готовности (ready response) представляет собой код 334 с текстом, содержащим строку в коде BASE64. Ответ
1Simple Authentication and Security Layer
ровень простой аутентификации и защиты.
Перевод RFC 2554
клиента состоит из строки в коде BASE64. Если клиент отказывается от аутентификационного обмена, он возвращает строку, содержащую только символ *. Если сервер получает такой отклик, он должен отвергнуть команду AUTH и возвратить код 501.
Необязательный аргумент initial-response в команде AUTH служит для “замыкания круга” (round trip) при использовании механизмов аутентификации, которые не передают данных в начальном запросе (initial challenge). При использовании аргумента initial-response с таким механизмом клиенту не передается пустой изначальный запрос и вместо этого сервер передает данные, указанные параметром initial-response, как будто он шлет их в ответ на пустой запрос. В отличие от пустого (zero-length) ответа клиента на код 334 пустой изначальный отклик передается в виде одного символа – знака равенства (=). Если клиент использует в команде AUTH параметр initial-response для механизма, который передает данные в изначальном запросе, сервер отвергает команду AUTH с возвратом кода 535.
Если сервер не может декодировать аргумент BASE64, он отвергает команду AUTH с возвратом кода 501. Если сервер отвергает аутентификационные данные, ему следует отвергнуть и команду AUTH с возвратом кода 535, если нет подходящего более специфичного кода из числа перечисленных в главе 6. Для успешного завершения клиентом процесса обмена аутентификационными данными, сервер SMTP возвращает код 235.
Имя сервиса, задаваемое данным вариантом SASL, - smtp.
Если в процессе аутентификационного обмена SASL согласуется уровень защиты, он вступает в силу сразу же после последовательности CRLF, завершающей аутентификационный обмен для клиента и CRLF в отклике о позитивном результате для сервера. После вступления в силу уровня защиты протокол SMTP сбрасывается в начальное состояние (состояние SMTP после возврата сервером кода готовности 220). Сервер должен отбрасывать любые полученные от клиента данные (такие, как аргументы команды EHLO), которые не были получены непосредственно из согласования SASL. Клиент должен отбрасывать любую полученную от сервера информацию (такую, как список расширений сервиса SMTP), которая не была получена непосредственно из согласования SASL (исключением является возможность клиента сравнивать список анонсируемых механизмов SASL до и после аутентификации для детектирования активных атак по срыву согласования2). Клиенту следует передавать EHLO в качестве первой команды после успешного завершения SASL-согласования, которое приводит к включению уровня защиты.
От сервера не требуется поддержки любого конкретного механизма аутентификации или механизмов аутентификации, требуемых для поддержки любых уровней защиты. При отказе, полученном в ответ на команду AUTH, клиент может попытаться использовать другой механизм аутентификации с помощью новой команды AUTH.
При отказе от выполнения команды AUTH сервер должен вести себя так, как будто клиент не вводил команду AUTH совсем.
Строка BASE64 в общем случае может иметь произвольную длину. Клиенты и серверы должны поддерживать строки запросов и откликов такого размера, который использует поддерживаемый ими механизм аутентификации, независимо от всех прочих ограничений на размер, которые могут вносить другие компоненты реализации протокола для сервера или клиента.
Примеры
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
5. Параметр AUTH в команде the MAIL FROM
AUTH=addr-spec Аргументы
Параметр addr-spec указывает “личность” (identity) подающего сообщение в систему доставки или содержит два символа <>, показывающие, что “личность” неизвестна или недостаточно аутентифицирована. С учетом ограничений, накладываемых на параметры ESMTP значение addr-spec кодируется в xtext. Синтаксис xtext описан в главе 5 документа [ESMTP-DSN].
Обсуждение
Необязательный параметр AUTH в команде MAIL FROM позволяет кооперировать агенты, находящиеся в защищенной среде для аутентификации отдельных сообщений.
Если сервер доверяет аутентифицированной “личности” клиента, заявляющего, что сообщение уже было изначально подано addr-spec, серверу следует передать это значение addr-spec в параметре AUTH при трансляции сообщения любому серверу, который поддерживает расширение AUTH.
Команда MAIL FROM с параметром AUTH=<> показывает, что изначально подавший сообщение неизвестен. Для сервера недопустимо трактовать такое сообщение как изначально поданное клиентом.
Если параметр AUTH не включен в команду MAIL FROM, клиент аутентифицирован и сервер полагает, что сообщение было изначально подано клиентом, сервер может указать “личность” клиента как addr-spec в параметре AUTH при трансляции сообщения любому серверу, который поддерживает расширение AUTH.
Если сервер не совсем доверяет аутентифицированной “личности” клиента или клиент попросту не аутентифицирован, сервер должен вести себя как при получении параметра AUTH=<>. Сервер может в таких случаях записать значение AUTH в системный журнал.
Если параметр AUTH=<> задан явно или в результате выполнения требований предыдущего параграфа, сервер должен указать параметр AUTH=<> при трансляции сообщения любому серверу, который поддерживает расширение AUTH.
2down-negotiation attack
rfc.com.ru                                                                                     2                                                            rfc.com.ru
Перевод RFC 2554                                                                                             
Сервер может трактовать расширение3 списка рассылки как новую подачу, указывая в параметре AUTH адрес списка рассылки или администратора этого списка при трансляции сообщения получателям.
Реализация может трактовать всех клиентов как недостаточно доверенных в этом случае реализация не делает ничего кроме разбора и отбрасывания синтаксически корректных параметров AUTH команды MAIL FROM и указания AUTH=<> всем серверам, использующим расширение AUTH.
Примеры
C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com S: 250 OK
6. Коды ошибок
Перечисленные ниже коды ошибок могут использоваться для индикации соответствующих условий.
432 A password transition is needed
такой отклик на команду AUTH показывает, что пользователю нужно перейти к выбранному механизму аутентификации. Обычно это делается путем однократного использования механизма аутентификации PLAIN.
534 Authentication mechanism is too weak
Этот отклик на команду AUTH показывает, что выбранный механизм аутентификации слабее, чем сервер может позволить для этого пользователя.
538 Encryption required for requested authentication mechanism
Этот отклик на команду AUTH показывает, что выбранный механизм аутентификации может использоваться только для шифрованных соединений SMTP.
454 Temporary authentication failure
Этот отклик на команду AUTH показывает, что аутентификация завершилась неудачей в результате временных проблем на сервере.
530 Authentication required
Этот отклик может возвращаться любой командой, за исключением AUTH, EHLO, HELO, NOOP, RSET и QUIT. Он показывает, что политика сервера требует аутентификации для выполнения запрошенной операции.
7. Формальный синтаксис
Спецификация формального синтаксиса использует расширенную нотацию Бэкуса-Наура (BNF), описанную в документе [ABNF].
За исключением явно указанных случаев регистр символов для букв не принимается во внимание. Использование строчных и прописных букв обусловлено исключительно наглядностью. Реализации должны принимать эти строки независимо от регистра символов.
UPALPHA = %x41-5A
LOALPHA = %x61-7A
ALPHA                       = UPALPHA / LOALPHA
DIGIT                       = %x30-39
HEXDIGIT = %x41-46 / DIGIT
верхний регистр: A-Z
нижний регистр: a-z
регистр не имеет значения
цифры 0-9
шестнадцатеричные цифры (верхний регистр для A - F)
hexchar = "+" HEXDIGIT HEXDIGIT
xchar                       = %x21-2A / %x2C-3C / %x3E-7E
;; символы US-ASCII за исключением "+", "=", пробела и CTL xtext                       = *(xchar / hexchar)
AUTH_CHAR = ALPHA / DIGIT / "-" / "_" auth_type = 1*20AUTH_CHAR
auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] *(CRLF [base64]) CRLF auth_param = "AUTH=" xtext
;; декодированная форма xtext ДОЛЖНА совпадать с addr-spec или "<>" base64 = base64_terminal / ( 1*(4base64_CHAR) [base64_terminal] ) base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; регистр принимается во внимание base64_terminal = (2base64_char "==") / (3base64_char "=") continue_req = "334" SPACE [base64] CRLF
CR                              = %x0C                       ;; ASCII CR (возврат каретки)
CRLF                         = CR LF
CTL                           = %x00-1F / %x7F
LF                              = %x0A
SPACE                       = %x20
все коды управления ASCII, а также символ DEL ASCII LF (перевод строки) ASCII SP (пробел)
8. Литература
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 22344, November 1997.
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 21195, March 1997.
3Извлечение адресов конкретных получателей из сообщения, направленного по адресу списка рассылки. Прим. перев. 4Этот документ устарел и заменен RFC 4234. Перевод имеется на сайте http://rfc.com.ru. Прим. перев. 5Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.
rfc.com.ru                                                                          3                                                                        rfc.com.ru
Перевод RFC 2554
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 22226, October 1997.
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 24766, December 1998.
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 8217, August 1982.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
9. Вопросы безопасности
В этом документе затрагиваются вопросы безопасности.
Если клиент использует это расширение для создания шифрованного туннеля через открытую сеть до корпоративного сервера требуется обеспечить такую настройку клиента, чтобы почта никогда не передавалась на этот сервер без соответствующей аутентификации и шифрования. В противном случае атакующий сможет красть клиентскую почту путем захвата соединений SMTP и ложной индикации отсутствия на сервере поддержки данного расширения или генерации ложных отказов от выполнения команд AUTH.
До начала согласования SASL все протокольные транзакции выполняются в открытом виде и могут быть изменены в результате активной атаки. По этой причине клиенты и серверы должны отбрасывать любые сведения, полученные до начала согласования SASL после того, как будет завершено SASL-согласование, приводящее к использованию защищенного уровня.
Этот механизм не защищает порт TCP, поэтому при активной атаке возможно перенаправить попытки соединения с портом транслятора в порт подачи сообщений [SUBMIT]. Параметр AUTH=<> предотвращает для таких атак возможность заставить транслируемое сообщение без аутентификации конверта “подбирать” аутентификацию клиента транслятора.
Клиент подачи сообщений может требовать от пользователя аутентификации всякий раз, когда анонсируется подходящий механизм SASL. Следовательно, для сервера подачи сообщений [SUBMIT] может оказаться нежелательным анонсирование механизма SASL в тех случаях, когда использование этого механизма не дает клиенту преимуществ по сравнению с анонимной подачей сообщений.
Это расширение не предназначено для замены сквозных систем поддержки цифровых подписей или шифрования типа S/MIME или PGP. Данное расширение предназначено для решения иных задач и ниже перечислены основные отличия от сквозных (end-to-end) систем:
(1)  данное расширение в общем случае полезно только на защищенных территориях;
(2)  это расширение защищает “конверт” сообщения в целом, а не только тело сообщения;
(3)  расширение аутентифицирует подачу сообщений, а не подтверждает авторство содержимого письма;
(4)  расширение может дать отправителю некоторые гарантии того, что сообщение будет доставлено на следующий этап (next hop) в тех случаях, когда отправитель имеет взаимную аутентификацию со следующим этапом и согласовал подходящий уровень безопасности.
Дополнительное рассмотрение вопросов безопасности приводится в спецификации SASL [SASL].
10. Адрес автора
John Gardiner Myers
Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View, CA 94043 EMail: jgmyers@netscape.com
Перевод на русский язык Николай Малых
11. Полное заявление авторских прав
Copyright (C) The Internet Society (1999). 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.
6Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.
7Этот документ признан устаревшим и заменен RFC 2821. Перевод имеется на сайте http://rfc.com.ru. Прим. перев.
rfc.com.ru                                                                                     4                                                            rfc.com.ru