📄 rfc2853.txt
字号:
The GSS-API may provide detection of mis-ordered messages once a
security context has been established. Protection may be applied to
messages by either application, by calling either getMIC or wrap
methods of the GSSContext interface, and verified by the peer
application by calling verifyMIC or unwrap for the peer's GSSContext
object.
The getMIC method calculates a cryptographic checksum of an
application message, and returns that checksum in a token. The
application should pass both the token and the message to the peer
application, which presents them to the verifyMIC method of the
peer's GSSContext object.
The wrap method calculates a cryptographic checksum of an application
message, and places both the checksum and the message inside a single
token. The application should pass the token to the peer
application, which presents it to the unwrap method of the peer's
GSSContext object to extract the message and verify the checksum.
Either pair of routines may be capable of detecting out-of-sequence
message delivery, or duplication of messages. Details of such mis-
ordered messages are indicated through supplementary query methods of
the MessageProp object that is filled in by each of these routines.
A mechanism need not maintain a list of all tokens that have been
processed in order to support these status codes. A typical
mechanism might retain information about only the most recent "N"
Kabat & Upadhyay Standards Track [Page 10]
RFC 2853 GSS-API Java Bindings June 2000
tokens processed, allowing it to distinguish duplicates and missing
tokens within the most recent "N" messages; the receipt of a token
older than the most recent "N" would result in the isOldToken method
of the instance of MessageProp to return "true".
3.4. Anonymous Authentication
In certain situations, an application may wish to initiate the
authentication process to authenticate a peer, without revealing its
own identity. As an example, consider an application providing
access to a database containing medical information, and offering
unrestricted access to the service. A client of such a service might
wish to authenticate the service (in order to establish trust in any
information retrieved from it), but might not wish the service to be
able to obtain the client's identity (perhaps due to privacy concerns
about the specific inquiries, or perhaps simply to avoid being placed
on mailing-lists).
In normal use of the GSS-API, the initiator's identity is made
available to the acceptor as a result of the context establishment
process. However, context initiators may request that their identity
not be revealed to the context acceptor. Many mechanisms do not
support anonymous authentication, and for such mechanisms the request
will not be honored. An authentication token will still be
generated, but the application is always informed if a requested
service is unavailable, and has the option to abort context
establishment if anonymity is valued above the other security
services that would require a context to be established.
In addition to informing the application that a context is
established anonymously (via the isAnonymous method of the GSSContext
class), the getSrcName method of the acceptor's GSSContext object
will, for such contexts, return a reserved internal-form name,
defined by the implementation.
The toString method for a GSSName object representing an anonymous
entity will return a printable name. The returned value will be
syntactically distinguishable from any valid principal name supported
by the implementation. The associated name-type object identifier
will be an oid representing the value of NT_ANONYMOUS. This name-
type oid will be defined as a public, static Oid object of the
GSSName class. The printable form of an anonymous name should be
chosen such that it implies anonymity, since this name may appear in,
for example, audit logs. For example, the string "<anonymous>" might
be a good choice, if no valid printable names supported by the
implementation can begin with "<" and end with ">".
Kabat & Upadhyay Standards Track [Page 11]
RFC 2853 GSS-API Java Bindings June 2000
When using the equal method of the GSSName interface, and one of the
operands is a GSSName instance representing an anonymous entity, the
method must return "false".
3.5. Confidentiality
If a GSSContext supports the confidentiality service, wrap method may
be used to encrypt application messages. Messages are selectively
encrypted, under the control of the setPrivacy method of the
MessageProp object used in the wrap method.
3.6. Inter-process Context Transfer
GSS-API V2 provides functionality which allows a security context to
be transferred between processes on a single machine. These are
implemented using the export method of GSSContext and a byte array
constructor of the same class. The most common use for such a
feature is a client-server design where the server is implemented as
a single process that accepts incoming security contexts, which then
launches child processes to deal with the data on these contexts. In
such a design, the child processes must have access to the security
context object created within the parent so that they can use per-
message protection services and delete the security context when the
communication session ends.
Since the security context data structure is expected to contain
sequencing information, it is impractical in general to share a
context between processes. Thus GSSContext interface provides an
export method that the process, which currently owns the context, can
call to declare that it has no intention to use the context
subsequently, and to create an inter-process token containing
information needed by the adopting process to successfully re-create
the context. After successful completion of export, the original
security context is made inaccessible to the calling process by GSS-
API and any further usage of this object will result in failures.
The originating process transfers the inter-process token to the
adopting process, which creates a new GSSContext object using the
byte array constructor. The properties of the context are equivalent
to that of the original context.
The inter-process token may contain sensitive data from the original
security context (including cryptographic keys). Applications using
inter-process tokens to transfer security contexts must take
appropriate steps to protect these tokens in transit.
Kabat & Upadhyay Standards Track [Page 12]
RFC 2853 GSS-API Java Bindings June 2000
Implementations are not required to support the inter-process
transfer of security contexts. Calling the isTransferable method of
the GSSContext interface will indicate if the context object is
transferable.
3.7. The Use of Incomplete Contexts
Some mechanisms may allow the per-message services to be used before
the context establishment process is complete. For example, a
mechanism may include sufficient information in its initial context-
level tokens for the context acceptor to immediately decode messages
protected with wrap or getMIC. For such a mechanism, the initiating
application need not wait until subsequent context-level tokens have
been sent and received before invoking the per-message protection
services.
An application can invoke the isProtReady method of the GSSContext
class to determine if the per-message services are available in
advance of complete context establishment. Applications wishing to
use per-message protection services on partially-established contexts
should query this method before attempting to invoke wrap or getMIC.
4. Calling Conventions
Java provides the implementors with not just a syntax for the
language, but also an operational environment. For example, memory
is automatically managed and does not require application
intervention. These language features have allowed for a simpler API
and have led to the elimination of certain GSS-API functions.
Moreover, the JCA defines a provider model which allows for
implementation independent access to security services. Using this
model, applications can seamlessly switch between different
implementations and dynamically add new services. The GSS-API
specification leverages these concepts by the usage of providers for
the mechanism implementations.
4.1. Package Name
The classes and interfaces defined in this document reside in the
package called "org.ietf.jgss". Applications that wish to make use
of this API should import this package name as shown in section 7.
4.2. Provider Framework
The Java security API's use a provider architecture that allows
applications to be implementation independent and security API
implementations to be modular and extensible. The
Kabat & Upadhyay Standards Track [Page 13]
RFC 2853 GSS-API Java Bindings June 2000
java.security.Provider class is an abstract class that a vendor
extends. This class maps various properties that represent different
security services that are available to the names of the actual
vendor classes that implement those services. When requesting a
service, an application simply specifies the desired provider and the
API delegates the request to service classes available from that
provider.
Using the Java security provider model insulates applications from
implementation details of the services they wish to use.
Applications can switch between providers easily and new providers
can be added as needed, even at runtime.
The GSS-API may use providers to find components for specific
underlying security mechanisms. For instance, a particular provider
might contain components that will allow the GSS-API to support the
Kerberos v5 mechanism and another might contain components to support
the SPKM mechanism. By delegating mechanism specific functionality
to the components obtained from providers the GSS-API can be extended
to support an arbitrary list of mechanism.
How the GSS-API locates and queries these providers is beyond the
scope of this document and is being deferred to a Service Provider
Interface (SPI) specification. The availability of such a SPI
specification is not mandatory for the adoption of this API
specification nor is it mandatory to use providers in the
implementation of a GSS-API framework. However, by using the provider
framework together with an SPI specification one can create an
extensible and implementation independent GSS-API framework.
4.3. Integer types
All numeric values are declared as "int" primitive Java type. The
Java specification guarantees that this will be a 32 bit two's
complement signed number.
Throughout this API, the "boolean" primitive Java type is used
wherever a boolean value is required or returned.
4.4. Opaque Data types
Java byte arrays are used to represent opaque data types which are
consumed and produced by the GSS-API in the forms of tokens. Java
arrays contain a length field which enables the users to easily
determine their size. The language has automatic garbage collection
which alleviates the need by developers to release memory and
simplifies buffer ownership issues.
Kabat & Upadhyay Standards Track [Page 14]
RFC 2853 GSS-API Java Bindings June 2000
4.5. Strings
The String object will be used to represent all textual data. The
Java String object, transparently treats all characters as two-byte
Unicode characters which allows support for many locals. All
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -