2.15. Идентификация IKE_SA
Если не используется расширяемая идентификация (см. параграф 2.16), партнеры идентифицируют себя посредством подписи (или MAC с использованием разделяемого секрета в качестве ключа) для блока данных. Для ответчика подписываемые данные начинаются с первого октета первого SPI в заголовке второго сообщения и заканчиваются последним октетом последнего элемента данных во втором сообщениии. В конце к этому добавляется (с целью расчета подписи) значение nonce Ni от инициатора (просто значение, а не содержащий его элемент данных) и значение prf(SK_pr,IDr'), где IDr' — элемент ID ответчика без фиксированного заголовка. Отметим, что ни одно из значений Ni и prf(SK_pr,IDr') не передается. Подобно этому инициатор подписывает первое сообщение, начиная с первого октета первого SPI в заголовке и заканчивая последним октетом последнего элемента данных. В конце к этому добавляется (для расчета подписи) значение nonce Nr от ответчика и значение prf(SK_pi,IDi'). В приведенных выше расчетах IDi' и IDr' являются полными элементами данных ID без фиксированного заголовка. Для защиты обмена критично наличие подписи каждой стороны для nonce другой стороны.
Отметим, что подписываются все элементы данных, включая и те, которые не определены в этом документе. Если перевое сообщение в обмене передается дважды (второй раз с cookie ответчика и/или другой группой Diffie-Hellman), подписывается вторая версия сообщения.
В дополнение к спазанному сообщения 3 и 4 могут включать сертификат или цепочку сертификатов, обеспечивающие очевидность того, что использованные для расчета цифровой подписи ключ относится к имени в элементе данных ID. Сигнатрура или MAC будет рассчитываться с использованием алгоритмов, диктуемых типом ключа, используемого подписывающим, и задается полем Auth Method в элементе данных Authentication. Здесь не задается использования одного криптографического алгоритма для инициатора и ответчика. Выбор криптографического алгоритма зависит от типа ключа, который имеет каждая из сторон. В частности, инициатор может использовать разделяемый ключ, а ответчик может иметь открытый ключ подписи и сертификат. Обычной (но не обязательной) практикой при наличии разделяемого ключа является использование этого ключа для идентификации в обоих направлениях. Отметим, что общепринято, хотя и не обеспечивает достаточной защиты, использование разделяемого ключа, созданного исключитьельно на базе выбранного пользователем пароля без использования других источников случайных данных.
Такая защита недостаточна, поскольку пользовательские пароли с очевидностью не являются достаточно непредсказуемыми для устойчивости к атакам по словарю, следовательно данный метод от таких атак не защищает (приложениям, использующим идентификацию по паролю на этапе загрузки и IKE_SA, следует применять метод идентификации, описанный в параграфе 2.16, который предназначен для защиты от атак по словарю в режиме off-line). Разделяемый (pre-shared) ключ следует делать столь же непредсказуемым, как наиболее сильный из согласуемых ключей. В случае pre-shared-ключа значение AUTH вычисляется, как:
AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
где сторока «Key Pad for IKEv2» представляет собой 17 символов ASCII без завершающего нуля. Разделяемый секрет (shared secret) ) может иметь переменный размер. Строка заполнения добавляется для того, чтобы при использовании разделяемого секрета на основе пароля реализации IKE не требовалось сохранять пароль в открытом виде, а можно было хранить его в форме prf(Shared Secret,"Key Pad for IKEv2"), которая не будет использоваться в качестве пароля для отличных от IKEv2 протоколов. Как отмечено выше, создание разделяемого ключа на основе пароля не обеспечивает должной защиты. Такая конструкция отмечена лишь потому, что многие люди ей пользуются до сих пор. Интерфейс управления, через который обеспечивается Shared Secret, должен принимать стороки символов ASCII размером, по крайней мере, 64 октета; добавление завершающего нуля перед использованием строки в качестве разделяемого секрета недопустимо. Интерфейс управления должен также воспринимать разделяемый секрет в шестнадцатеричном (HEX) представлении. Интерфейс управления может воспринимать другие варианты кодировки строки, если указан алгоритм преобразования в двоичную строку. Если согласованная функция prf принимает ключ фиксированного размера, разделяемый секрет должен иметь такой же размер.