SPKM — Википедия WikiZero

SPKM (англ. The Simple Public-Key GSS-API Mechanism — простой механизм^[1] GSS-API на основе инфраструктуры с открытым ключом) — сетевой протокол, обладающий инфраструктурой с открытым, а не симметричным ключом. Протокол применяется для аутентификации, формирования ключей, сохранения целостности и конфиденциальности данных.

История и причины появления[править | править код]

В сентябре 1993 года была опубликована первая версия GSS-API^[2]^[3], и к этому же времени появляется механизм Kerberos V5^[4]. Но несмотря на то, что Kerberos 5 стал широко используемым, устоявшимся во многих системах протоколом, в некоторых приложениях было необходимо иметь GSS-API, построенный на инфраструктуре с открытыми, а не симметричными ключами. Это привело к созданию Карлайлом Адамсом (Carlisle Adams) в октябре 1996 года протокола SPKM (его первых двух разновидностей). Однако, при создании в 2000 году NFSv4 возникла проблема взаимной аутентификации и создания защищённого канала между анонимным пользователем и сервером, что привело к появлению SPKM-3.

Особенности протокола[править | править код]

Протокол дает возможность использовать как одностороннюю, так и взаимную (двустороннюю) аутентификацию без использования меток доверенного времени. Это позволяет даже системам, не имеющим доступа к доверенному времени, тем не менее пользоваться безопасной проверкой подлинности.
Также протокол использует идентификаторы алгоритмов для согласования алгоритмов, используемых общающимися сторонами, что делает его достаточно гибким при использовании в разных средах и по отношению к будущим изменениям в алгоритмах.
Разрешает использование электронных подписей, основанных на асимметричных алгоритмах, а не контрольную сумму целостности, использующую MAC, полученный с помощью симметричного алгоритма (например, DES).
SPKM поддерживает возможность инициатора остаться неизвестным в то время как целевой пользователь аутентифицирован, это желательная (или необходимая) опция аутентификации в некоторых средах.
Управление ключами, используемое в данном механизме подразумевает совместимость как с X.509, так и с PEM.
В процессе установления соединения в протоколе возможна полная договорённость сторон по алгоритмам конфиденциальности и целостности данных, алгоритмам создания ключей. В результате среда может поддерживать любое число взаимосогласованных, конфиденциальных и целостных алгоритмов, которые могут быть выбраны приложением свои на каждое сообщение, в зависимости от индивидуальных требований по защите.
Форматы данных и процедуры SPKM и Kerberos схожи друг с другом, что упрощает внедрение SPKM в среде, использующей протокол Kerberos.^[5]

Из выше перечисленных свойств следует, что SPKM обладает гибкостью и функциональностью, без излишней сложности и накладных расходов на внедрение. Так как SPKM соответствует GSS-API, то он может быть использован приложением в качестве альтернативного сетевого протокола безопасности (например вместо Kerberos)^[6].

Обзор[править | править код]

Описание общего программного интерфейса служб безопасности (GSS-API), согласно можно разделить на 2 части^[2]:

Документы, определяющие конкретные привязки параметров для конкретных языковых сред.
Документы, определяющие форматы маркеров^[7], протоколов и процедур, которые будут исполняться в процессе реализации сервисов GSS-API над конкретными механизмами безопасности.

SPKM является примером последнего типа документов, и поэтому называется «GSS-API механизм». Этот механизм обеспечивает проверку подлинности, создание ключей, целостность данных, и конфиденциальность данных в распределённых приложениях в режиме онлайн, с использованием инфраструктуры открытых ключей. SPKM может быть использован, как замена любому другому приложению, использующему службы безопасности через GSS-API вызовы (например, приложение, которое уже использует Kerberos GSS-API). Использование инфраструктуры открытых ключей позволяет использовать электронные подписи для поддержания невозможности отказа от авторства при обмене сообщениями, а также предоставляет другие преимущества, такие как масштабируемость для больших групп пользователей.

Маркеры, определённые в SPKM, предназначены для использования прикладными программами в соответствии с рабочей парадигмой GSS-API^[2]. Она работает следующим образом. Обычно GSS-API вызывается сетевым протоколом (или приложением его использующим) для того, чтобы защитить соединение с помощью аутентификации, служб обеспечения конфиденциальности и/или целостности данных. При вызове GSS-API протокол (приложение) принимает маркеры, предоставленные ему своей (локальной) реализацией GSS-API (то есть GSS-API механизмом), и передаёт маркеры на удалённую систему, на том конце происходит получение маркера и его дальнейшая обработка уже своим GSS-API механизмом. Таким образом, GSS-API сам по себе не обеспечивает сервисов безопасности, вместо этого он обеспечивает интерфейс между приложениями и реализациями GSS-API (механизмами). А они в свою очередь обеспечивают совместимый с GSS-API интерфейс, позволяя создавать приложения, способные работать с разными механизмами безопасности; позволяя заменять механизмы без необходимости переписывать приложения.

Алгоритмы[править | править код]

Для того чтобы обеспечить хотя бы минимальную совместимость между различными реализациями SPKM, один из алгоритмов целостности был сделан обязательным (MANDATORY), а все остальные алгоритмы и примеры поддерживаются различными реализациями опционально, некоторые алгоритмы также обозначены как рекомендуемые (RECOMMENDED), это сделано для увеличения совместимости^[6].

В протоколе SPKM используются следующие алгоритмы:

Целостности данных — I-ALG
Конфиденциальности — C-ALG
Образования ключа — K-ALG
Получения подключей — O-ALG

Алгоритмы целостности данных[править | править код]

Используются, чтобы убедится, что данные не были изменены третьей стороной. В зависимости от алгоритма, может обеспечивать также достоверность и невозможность отказа от авторства сообщения.

В качестве примеров могут использоваться следующие алгоритмы (ниже указаны идентификаторы алгоритмов):

md5WithRSAEncryption OBJECT IDENTIFIER ::= {           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)           pkcs-1(1) 4        //заимствовано из PKCS#1         }

Данный алгоритм является обязательным (MANDATORY) для SPKM. Он обеспечивает целостность и подлинность данных, а также невозможность отказа от авторства, вычисляя электронную RSA подпись на основе MD5 хеш-функции. Так как на данный момент этот алгоритм является единственным обязательным алгоритмом проверки целостности и подлинности, то для обеспечения взаимодействия было также предусмотрено, чтобы md5WithRSA был алгоритмом подписи всех маркеров установления соединения, в которых целостность проверяется с помощью подписи, а не на основе MAC. Возможно в будущем появятся и другие обязательные алгоритмы, и тогда это условие, накладываемое на маркеры исчезнет^[6].

DES-MAC OBJECT IDENTIFIER ::= {            iso(1) identified-organization(3) oiw(14) secsig(3) //хранит длину MAC в битах как целое число,            algorithm(2) 10                                     //ограниченное кратными 8, от 16 до 64         }

Этот алгоритм является рекомендуемым (RECOMMENDED), целостность обеспечивается посредством использования MAC на основе DES.

md5-DES-CBC OBJECT IDENTIFIER ::= {            iso(1) identified-organization(3) dod(6) internet(1)            security(5) integrity(3) md5-DES-CBC(1)         }

Здесь целостность данных обеспечивается шифрованием на основе DES-CBC и «замешанного» MD5-хеширования. Это на практике быстрее, чем вычисление DES-MAC, если входные данные малы (порядка нескольких байт). Заметим, что без «замешивания» стойкость целостности механизма не более или равна стойкости DES при атаке с известным открытым текстом.

sum64-DES-CBC OBJECT IDENTIFIER ::= {            iso(1) identified-organization(3) dod(6) internet(1)            security(5) integrity(3) sum64-DES-CBC(2)         }

Данный алгоритм обеспечивает целостность данных посредством шифрования с помощью DES CBC. Конкатенация «замешанных» данных и суммы всех входных блоков данных (сумма вычисляется с помощью сложения по модулю 2⁶⁴ — 1). Таким образом, в этом алгоритме шифрование является необходимым условием обеспечения целостности данных^[6].

Алгоритмы конфиденциальности[править | править код]

Эти симметричные алгоритмы используются для шифрования данных для вызовов GSS-API : gss_seal() / gss_wrap().

Пример:

DES-CBC OBJECT IDENTIFIER ::= {            iso(1) identified-organization(3) oiw(14) secsig(3)            algorithm(2) 7          }

Этот алгоритм является рекомендуемым (RECOMMENDED).

Алгоритмы образования ключа[править | править код]

Используются для создания симметричного ключа используемого узлами во время соединения. Далее из этого ключа создаются подключи для алгоритмов целостности и конфиденциальности. Создание ключа проходит во время обмена аутентификациями по стандарту X.509, так что полученный симметричный ключ является аутентифицированным.

Примеры:

RSAEncryption OBJECT IDENTIFIER ::= {           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)           pkcs-1(1) 1        // заимствовано из PKCS#1 и RFC-1423         }

В этом обязательном (MANDATORY) алгоритме ключ соединения создаётся его инициатором с помощью открытого RSA ключа цели и посылается ей. Цели, в свою очередь, не обязательно отвечать, чтобы ключ был создан.

dhKeyAgreement OBJECT IDENTIFIER ::= {           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)           pkcs-3(3) 1        }

В этом примере ключ создаётся обоими узлами с использованием алгоритма Диффи-Хеллмана. Таким образом, цель должна ответить инициатору для установления соединения (следовательно, этот алгоритм не может быть использован с односторонней аутентификацией в SPKM-2).

Односторонняя функция для алгоритма получения подключей[править | править код]

Создав ключ соединения с помощью K-ALG, узлы должны получить набор подключей для алгоритмов конфиденциальности и целостности. Для этого используются односторонние функции. Пусть перечень принятых алгоритмов конфиденциальности пронумерован последовательно, то есть первому алгоритму (алгоритму по умолчанию) присвоен номер 0, второму — номер 1 и так далее. Пусть список алгоритмов целостности пронумерован таким же образом. Наконец, пусть ключ соединения будет двоичной строкой произвольной длины M, с учётом ограничений:

L ≤ M ≤ U

Битовая длина ключа соединения должна быть больше, чем наибольшая битовая длина подключей (C-ALG или I-ALG), и, в то же время, она ограничена сверху входными параметрами алгоритма формирования ключа (K-ALG).

Например, при использовании DES и 3-DES в алгоритмах конфиденциальности и DES-MAC в алгоритме целостности, ключ соединения должен составлять, по крайней мере, 112 бит. А при использовании 512-битного RSA, возможная длина составляет 424 бит (наибольший допустимый входной параметр RSAEncryption, описанный в PKCS#1). С другой стороны, при использовании алгоритма dhKeyAgreement, ключ соединения вычисляется по алгоритму Диффи-Хеллмана (за исключением старшего байта, который отбрасывается по соображениям безопасности), таким образом его длина будет на 8 битов меньше чем модуль p, что составляет примерно 1000 бит^[6].

Алгоритм получения k-битного подключа определяется следующим образом:

rightmost_k_bits ( OWF ( context_key || x || n || s || context_key ) )  где:

context_key — ключ соединения;
x — ASCII символ «C» (0x43) при создании подключа для алгоритма конфиденциальности, ASCII символ «I» (0x49) при создании подключа для алгоритма целостности;
n — номер алгоритма в соответствующем разрешенном списке (ASCII символ «0» (0x30), «1» (0x31), и так далее);
s — «этап» обработки — всегда равняется ASCII символом «0» (0x30), если «k» не больше выходного размера односторонней функции (OWF), в этом случае односторонняя функция считается повторно с увеличением значения «этапа» (каждое выходное значение OWF дописывается к концу предыдущих), до тех пор, пока не будет образовано «k» битов;
|| — операция конкатенации;
OWF — соответствующая односторонняя функция.

Примеры:

  MD5 OBJECT IDENTIFIER ::= {           iso(1) member-body(2) US(840) rsadsi(113549)           digestAlgorithm(2) 5         }

Этот алгоритм является обязательным (MANDATORY).

  SHA OBJECT IDENTIFIER ::= {            iso(1) identified-organization(3) oiw(14) secsig(3)            algorithm(2) 18         }

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

Согласование[править | править код]

В процессе установления соединения в SPKM инициатор предлагает ряд возможных алгоритмов конфиденциальности и целостности данных (в том числе и алгоритмов электронной подписи). Приёмник выбирает, какие алгоритмы будут использоваться в установленном соединении и отсылает подкорректированный список поддерживаемых алгоритмов обратно. В каждом сообщении, передаваемом по установленному соединению, может быть использован любой алгоритм конфиденциальности и целостности, причём указанные на первом месте в списке алгоритмы являются выбранными по умолчанию. Принятые для данного соединения алгоритмы конфиденциальности и целостности определяют значения параметра качества защиты (Quality Of Protection), используемого функциями gss_getMIC() и gss_wrap(), которые вычисляют криптографические коды целостности сообщения и пришивают его к сообщению. Если ответа от приёмника не ожидается (односторонняя аутентификация в SPKM-2), то алгоритмы, предлагаемые источником, и будут использоваться в процессе передачи сообщений. Если же приёмник не поддерживает применяемые алгоритмы, то он посылает маркер завершения соединения (delete token) источнику и соединение разрывается.

Кроме того, в первом маркере установления соединения источник предлагает ряд возможных алгоритмов образования ключа (K_ALG) вместе с ключом (или половиной ключа), отвечающим первому алгоритму в списке. Если этот алгоритм неприемлем, то приёмник должен выбрать один из оставшихся в списке и послать свой выбор вместе с ключом (половиной), отвечающим выбранному алгоритму. Если в присланном приёмнику списке нет поддерживаемого им алгоритма, то он посылает источнику маркер разрыва соединения. При необходимости (если приёмник выбирает двусторонний алгоритм образования ключа, как в случае с использованием алгоритма Диффи-Хеллмана), источник пошлёт свою половину ключа обратно к приёмнику. Наконец, в первом маркере установления соединения источник предлагает ряд разрешённых алгоритмов образования подключей, если же используется односторонняя аутентификация, то предлагается только один алгоритм. Алгоритм (единственный), выбранный приёмником становится алгоритмом получения подключа в установленном соединении^[6].

Пример установления, использования и разрыва соединения[править | править код]

Для того, чтобы понять механизм работы маркеров, используемых в SPKM, обратимся к примеру установления соединения на основе случайных чисел. Мы не будем рассматривать все доступные маркеры и функции, для ознакомления со всем списком и для просмотра их описания и реализации лучше обратиться к RFC 2025.

На представленной схеме инициатор соединения вызывает функцию gss_init_sec_context(), которая возвращает маркер SPKM_REQ, который затем пересылается приёмнику по используемому сетевому протоколу. Приёмник, получив этот маркер, передает его gss_accept_sec_context(), которая возвращает в качестве результата SPKM_REP_TI. Его приёмник отсылает обратно инициатору. Тот, в свою очередь, использует этот маркер, как входной параметр во время второго вызова gss_init_sec_context(). Если инициатором использовалась односторонняя аутентификация, то на этом установление соединения заканчивается. В противном случае (например, если изначально требуется взаимная аутентификация) gss_init_sec_context() возвращает SPKM_REP_IT, который посылается приёмнику. Тот использует этот маркер во время второго вызова gss_accept_sec_context() и, тем самым, завершает установку соединения. После этого, стороны могут обмениваться маркерами SPKM_MIC и SPKM_WRAP до тех пор, пока одна из сторон не пошлет SPKM_DEL для разрыва соединения^[5].

Маркер SPKM_REQ содержит, среди других полей данных, следующие пункты:

имена инициатора и приёмника
новое (каждый раз разное) случайное число
список доступных алгоритмов конфиденциальности (C-ALGs)
список доступных алгоритмов целостности (I-ALGs)
список доступных алгоритмов образования ключа (K-ALGs)
ключ (или половина), соответствующие первого алгоритму образования ключа в представленном выше списке
GSS опции соединения (такие как: односторонняя или взаимная аутентификация, использование последовательного и повторного обнаружения и так далее).

Целостность этих данных защищается, а также они подписываются электронной подписью инициатора соединения. Если же он пожелал остаться анонимным, в этом случае целостность защищается при помощи MAC. При необходимости в этом маркере может отсылаться информация о цифровых сертификатах.

Маркер SPKM_REP_TI содержит:

имена инициатора и приёмника
случайное число, присланное инициатором
новое случайное число
подмножество предлагаемых алгоритмов конфиденциальности (C-ALGs), которые поддерживаются приёмником
подмножество предлагаемых алгоритмов целостности (I-ALGs), которые поддерживаются приёмником
альтернативный алгоритм образования ключа (K-ALG) из представленных в списке, если первый не подходит
половина ключа, соответствующая алгоритму образования ключа инициатора или ключ (половина), соответствующий представленному выше алгоритму
GSS опции.

Целостность этих данных защищается, а также они подписываются электронной подписью приёмника. Заметим, что подписанное приёмником случайное число инициатора, дает ему гарантию того, что приёмник «живой» и достоверный. В этом маркере может отсылаться информация о цифровых сертификатах, если это было потребовано инициатором в SPKM_REQ.

Если было выбрана взаимная аутентификация, то используется маркер SPKM_REP_IT, содержащий следующие поля:

имена инициатора и приёмника
случайное число, посланное инициатором в SPKM_REQ
случайное число, посланное приёмником SPKM_REP_TI
(при необходимости) половина ключа, соответствующая алгоритму образования ключа, выбранному приёмником.

Целостность этих данных защищается, а также они подписываются электронной подписью инициатора. Заметим, что подписанное инициатором случайное число приёмника, дает ему гарантию того, что инициатор «живой» и достоверный.

По завершении установления соединения на основе случайных чисел, обе стороны аутентифицированы (без использования меток доверенного времени), ключ соединения был безопасно установлен, два набора алгоритмов (конфиденциальности и целостности) согласованы для использования в соединении операциями MIC и WRAP. Каждый SPKM_MIC, SPKM_WRAP, а также SPKM_DEL маркер может явно указывать соответствующий алгоритм из согласованного списка, который будет использоваться для данных, связанных с маркером, или же использовать алгоритмы «по умолчанию» (то есть первые алгоритмы в каждом из списков).

SPKM_MIC — используется для подписи и проверки целостности данных (gss_sign() / gss_getMIC())

SPKM_WRAP — используется для шифрования (расшифровки) и защиты конфиденциальности данных (gss_seal() / gss_wrap())

SPKM_DEL — для разрыва соединения (gss_delete_sec_context()).

Поэтому маркеры содержат следующую информацию:

алгоритм целостности или «по умолчанию»
алгоритм конфиденциальности «или по умолчанию» (только для SPKM_WRAP)
порядковый номер
контрольная сумма целостности (вычисляется из данных и представленной выше информации на основе представленного выше алгоритма целостности)
входные данные (только для SPKM_WRAP).

Этот формат маркеров дает большую гибкость при вызове приложений, чтобы выбрать то качество защиты (QOP), которое подходит для защищаемых данных в пределах установленного соединения^[5].

Разновидности[править | править код]

Изначально были описаны две разновидности SPKM: SPKM-1 и SPKM-2, основным отличием, которых является то, что SPKM-2 требует наличие меток доверенного времени с целью повторного обнаружения во время установления соединения, а в SPKM-1 не требует. Это обеспечивает большую гибкость для приложений, так как в системе не всегда возможно использование меток доверенного времени. При создании в 2000 году протокола NFSv4 возникла необходимость в механизме, предусматривающем создание защищенного канала со взаимной аутентификацией, где:

Как пользователи, так и сервер проводят аутентификацию с использованием сертификатов открытого ключа
Сервер устанавливает подлинность по сертификатам открытого ключа, а пользователи по логину и паролю.
Клиент остается анонимным, а сервер использует сертификаты открытого ключа.

Так появился SPKM-3, который, используя надстройку LIPKEY, лежит в основе работы сетевых файловых систем^[8]^[9]. В первую очередь он создан для упрощения процедуры аутентификации. Рассмотрим подробнее этот механизм.

Клиент:

получает сертификат от сервера
проверяет, что он подписан доверенным центром сертификации
генерирует случайный симметричный сессионный ключ
шифрует свой сессионный ключ открытым ключом сервера
отправляет зашифрованный сессионный ключ серверу

Таким образом, между клиентом и сервером установлено защищенное соединение, как видно здесь применяется алгоритм Диффи — Хеллмана. Клиент может предоставить свой логин и пароль для аутентификации (или же сертификаты), однако, это не является обязательным, то есть клиент может оставаться анонимным.

Как видно, используемый механизм аутентификации аналогичен TLS, но вместе с простотой и удобством он также унаследовал и главный недостаток — возможность атаки человек посередине^[10].

GSS-API[править | править код]

GSS-API (англ. Generic Security Service - Application Programming Interface — служба общей безопасности — интерфейс программирования приложений) позволяет приложению аутентифицировать пользователя, соответствующего другому приложению, с целью предоставления ему прав, и применить службы безопасности конфиденциальности и целостности данных для каждого сообщения.

Существует 4 этапа использования GSS-API:

Приложение получает ряд удостоверений, с помощью которых оно может доказать свою подлинность другим процессам. При этом удостоверение приложения отвечает глобальной учётной записи, которая может быть, и не связана с локальной.
С помощью своих удостоверений пара общающихся приложений устанавливает безопасное соединение, которое представляет собой пару структур данных GSS-API содержащих общую информацию состояния. Эта информация необходима для того чтобы обеспечить применение служб безопасности для каждого сообщения. В качестве этой информации могут выступать криптографические ключи и порядковые номера сообщений. В процессе установления безопасного соединения, инициатор этого соединения должен быть аутентифицирован другой стороной (приёмником), и также может требовать аутентификации приёмника. Инициатор может отдать приёмнику право инициировать безопасные соединения на своих правах, что возможно, если создать ряд удостоверений схожих с удостоверениями инициатора, с тем отличием что их может использовать приёмник. Для того чтобы создать и поддерживать общую информацию, обуславливающую безопасное соединение, определенные GSS-API вызовы возвращают метку структуры данных, которая содержит криптографически защищенные данные. Метка передается в соответствии с выбранным сетевым протоколом и, приняв её, удаленное приложение извлекает необходимую информацию и обновляет состояние безопасного соединения.
Для каждого сообщения службы безопасности направлены либо на обеспечение целостности данных и проверки их происхождения, либо ещё и на обеспечение конфиденциальности. При этом данные приложения рассматриваются GSS-API как случайные 8-символьные строки. При передаче сообщения, нуждающегося в защите, приложение вызывает соответствующую GSS-API функцию (например, gss_wrap()), указывая используемое соединение, и посылает полученную метку принимающей стороне. Та в свою очередь передает эту метку соответствующей функции расшифровки и получает исходное сообщение.
При завершении сессии обе стороны вызывают функцию разрыва соединения.

Примечания[править | править код]

↑ Механизм (mechanism) — реализация нижележащего уровня GSS-API, обеспечивающая фактические имя, удостоверение и маркеры
↑ ¹ ² ³ RFC 1508 (неопр.). Дата обращения: 30 октября 2011. Архивировано 1 февраля 2012 года.
↑ RFC-1509 (неопр.). Дата обращения: 4 ноября 2011. Архивировано 12 ноября 2011 года.
↑ RFC- 1510 (неопр.). Дата обращения: 27 октября 2011. Архивировано 26 октября 2011 года.
↑ ¹ ² ³ Carlisle Adams IDUP and SPKM: Developing Public-Key-Based APIs and Mechanisms for Communication Security Services
↑ ¹ ² ³ ⁴ ⁵ ⁶ RFC 2025 (неопр.). Дата обращения: 18 декабря 2009. Архивировано 22 ноября 2009 года.
↑ Маркер (token) — непрозрачное (для приложения) сообщение, которое отсылается на этапе установления соединения или в ходе передачи защищённого сообщения
↑ RFC 3530 — Network File System (NFS) version 4 Protocol (неопр.). Дата обращения: 30 октября 2011. Архивировано 3 сентября 2011 года.
↑ RFC 2847 — LIPKEY — A Low Infrastructure Public Key Mechanism Using SPKM (неопр.). Дата обращения: 30 октября 2011. Архивировано 16 сентября 2011 года.
↑ William (Andy) Adamson, Olga Kornievskaia Low Infrastructure Public Key Based GSS Security Mechanisms

Ссылки[править | править код]

Протоколы аутентификации и обмена ключами
С симметричными алгоритмами	Wide-Mouth Frog Yahalom Протокол Нидхема — Шрёдера Протокол Отвея — Рииса Kerberos Протокол Ньюмана — Стабблбайна
С симметричными и асимметричными алгоритмами	DASS Протокол Деннинг — Сакко Протокол Ву — Лама SPKM
Протоколы и сервисы, используемые в интернете	OAuth OpenID Windows Live ID