SPKM
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.Конкатенация«замешанных» данных и суммы всех входных блоков данных (сумма вычисляется с помощью сложения по модулю264— 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,с учётом ограничений:
Битовая длина ключа соединения должна быть больше, чем наибольшая битовая длина подключей (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 инициатор предлагает ряд возможных алгоритмов конфиденциальности и целостности данных (в том числе и алгоритмов электронной подписи). Приёмник выбирает, какие алгоритмы будут использоваться в установленном соединении и отсылает подкорректированный список поддерживаемых алгоритмов обратно. В каждом сообщении, передаваемом по установленному соединению, может быть использован любой алгоритм конфиденциальности и целостности, причём указанные на первом месте в списке алгоритмы являются выбранными по умолчанию. Принятые для данного соединения алгоритмы конфиденциальности и целостности определяют значения параметра качества защиты (QualityOfProtection), используемого функциямиgss_getMIC()иgss_wrap(),которые вычисляют криптографические коды целостности сообщения и пришивают его к сообщению. Если ответа от приёмника не ожидается (односторонняя аутентификация в SPKM-2), то алгоритмы, предлагаемые источником, и будут использоваться в процессе передачи сообщений. Если же приёмник не поддерживает применяемые алгоритмы, то он посылает маркер завершения соединения (delete token) источнику и соединение разрывается.
Кроме того, в первом маркере установления соединения источник предлагает ряд возможных алгоритмов образования ключа (K_ALG) вместе с ключом (или половиной ключа), отвечающим первому алгоритму в списке. Если этот алгоритм неприемлем, то приёмник должен выбрать один из оставшихся в списке и послать свой выбор вместе с ключом (половиной), отвечающим выбранному алгоритму. Если в присланном приёмнику списке нет поддерживаемого им алгоритма, то он посылает источнику маркер разрыва соединения. При необходимости (если приёмник выбирает двусторонний алгоритм образования ключа, как в случае с использованием алгоритма Диффи-Хеллмана), источник пошлёт свою половину ключа обратно к приёмнику. Наконец, в первом маркере установления соединения источник предлагает ряд разрешённых алгоритмов образования подключей, если же используется односторонняя аутентификация, то предлагается только один алгоритм. Алгоритм (единственный), выбранный приёмником становится алгоритмом получения подключа в установленном соединении[6].
Пример установления, использования и разрыва соединения
[править|править код]![](https://upload.wikimedia.org/wikipedia/commons/thumb/5/5e/Token_example.png/220px-Token_example.png)
Для того, чтобы понять механизм работы маркеров, используемых в 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, обеспечивающая фактические имя, удостоверение и маркеры
- ↑123RFC 1508 .Дата обращения: 30 октября 2011.Архивировано1 февраля 2012 года.
- ↑RFC-1509 .Дата обращения: 4 ноября 2011.Архивировано12 ноября 2011 года.
- ↑RFC- 1510 .Дата обращения: 27 октября 2011.Архивировано26 октября 2011 года.
- ↑123Carlisle AdamsIDUP and SPKM: Developing Public-Key-Based APIs and Mechanisms for Communication Security Services
- ↑123456RFC 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 KornievskaiaLow Infrastructure Public Key Based GSS Security Mechanisms
Ссылки
[править|править код]- http://www.ietf.org/rfc/rfc1508.txt
- http://www.ietf.org/rfc/rfc1509.txt
- http://www.ietf.org/rfc/rfc1510.txt
- http://www.ietf.org/rfc/rfc2025.txt
- http://www.ietf.org/rfc/rfc2847.txt
- http://www.ietf.org/rfc/rfc3530.txt
- https://www.ietf.org/mailman/listinfo/spkm
- http://potaroo.net/ietf/idref/draft-adamson-nfsv4-spkm3/#ref-RFC3280
- http://tools.ietf.org/html/draft-adamson-rfc2847-bis-01