GSS-API
 | Страницу в данный момент активно редактирует участник [[user:George Shuklin|George Shuklin]] ([[user talk:George Shuklin|обс.]] · [[special:Contributions/George Shuklin|вклад]]). |
GSS-API (GSS, GSSAPI, англ. Generic Security Services API, общий программный интерфейс сервисов безопасности) - API для доступа к сервисам безопасности. Описано в стандарте IETF. Предназначено для решения проблемы несовместимости схожих сервисов безопасности.
Описание
GSS-API сам по себе не обеспечивает сервисов безопасности, вместо этого он обеспечивает интерфейс между приложениями и реализациями GSSAPI (обычно библиотеками). Эти библиотеки обеспечивают совместимый с GSS-API интерфейс, позволяя создавать приложения, способные работать с разными библиотеками безопасности; позволяя заменять библиотеки без необходимости переписывать приложения.
Отличительной особенностью приложений, реализованных с использованием GSSAPI является использование закрытых сообщений (токенов), которые скрывают подробности реализации от вышестоящих приложений. Серверная и клиентская часть приложений создаются таким образом, чтобы взаимодействовать с помощью токенов GSSAPI. Токены обычно могут передаваться через незащищённую (публичную) сеть. После обмена сторонами (клиентом и сервером) некоторым количеством сообщений, библиотека GSSAPI информирует обе стороны взаимодействия об установлении безопасного контекста.
После установления безопасного контекста защищаемые сообщения приложения могут быть "завёрнуты" (зашифрованы) с помощью GSSAPI для безопасной передачи между сервером и клиентом.
Типичные аспекты безопасности, обеспечиваемые библиотеками, реализующими GSSAPI:
- конфиденциальность
- целостность
- подлинность обоих сторон информационного обмена
GSSAPI описывает примерно 45 вызовов. Основные:
- GSS_Acquire_cred - получение пользовательского доказательства идентичности (чаще всего закрытый ключ, пароль)
- GSS_Import_name - конвертирование имени пользователя, узла сети в форму, позволяющую определить объект безопасности
- GSS_Init_sec_context - создаёт клиентский токен для отсылки на сервер (обычно вызов, в рамках модели Вызов-ответ (аутентификация))
- GSS_Accept_sec_context - обрабатывает токен, созданный с помощью GSS_Init_sec_context и, возможно, возвращает токен ответа
- GSS_Wrap - конвертирует данные приложения в форму защищённого сообщения (обычно шифрация)
- GSS_Unwrap - извлекает из защищённого сообщения данные приложения (обычно расшифровка)
The GSSAPI has been standardized for the C (RFC 2744) and Java (JSR-072) languages.
Limitations of the GSSAPI include that it standardizes only authentication, and not authorization, and that it assumes a client–server architecture.
Anticipating new security mechanisms, the GSSAPI includes a negotiating pseudo mechanism, SPNEGO, that can discover and use new mechanisms not present when the original application was built.
Relationship to Kerberos
The dominant GSSAPI mechanism implementation in use is Kerberos. Unlike the GSSAPI, the Kerberos API has not been standardized and various existing implementations use incompatible APIs. The GSSAPI allows Kerberos implementations to be API compatible.
Related technologies
Key concepts of the GSSAPI
- Name
- A binary string that labels a security principal (i.e., user or service program) - see access control and identity. For example, Kerberos uses names like user@REALM for users and service/hostname@REALM for programs.
- Credentials
- Information that proves an identity; used by an entity to act as the named principal. Credentials typically involve a secret cryptographic key.
- Context
- The state of one end of the authenticating/authenticated protocol. May provide message protection services, which can be used to compose a secure channel.
- Tokens
- Opaque messages exchanged either as part of the initial authentication protocol (context-level tokens), or as part of a protected communication (per-message tokens)
- Mechanism
- An underlying GSSAPI implementation that provides actual names, tokens and credentials. Known mechanisms include Kerberos, NTLM, Distributed Computing Environment (DCE), SESAME, SPKM, LIPKEY.
- Initiator/acceptor
- The peer that sends the first token is the initiator; the other the acceptor. Generally, the client program is the initiator while the server is the acceptor.
History of the GSSAPI
- July 1991: IETF Common Authentication Technology (CAT) Working Group meets in Atlanta, led by John Linn
- September 1993: GSSAPI version 1 (RFC 1508, RFC 1509)
- May 1995: Windows NT 3.51 released, includes SSPI
- June 1996: Kerberos mechanism for GSSAPI (RFC 1964)
- January 1997: GSSAPI version 2 (RFC 2078)
- October 1997: SASL published, includes GSSAPI mechanism (RFC 2222)
- January 2000: GSSAPI version 2 update 1 (RFC 2743, RFC 2744)
- August 2004: KITTEN working group meets to continue CAT activities
- May 2006: Secure Shell use of GSSAPI standardised (RFC 4462)
See also
External links
- RFC 2743 The Generic Security Service API Version 2 update 1
- RFC 2744 The Generic Security Service API Version 2: C-Bindings
- RFC 1964 The Kerberos 5 GSS-API mechanism
- RFC 4121 The Kerberos 5 GSS-API mechanism: Version 2
- RFC 4178 The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
- RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM)
- RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
- Kitten working group - next generation GSS-API
- GSS-API Programming Guide from Sun
>