GSS-API

Материал из Википедии — свободной энциклопедии
Это старая версия этой страницы, сохранённая George Shuklin (обсуждение | вклад) в 19:37, 19 июня 2010 (→Relationship to Kerberos). Она может серьёзно отличаться от текущей версии.
Перейти к навигации Перейти к поиску

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.

Связь с Kerberos

GSSAPI часто применяется в связке с Kerberos. В отличие от GSSAPI, API Kerberos не стандартизировано (и существуют несовместимые API). GSSAPI позволяет использовать разные реализации Kerberos без изменения кода приложения.

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


>

Источник — https://ru.wikipedia.org/w/index.php?title=GSS-API&oldid=25551430