tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2853


Pages: 96
Top     in Index     Prev     Next
 

Generic Security Service API Version 2 : Java Bindings

Part 1 of 4, p. 1 to 26
None       Next RFC Part

Obsoleted by:    5653


Top       ToC       Page 1 
Network Working Group                                          J. Kabat
Request for Comments: 2853                               ValiCert, Inc.
Category: Standards Track                                   M. Upadhyay
                                                 Sun Microsystems, Inc.
                                                              June 2000


         Generic Security Service API Version 2 : Java Bindings

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   The Generic Security Services Application Program Interface (GSS-API)
   offers application programmers uniform access to security services
   atop a variety of underlying cryptographic mechanisms. This document
   specifies the Java bindings for GSS-API which is described at a
   language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE].

   The GSS-API allows a caller application to authenticate a principal
   identity, to delegate rights to a peer, and to apply security
   services such as confidentiality and integrity on a per-message
   basis. Examples of security mechanisms defined for GSS-API are The
   Simple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5
   GSS-API Mechanism [KERBV5].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  GSS-API Operational Paradigm . . . . . . . . . . . . . . .   6
   3.  Additional Controls  . . . . . . . . . . . . . . . . . . .   8
   3.1.  Delegation . . . . . . . . . . . . . . . . . . . . . . .   9
   3.2.  Mutual Authentication  . . . . . . . . . . . . . . . . .  10
   3.3.  Replay and Out-of-Sequence Detection . . . . . . . . . .  10
   3.4.  Anonymous Authentication . . . . . . . . . . . . . . . .  11
   3.5.  Confidentiality  . . . . . . . . . . . . . . . . . . . .  12
   3.6.  Inter-process Context Transfer . . . . . . . . . . . . .  12
   3.7.  The Use of Incomplete Contexts . . . . . . . . . . . . .  13

Top      ToC       Page 2 
   4.  Calling Conventions  . . . . . . . . . . . . . . . . . . .  13
   4.1.  Package Name . . . . . . . . . . . . . . . . . . . . . .  13
   4.2.  Provider Framework . . . . . . . . . . . . . . . . . . .  13
   4.3.  Integer types  . . . . . . . . . . . . . . . . . . . . .  14
   4.4.  Opaque Data types  . . . . . . . . . . . . . . . . . . .  14
   4.5.  Strings  . . . . . . . . . . . . . . . . . . . . . . . .  15
   4.6.  Object Identifiers . . . . . . . . . . . . . . . . . . .  15
   4.7.  Object Identifier Sets . . . . . . . . . . . . . . . . .  15
   4.8.  Credentials  . . . . . . . . . . . . . . . . . . . . . .  16
   4.9.  Contexts . . . . . . . . . . . . . . . . . . . . . . . .  18
   4.10.  Authentication tokens . . . . . . . . . . . . . . . . .  18
   4.11.  Interprocess tokens . . . . . . . . . . . . . . . . . .  18
   4.12.  Error Reporting . . . . . . . . . . . . . . . . . . . .  19
   4.12.1.  GSS status codes  . . . . . . . . . . . . . . . . . .  19
   4.12.2.  Mechanism-specific status codes . . . . . . . . . . .  21
   4.12.3.  Supplementary status codes  . . . . . . . . . . . . .  21
   4.13.  Names . . . . . . . . . . . . . . . . . . . . . . . . .  22
   4.14.  Channel Bindings  . . . . . . . . . . . . . . . . . . .  25
   4.15.  Stream Objects  . . . . . . . . . . . . . . . . . . . .  26
   4.16.  Optional Parameters . . . . . . . . . . . . . . . . . .  26
   5.  Introduction to GSS-API Classes and Interfaces . . . . . .  26
   5.1.  GSSManager class . . . . . . . . . . . . . . . . . . . .  26
   5.2.  GSSName interface  . . . . . . . . . . . . . . . . . . .  27
   5.3.  GSSCredential interface  . . . . . . . . . . . . . . . .  28
   5.4.  GSSContext interface . . . . . . . . . . . . . . . . . .  28
   5.5.  MessageProp class  . . . . . . . . . . . . . . . . . . .  30
   5.6.  GSSException class . . . . . . . . . . . . . . . . . . .  30
   5.7.  Oid class  . . . . . . . . . . . . . . . . . . . . . . .  30
   5.8.  ChannelBinding class . . . . . . . . . . . . . . . . . .  31
   6.  Detailed GSS-API Class Description . . . . . . . . . . . .  31
   6.1.  public abstract class GSSManager . . . . . . . . . . . .  31
   6.1.1.  Example Code . . . . . . . . . . . . . . . . . . . . .  32
   6.1.2.  getInstance  . . . . . . . . . . . . . . . . . . . . .  33
   6.1.3.  getMechs . . . . . . . . . . . . . . . . . . . . . . .  33
   6.1.4.  getNamesForMech  . . . . . . . . . . . . . . . . . . .  33
   6.1.5.  getMechsForName  . . . . . . . . . . . . . . . . . . .  33
   6.1.6.  createName . . . . . . . . . . . . . . . . . . . . . .  33
   6.1.7.  createName . . . . . . . . . . . . . . . . . . . . . .  34
   6.1.8.  createName . . . . . . . . . . . . . . . . . . . . . .  35
   6.1.9.  createName . . . . . . . . . . . . . . . . . . . . . .  35
   6.1.10.  createCredential  . . . . . . . . . . . . . . . . . .  36
   6.1.11.  createCredential  . . . . . . . . . . . . . . . . . .  36
   6.1.12.  createCredential  . . . . . . . . . . . . . . . . . .  37
   6.1.13.  createContext . . . . . . . . . . . . . . . . . . . .  37
   6.1.14.  createContext . . . . . . . . . . . . . . . . . . . .  38
   6.1.15.  createContext . . . . . . . . . . . . . . . . . . . .  38
   6.1.16.  addProviderAtFront  . . . . . . . . . . . . . . . . .  38
   6.1.16.1.  Example Code  . . . . . . . . . . . . . . . . . . .  39

Top      ToC       Page 3 
   6.1.17.  addProviderAtEnd  . . . . . . . . . . . . . . . . . .  40
   6.1.17.1.  Example Code  . . . . . . . . . . . . . . . . . . .  41
   6.2.  public interface GSSName . . . . . . . . . . . . . . . .  42
   6.2.1.  Example Code . . . . . . . . . . . . . . . . . . . . .  42
   6.2.2.  Static Constants . . . . . . . . . . . . . . . . . . .  43
   6.2.3.  equals . . . . . . . . . . . . . . . . . . . . . . . .  44
   6.2.4.  equals . . . . . . . . . . . . . . . . . . . . . . . .  44
   6.2.5.  canonicalize . . . . . . . . . . . . . . . . . . . . .  44
   6.2.6.  export . . . . . . . . . . . . . . . . . . . . . . . .  45
   6.2.7.  toString . . . . . . . . . . . . . . . . . . . . . . .  45
   6.2.8.  getStringNameType  . . . . . . . . . . . . . . . . . .  45
   6.2.9.  isAnonymous  . . . . . . . . . . . . . . . . . . . . .  45
   6.2.10.  isMN  . . . . . . . . . . . . . . . . . . . . . . . .  45
   6.3.  public interface GSSCredential implements Cloneable  . .  45
   6.3.1.  Example Code . . . . . . . . . . . . . . . . . . . . .  46
   6.3.2.  Static Constants . . . . . . . . . . . . . . . . . . .  47
   6.3.3.  dispose  . . . . . . . . . . . . . . . . . . . . . . .  48
   6.3.4.  getName  . . . . . . . . . . . . . . . . . . . . . . .  48
   6.3.5.  getName  . . . . . . . . . . . . . . . . . . . . . . .  48
   6.3.6.  getRemainingLifetime . . . . . . . . . . . . . . . . .  48
   6.3.7.  getRemainingInitLifetime . . . . . . . . . . . . . . .  49
   6.3.8.  getRemainingAcceptLifetime . . . . . . . . . . . . . .  49
   6.3.9.  getUsage . . . . . . . . . . . . . . . . . . . . . . .  49
   6.3.10.  getUsage  . . . . . . . . . . . . . . . . . . . . . .  49
   6.3.11.  getMechs  . . . . . . . . . . . . . . . . . . . . . .  50
   6.3.12.  add . . . . . . . . . . . . . . . . . . . . . . . . .  50
   6.3.13.  equals  . . . . . . . . . . . . . . . . . . . . . . .  51
   6.4.  public interface GSSContext  . . . . . . . . . . . . . .  51
   6.4.1.  Example Code . . . . . . . . . . . . . . . . . . . . .  52
   6.4.2.  Static Constants . . . . . . . . . . . . . . . . . . .  54
   6.4.3.  initSecContext . . . . . . . . . . . . . . . . . . . .  54
   6.4.3.1.  Example Code . . . . . . . . . . . . . . . . . . . .  55
   6.4.4.  initSecContext . . . . . . . . . . . . . . . . . . . .  56
   6.4.4.1.  Example Code . . . . . . . . . . . . . . . . . . . .  56
   6.4.5.  acceptSecContext . . . . . . . . . . . . . . . . . . .  57
   6.4.5.1.  Example Code . . . . . . . . . . . . . . . . . . . .  58
   6.4.6.  acceptSecContext . . . . . . . . . . . . . . . . . . .  59
   6.4.6.1.  Example Code . . . . . . . . . . . . . . . . . . . .  59
   6.4.7.  isEstablished  . . . . . . . . . . . . . . . . . . . .  60
   6.4.8.  dispose  . . . . . . . . . . . . . . . . . . . . . . .  60
   6.4.9.  getWrapSizeLimit . . . . . . . . . . . . . . . . . . .  61
   6.4.10.  wrap  . . . . . . . . . . . . . . . . . . . . . . . .  61
   6.4.11.  wrap  . . . . . . . . . . . . . . . . . . . . . . . .  62
   6.4.12.  unwrap  . . . . . . . . . . . . . . . . . . . . . . .  63
   6.4.13.  unwrap  . . . . . . . . . . . . . . . . . . . . . . .  64
   6.4.14.  getMIC  . . . . . . . . . . . . . . . . . . . . . . .  65
   6.4.15.  getMIC  . . . . . . . . . . . . . . . . . . . . . . .  65
   6.4.16.  verifyMIC . . . . . . . . . . . . . . . . . . . . . .  66

Top      ToC       Page 4 
   6.4.17.  verifyMIC . . . . . . . . . . . . . . . . . . . . . .  67
   6.4.18.  export  . . . . . . . . . . . . . . . . . . . . . . .  68
   6.4.19.  requestMutualAuth . . . . . . . . . . . . . . . . . .  68
   6.4.20.  requestReplayDet  . . . . . . . . . . . . . . . . . .  69
   6.4.21.  requestSequenceDet  . . . . . . . . . . . . . . . . .  69
   6.4.22.  requestCredDeleg  . . . . . . . . . . . . . . . . . .  69
   6.4.23.  requestAnonymity  . . . . . . . . . . . . . . . . . .  69
   6.4.24.  requestConf . . . . . . . . . . . . . . . . . . . . .  70
   6.4.25.  requestInteg  . . . . . . . . . . . . . . . . . . . .  70
   6.4.26.  requestLifetime . . . . . . . . . . . . . . . . . . .  70
   6.4.27.  setChannelBinding . . . . . . . . . . . . . . . . . .  71
   6.4.28.  getCredDelegState . . . . . . . . . . . . . . . . . .  71
   6.4.29.  getMutualAuthState  . . . . . . . . . . . . . . . . .  71
   6.4.30.  getReplayDetState . . . . . . . . . . . . . . . . . .  71
   6.4.31.  getSequenceDetState . . . . . . . . . . . . . . . . .  71
   6.4.32.  getAnonymityState . . . . . . . . . . . . . . . . . .  72
   6.4.33.  isTransferable  . . . . . . . . . . . . . . . . . . .  72
   6.4.34.  isProtReady . . . . . . . . . . . . . . . . . . . . .  72
   6.4.35.  getConfState  . . . . . . . . . . . . . . . . . . . .  72
   6.4.36.  getIntegState . . . . . . . . . . . . . . . . . . . .  72
   6.4.37.  getLifetime . . . . . . . . . . . . . . . . . . . . .  73
   6.4.38.  getSrcName  . . . . . . . . . . . . . . . . . . . . .  73
   6.4.39.  getTargName . . . . . . . . . . . . . . . . . . . . .  73
   6.4.40.  getMech . . . . . . . . . . . . . . . . . . . . . . .  73
   6.4.41.  getDelegCred  . . . . . . . . . . . . . . . . . . . .  73
   6.4.42.  isInitiator . . . . . . . . . . . . . . . . . . . . .  73
   6.5.  public class MessageProp . . . . . . . . . . . . . . . .  74
   6.5.1.  Constructors . . . . . . . . . . . . . . . . . . . . .  74
   6.5.2.  getQOP . . . . . . . . . . . . . . . . . . . . . . . .  75
   6.5.3.  getPrivacy . . . . . . . . . . . . . . . . . . . . . .  75
   6.5.4.  getMinorStatus . . . . . . . . . . . . . . . . . . . .  75
   6.5.5.  getMinorString . . . . . . . . . . . . . . . . . . . .  75
   6.5.6.  setQOP . . . . . . . . . . . . . . . . . . . . . . . .  75
   6.5.7.  setPrivacy . . . . . . . . . . . . . . . . . . . . . .  75
   6.5.8.  isDuplicateToken . . . . . . . . . . . . . . . . . . .  76
   6.5.9.  isOldToken . . . . . . . . . . . . . . . . . . . . . .  76
   6.5.10.  isUnseqToken  . . . . . . . . . . . . . . . . . . . .  76
   6.5.11.  isGapToken  . . . . . . . . . . . . . . . . . . . . .  76
   6.5.12.  setSupplementaryStates  . . . . . . . . . . . . . . .  76
   6.6.  public class ChannelBinding  . . . . . . . . . . . . . .  77
   6.6.1.  Constructors . . . . . . . . . . . . . . . . . . . . .  77
   6.6.2.  getInitiatorAddress  . . . . . . . . . . . . . . . . .  78
   6.6.3.  getAcceptorAddress . . . . . . . . . . . . . . . . . .  78
   6.6.4.  getApplicationData . . . . . . . . . . . . . . . . . .  78
   6.6.5.  equals . . . . . . . . . . . . . . . . . . . . . . . .  78
   6.7.  public class Oid . . . . . . . . . . . . . . . . . . . .  79
   6.7.1.  Constructors . . . . . . . . . . . . . . . . . . . . .  79
   6.7.2.  toString . . . . . . . . . . . . . . . . . . . . . . .  80

Top      ToC       Page 5 
   6.7.3.  equals . . . . . . . . . . . . . . . . . . . . . . . .  80
   6.7.4.  getDER . . . . . . . . . . . . . . . . . . . . . . . .  80
   6.7.5.  containedIn  . . . . . . . . . . . . . . . . . . . . .  80
   6.8.  public class GSSException extends Exception  . . . . . .  80
   6.8.1.  Static Constants . . . . . . . . . . . . . . . . . . .  81
   6.8.2.  Constructors . . . . . . . . . . . . . . . . . . . . .  83
   6.8.3.  getMajor . . . . . . . . . . . . . . . . . . . . . . .  84
   6.8.4.  getMinor . . . . . . . . . . . . . . . . . . . . . . .  84
   6.8.5.  getMajorString . . . . . . . . . . . . . . . . . . . .  84
   6.8.6.  getMinorString . . . . . . . . . . . . . . . . . . . .  84
   6.8.7.  setMinor . . . . . . . . . . . . . . . . . . . . . . .  84
   6.8.8.  toString . . . . . . . . . . . . . . . . . . . . . . .  85
   6.8.9.  getMessage . . . . . . . . . . . . . . . . . . . . . .  85
   7.  Sample Applications  . . . . . . . . . . . . . . . . . . .  85
   7.1.  Simple GSS Context Initiator . . . . . . . . . . . . . .  85
   7.2.  Simple GSS Context Acceptor  . . . . . . . . . . . . . .  89
   8.  Security Considerations  . . . . . . . . . . . . . . . . .  93
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  94
   10.  Bibliography  . . . . . . . . . . . . . . . . . . . . . .  94
   11.  Authors' Addresses  . . . . . . . . . . . . . . . . . . .  95
   12.  Full Copyright Statement. . . . . . . . . . . . . . . . .  96

1.  Introduction

   This document specifies Java language bindings for the Generic
   Security Services Application Programming Interface Version 2 (GSS-
   API).  GSS-API Version 2 is described in a language independent
   format in RFC 2743 [GSSAPIv2-UPDATE]. The GSS-API allows a caller
   application to authenticate a principal identity, to delegate rights
   to a peer, and to apply security services such as confidentiality and
   integrity on a per-message basis.

   This document leverages the work performed by the WG in the area of
   RFC 2743 [GSSAPIv2-UPDATE] and the C-bindings RFC 2744 [GSSAPI-C].
   Whenever appropriate, text has been used from the C-bindings RFC 2744
   to explain generic concepts and provide direction to the
   implementors.

   The design goals of this API have been to satisfy all the
   functionality defined in RFC 2743 and to provide these services in an
   object oriented method.  The specification also aims to satisfy the
   needs of both types of Java application developers, those who would
   like access to a "system-wide" GSS-API implementation, as well as
   those who would want to provide their own "custom" implementation.

Top      ToC       Page 6 
   A "system-wide" implementation is one that is available to all
   applications in the form of a library package.  It may be a standard
   package in the Java runtime environment (JRE) being used or it may be
   additionally installed and accessible to any application via the
   CLASSPATH.

   A "custom" implementation of the GSS-API, on the other hand, is one
   that would, in most cases, be bundled with the application during
   distribution.  It is expected that such an implementation would be
   meant to provide for some particular need of the application, such as
   support for some specific mechanism.

   The design of this API also aims to provide a flexible framework to
   add and manage GSS-API mechanisms. GSS-API leverages the Java
   Cryptography Architecture (JCA) provider model to support the
   plugability of mechanisms.  Mechanisms can be added on a "system-
   wide" basis, where all users of the framework will have them
   available. The specification also allows for the addition of
   mechanisms per-instance of the GSS-API.

   Lastly, this specification presents an API that will naturally fit
   within the operation environment of the Java platform.  Readers are
   assumed to be familiar with both the GSS-API and the Java platform.

2.  GSS-API Operational Paradigm

   The Generic Security Service Application Programming Interface
   Version 2 [GSSAPIv2-UPDATE] defines a generic security API to calling
   applications.  It allows a communicating application to authenticate
   the user associated with another application, to delegate rights to
   another application, and to apply security services such as
   confidentiality and integrity on a per-message basis.

      There are four stages to using GSS-API:

      1) The application acquires a set of credentials with which it may
         prove its identity to other processes.  The application's
         credentials vouch for its global identity, which may or may not
         be related to any local username under which it may be running.

      2) A pair of communicating applications establish a joint security
         context using their credentials.  The security context
         encapsulates shared state information, which is required in
         order that per-message security services may be provided.
         Examples of state information that might be shared between
         applications as part of a security context are cryptographic
         keys, and message sequence numbers.  As part of the
         establishment of  a security context, the context initiator is

Top      ToC       Page 7 
         authenticated to the responder, and may require that the
         responder is authenticated back to the initiator.  The
         initiator may optionally give the responder the right to
         initiate further security contexts, acting as an agent or
         delegate of the initiator.  This transfer of rights is termed
         "delegation", and is achieved by creating a set of credentials,
         similar to those used by the initiating application, but which
         may be used by the responder.

         A GSSContext object is used to establish and maintain the
         shared information that makes up the security context.  Certain
         GSSContext methods will generate a token, which applications
         treat as cryptographically protected, opaque data.  The caller
         of such GSSContext method is responsible for transferring the
         token to the peer application, encapsulated if necessary in an
         application-to-application protocol.  On receipt of such a
         token, the peer application should pass it to a corresponding
         GSSContext method which will decode the token and extract the
         information, updating the security context state information
         accordingly.

      3) Per-message services are invoked on a GSSContext object to
         apply either:

         integrity and data origin authentication, or

         confidentiality, integrity and data origin authentication

         to application data, which are treated by GSS-API as arbitrary
         octet-strings.  An application transmitting a message that it
         wishes to protect will call the appropriate GSSContext method
         (getMIC or wrap) to apply protection, and send the resulting
         token to the receiving application.  The receiver will pass the
         received token (and, in the case of data protected by getMIC,
         the accompanying message-data) to the corresponding decoding
         method of the GSSContext interface (verifyMIC or unwrap) to
         remove the protection and validate the data.

      4) At the completion of a communications session (which may extend
         across several transport connections), each application uses a
         GSSContext method to invalidate the security context and
         release any system or cryptographic resources held.  Multiple
         contexts may also be used (either successively or
         simultaneously) within a single communications association, at
         the discretion of the applications.

Top      ToC       Page 8 
3.  Additional Controls

   This section discusses the optional services that a context initiator
   may request of the GSS-API before the context establishment.  Each of
   these services is requested by calling the appropriate mutator method
   in the GSSContext object before the first call to init is performed.
   Only the context initiator can request context flags.

   The optional services defined are:

   Delegation
         The (usually temporary) transfer of rights from initiator to
         acceptor, enabling the acceptor to authenticate itself as an
         agent of the initiator.

   Mutual Authentication
         In addition to the initiator authenticating its identity to the
         context acceptor, the context acceptor should also authenticate
         itself to the initiator.

   Replay Detection
         In addition to providing message integrity services, GSSContext
         per-message operations of getMIC and wrap should include
         message numbering information  to enable verifyMIC and unwrap
         to detect if a message has been duplicated.

   Out-of-Sequence Detection
         In addition to providing message integrity services, GSSContext
         per-message operations  (getMIC and wrap) should include
         message sequencing information to enable verifyMIC and unwrap
         to detect if a message has been received out of sequence.

   Anonymous Authentication
         The establishment of the security context should not reveal the
         initiator's identity to the context acceptor.

   Some mechanisms may not support all optional services, and some
   mechanisms may only support some services in conjunction with others.
   The GSSContext interface offers query methods to allow the
   verification by the calling application of which services will be
   available from the context when the establishment phase is complete.
   In general, if the security mechanism is capable of providing a
   requested service, it should do so even if additional services must
   be enabled in order to provide the requested service.  If the
   mechanism is incapable of providing a requested service, it should
   proceed without the service leaving the application to abort the
   context establishment process if it considers the requested service
   to be mandatory.

Top      ToC       Page 9 
   Some mechanisms may specify that support for some services is
   optional, and that implementors of the mechanism need not provide it.
   This is most commonly true of the confidentiality service, often
   because of legal restrictions on the use of data-encryption, but may
   apply to any of the services.  Such mechanisms are required to send
   at least one token from acceptor to initiator during context
   establishment when the initiator indicates a desire to use such a
   service, so that the initiating GSS-API can correctly indicate
   whether the service is supported by the acceptor's GSS-API.

3.1.  Delegation

   The GSS-API allows delegation to be controlled by the initiating
   application via the requestCredDeleg method before the first call to
   init has been issued.  Some mechanisms do not support delegation, and
   for such mechanisms attempts by an application to enable delegation
   are ignored.

   The acceptor of a security context, for which the initiator enabled
   delegation, can check if delegation was enabled by using the
   getCredDelegState method of the GSSContext interface.  In cases when
   it is, the delegated credential object can be obtained by calling the
   getDelegCred method.  The obtained GSSCredential object may then be
   used to initiate subsequent GSS-API security contexts as an agent or
   delegate of the initiator.  If the original initiator's identity is
   "A" and the delegate's identity is "B", then, depending on the
   underlying mechanism, the identity embodied by the delegated
   credential may be either "A" or "B acting for A".

   For many mechanisms that support delegation, a simple boolean does
   not provide enough control.  Examples of additional aspects of
   delegation control that a mechanism might provide to an application
   are duration of delegation, network addresses from which delegation
   is valid, and constraints on the tasks that may be performed by a
   delegate.  Such controls are presently outside the scope of the GSS-
   API.  GSS-API implementations supporting mechanisms offering
   additional controls should provide extension routines that allow
   these controls to be exercised (perhaps by modifying the initiator's
   GSS-API credential object prior to its use in establishing a
   context).  However, the simple delegation control provided by GSS-API
   should always be able to over-ride other mechanism-specific
   delegation controls.  If the application instructs the GSSContext
   object that delegation is not desired, then the implementation must
   not permit delegation to occur.  This is an exception to the general
   rule that a mechanism may enable services even if they are not
   requested - delegation may only be provided at the explicit request
   of the application.

Top      ToC       Page 10 
3.2.  Mutual Authentication

   Usually, a context acceptor will require that a context initiator
   authenticate itself so that the acceptor may make an access-control
   decision prior to performing a service for the initiator.  In some
   cases, the initiator may also request that the acceptor authenticate
   itself.  GSS-API allows the initiating application to request this
   mutual authentication service by calling the requestMutualAuth method
   of the GSSContext interface with a "true" parameter before making the
   first call to init.  The initiating application is informed as to
   whether or not the context acceptor has authenticated itself.  Note
   that some mechanisms may not support mutual authentication, and other
   mechanisms may always perform mutual authentication, whether or not
   the initiating application requests it.  In particular, mutual
   authentication may be required by some mechanisms in order to support
   replay or out-of-sequence message detection, and for such mechanisms
   a request for either of these services will automatically enable
   mutual authentication.

3.3.  Replay and Out-of-Sequence Detection

   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"

Top      ToC       Page 11 
   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 ">".

Top      ToC       Page 12 
   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.

Top      ToC       Page 13 
   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

Top      ToC       Page 14 
   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.

Top      ToC       Page 15 
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
   routines returning or accepting textual data will use the String
   object.

4.6.  Object Identifiers

   An Oid object will be used to represent Universal Object Identifiers
   (Oids).  Oids are ISO-defined, hierarchically globally-interpretable
   identifiers used within the GSS-API framework to identify security
   mechanisms and name formats.  The Oid object can be created from a
   string representation of its dot notation (e.g. "1.3.6.1.5.6.2") as
   well as from its ASN.1 DER encoding.  Methods are also provided to
   test equality and provide the DER representation for the object.

   An important feature of the Oid class is that its instances are
   immutable - i.e.  there are no methods defined that allow one to
   change the contents of an Oid.  This property allows one to treat
   these objects as "statics" without the need to perform copies.

   Certain routines allow the usage of a default oid.  A "null" value
   can be used in those cases.

4.7.  Object Identifier Sets

   The Java bindings represents object identifiers sets as arrays of Oid
   objects.  All Java arrays contain a length field which allows for
   easy manipulation and reference.

   In order to support the full functionality of RFC 2743, the Oid class
   includes a method which checks for existence of an Oid object within
   a specified array.  This is equivalent in functionality to
   gss_test_oid_set_member.  The use of Java arrays and Java's automatic
   garbage collection has eliminated the need for the following
   routines: gss_create_empty_oid_set, gss_release_oid_set, and
   gss_add_oid_set_member.  Java GSS-API implementations will not
   contain them.  Java's automatic garbage collection and the immutable
   property of the Oid object eliminates the complicated memory
   management issues of the C counterpart.

   When ever a default value for an Object Identifier Set is required, a
   "null" value can be used.  Please consult the detailed method
   description for details.

Top      ToC       Page 16 
4.8.  Credentials

   GSS-API credentials are represented by the GSSCredential interface.
   The interface contains several constructs to allow for the creation
   of most common credential objects for the initiator and the acceptor.
   Comparisons are performed using the interface's "equals" method.  The
   following general description of GSS-API credentials is included from
   the C-bindings specification:

   GSS-API credentials can contain mechanism-specific principal
   authentication data for multiple mechanisms.  A GSS-API credential is
   composed of a set of credential-elements, each of which is applicable
   to a single mechanism.  A credential may contain at most one
   credential-element for each supported mechanism.  A credential-
   element identifies the data needed by a single mechanism to
   authenticate a single principal, and conceptually contains two
   credential-references that describe the actual mechanism-specific
   authentication data, one to be used by GSS-API for initiating
   contexts, and one to be used for accepting contexts.  For mechanisms
   that do not distinguish between acceptor and initiator credentials,
   both references would point to the same underlying mechanism-specific
   authentication data.

   Credentials describe a set of mechanism-specific principals, and give
   their holder the ability to act as any of those principals.  All
   principal identities asserted by a single GSS-API credential should
   belong to the same entity, although enforcement of this property is
   an implementation-specific matter.  A single GSSCredential object
   represents all the credential elements that have been acquired.

   The creation's of an GSSContext object allows the value of "null" to
   be specified as the GSSCredential input parameter.  This will
   indicate a desire by the application to act as a default principal.
   While individual GSS-API implementations are free to determine such
   default behavior as appropriate to the mechanism, the following
   default behavior by these routines is recommended for portability:

      For the initiator side of the context:

      1) If there is only a single principal capable of initiating
         security contexts for the chosen mechanism that the application
         is authorized to act on behalf of, then that principal shall be
         used, otherwise

Top      ToC       Page 17 
      2) If the platform maintains a concept of a default network-
         identity for the chosen mechanism, and if the application is
         authorized to act on behalf of that identity for the purpose of
         initiating security contexts, then the principal corresponding
         to that identity shall be used, otherwise

      3) If the platform maintains a concept of a default local
         identity, and provides a means to map local identities into
         network-identities for the chosen mechanism, and if the
         application is authorized to act on behalf of the network-
         identity image of the default local identity for the purpose of
         initiating security contexts using the chosen mechanism, then
         the principal corresponding to that identity shall be used,
         otherwise

      4) A user-configurable default identity should be used.

      and for the acceptor side of the context

      1) If there is only a single authorized principal identity capable
         of accepting security contexts for the chosen mechanism, then
         that principal shall be used, otherwise

      2) If the mechanism can determine the identity of the target
         principal by examining the context-establishment token
         processed during the accept method, and if the accepting
         application is authorized to act as that principal for the
         purpose of accepting security contexts using the chosen
         mechanism, then that principal identity shall be used,
         otherwise

      3) If the mechanism supports context acceptance by any principal,
         and if mutual authentication was not requested, any principal
         that the application is authorized to accept security contexts
         under using the chosen mechanism may be used, otherwise

      4) A user-configurable default identity shall be used.

   The purpose of the above rules is to allow security contexts to be
   established by both initiator and acceptor using the default behavior
   whenever possible.  Applications requesting default behavior are
   likely to be more portable across mechanisms and implementations than
   ones that instantiate an GSSCredential object representing a specific
   identity.

Top      ToC       Page 18 
4.9.  Contexts

   The GSSContext interface is used to represent one end of a GSS-API
   security context, storing state information appropriate to that end
   of the peer communication, including cryptographic state information.
   The instantiation of the context object is done differently by the
   initiator and the acceptor.  After the context has been instantiated,
   the initiator may choose to set various context options which will
   determine the characteristics of the desired security context.  When
   all the application desired characteristics have been set, the
   initiator will call the initSecContext method which will produce a
   token for consumption by the peer's acceptSecContext method.  It is
   the responsibility of the application to deliver the authentication
   token(s) between the peer applications for processing.  Upon
   completion of the context establishment phase, context attributes can
   be retrieved, by both the initiator and acceptor, using the accessor
   methods.  These will reflect the actual attributes of the established
   context.  At this point the context can be used by the application to
   apply cryptographic services to its data.

4.10.  Authentication tokens

   A token is a caller-opaque type that GSS-API uses to maintain
   synchronization between each end of the GSS-API security context.
   The token is a cryptographically protected octet-string, generated by
   the underlying mechanism at one end of a GSS-API security context for
   use by the peer mechanism at the other end.  Encapsulation (if
   required) within the application protocol and transfer of the token
   are the responsibility of the peer applications.

   Java GSS-API uses byte arrays to represent authentication tokens.
   Overloaded methods exist which allow the caller to supply input and
   output streams which will be used for the reading and writing of the
   token data.

4.11.  Interprocess tokens

   Certain GSS-API routines are intended to transfer data between
   processes in multi-process programs.  These routines use a caller-
   opaque octet-string, generated by the GSS-API in one process for use
   by the GSS-API in another process.  The calling application is
   responsible for transferring such tokens between processes.  Note
   that, while GSS-API implementors are encouraged to avoid placing
   sensitive information within interprocess tokens, or to
   cryptographically protect them, many implementations will be unable
   to avoid placing key material or other sensitive data within them.
   It is the application's responsibility to ensure that interprocess
   tokens are protected in transit, and transferred only to processes

Top      ToC       Page 19 
   that are trustworthy.  An interprocess token is represented using a
   byte array emitted from the export method of the GSSContext
   interface.  The receiver of the interprocess token would initialize
   an GSSContext object with this token to create a new context.  Once a
   context has been exported, the GSSContext object is invalidated and
   is no longer available.

4.12.  Error Reporting

   RFC 2743 defined the usage of major and minor status values for
   signaling of GSS-API errors.  The major code, also called GSS status
   code, is used to signal errors at the GSS-API level independent of
   the underlying mechanism(s).  The minor status value or Mechanism
   status code, is a mechanism defined error value indicating a
   mechanism specific error code.

   Java GSS-API uses exceptions implemented by the GSSException class to
   signal both minor and major error values.  Both mechanism specific
   errors and GSS-API level errors are signaled through instances of
   this class.  The usage of exceptions replaces the need for major and
   minor codes to be used within the API calls.  GSSException class also
   contains methods to obtain textual representations for both the major
   and minor values, which is equivalent to the functionality of
   gss_display_status.

4.12.1.  GSS status codes

   GSS status codes indicate errors that are independent of the
   underlying mechanism(s) used to provide the security service.  The
   errors that can be indicated via a GSS status code are generic API
   routine errors (errors that are defined in the GSS-API
   specification).  These bindings take advantage of the Java exceptions
   mechanism, thus eliminating the need for calling errors.

   A GSS status code indicates a single fatal generic API error from the
   routine that has thrown the GSSException.  Using exceptions announces
   that a fatal error has occurred during the execution of the method.
   The GSS-API operational model also allows for the signaling of
   supplementary status information from the per-message calls.  These
   need to be handled as return values since using exceptions is not
   appropriate for informatory or warning-like information.  The methods
   that are capable of producing supplementary information are the two
   per-message methods GSSContext.verifyMIC() and GSSContext.unwrap().
   These methods fill the supplementary status codes in the MessageProp
   object that was passed in.

Top      ToC       Page 20 
   GSSException object, along with providing the functionality for
   setting of the various error codes and translating them into textual
   representation, also contains the definitions of all the numeric
   error values.  The following table lists the definitions of error
   codes:

      Table: GSS Status Codes

      Name                   Value   Meaning

      BAD_MECH                 1     An unsupported mechanism
                                     was requested.

      BAD_NAME                 2     An invalid name was supplied.

      BAD_NAMETYPE             3     A supplied name was of an
                                     unsupported type.

      BAD_BINDINGS             4     Incorrect channel bindings were
                                     supplied.

      BAD_STATUS               5     An invalid status code was
                                     supplied.

      BAD_MIC                  6     A token had an invalid MIC.

      NO_CRED                  7     No credentials were supplied, or
                                     the credentials were unavailable
                                     or inaccessible.

      NO_CONTEXT               8     Invalid context has been
                                     supplied.

      DEFECTIVE_TOKEN          9     A supplied token was invalid.

      DEFECTIVE_CREDENTIAL    10     A supplied credential was
                                     invalid.

      CREDENTIALS_EXPIRED     11     The referenced credentials
                                     have expired.

      CONTEXT_EXPIRED         12     The context has expired.

      FAILURE                 13     Miscellaneous failure,
                                     unspecified at the GSS-API level.

      BAD_QOP                 14     The quality-of-protection
                                     requested could not be provided.

Top      ToC       Page 21 
      UNAUTHORIZED            15     The operation is forbidden by
                                     local security policy.

      UNAVAILABLE             16     The operation or option is
                                     unavailable.

      DUPLICATE_ELEMENT       17     The requested credential
                                     element already exists.

      NAME_NOT_MN             18     The provided name was not a
                                     mechanism name.

      OLD_TOKEN               19     The token's validity period has
                                     expired.

      DUPLICATE_TOKEN         20     The token was a duplicate of an
                                     earlier version.

   The GSS major status code of FAILURE is used to indicate that the
   underlying mechanism detected an error for which no specific GSS
   status code is defined.  The mechanism-specific status code can
   provide more details about the error.

   The different major status codes that can be contained in the
   GSSException object thrown by the methods in this specification are
   the same as the major status codes returned by the corresponding
   calls in RFC 2743 [GSSAPIv2-UPDATE].

4.12.2.  Mechanism-specific status codes

   Mechanism-specific status codes are communicated in two ways, they
   are part of any GSSException thrown from the mechanism specific layer
   to signal a fatal error, or they are part of the MessageProp object
   that the per-message calls use to signal non-fatal errors.

   A default value of 0 in either the GSSException object or the
   MessageProp object will be used to represent the absence of any
   mechanism specific status code.

4.12.3.  Supplementary status codes

   Supplementary status codes are confined to the per-message methods of
   the GSSContext interface.  Because of the informative nature of these
   errors it is not appropriate to use exceptions to signal them.
   Instead, the per-message operations of the GSSContext interface
   return these values in a MessageProp object.

Top      ToC       Page 22 
   The MessageProp class defines query methods which return boolean
   values indicating the following supplementary states:

      Table: Supplementary Status Methods

      Method Name       Meaning when "true" is returned

      isDuplicateToken   The token was a duplicate of an
                         earlier token.

      isOldToken         The token's validity period has
                         expired.

      isUnseqToken       A later token has already been
                         processed.

      isGapToken         An expected per-message token was
                         not received.

   "true" return value for any of the above methods indicates that the
   token exhibited the specified property.  The application must
   determine the appropriate course of action for these supplementary
   values.  They are not treated as errors by the GSS-API.

4.13.  Names

   A name is used to identify a person or entity.  GSS-API authenticates
   the relationship between a name and the entity claiming the name.

   Since different authentication mechanisms may employ different
   namespaces for identifying their principals, GSS-API's naming support
   is necessarily complex in multi-mechanism environments (or even in
   some single-mechanism environments where the underlying mechanism
   supports multiple namespaces).

   Two distinct conceptual representations are defined for names:

   1) A GSS-API form represented by implementations of the GSSName
      interface: A single GSSName object may contain multiple names from
      different namespaces, but all names should refer to the same
      entity.  An example of such an internal name would be the name
      returned from a call to the getName method of the GSSCredential
      interface, when applied to a credential containing credential
      elements for multiple authentication mechanisms employing
      different namespaces.  This GSSName object will contain a distinct
      name for the entity for each authentication mechanism.

Top      ToC       Page 23 
      For GSS-API implementations supporting multiple namespaces,
      GSSName implementations must contain sufficient information to
      determine the namespace to which each primitive name belongs.

   2) Mechanism-specific contiguous byte array and string forms:
      Different GSSName initialization methods are provided to handle
      both byte array and string formats and to accommodate various
      calling applications and name types.  These formats are capable of
      containing only a single name (from a single namespace).
      Contiguous string names are always accompanied by an object
      identifier specifying the namespace to which the name belongs, and
      their format is dependent on the authentication mechanism that
      employs that name.  The string name forms are assumed to be
      printable, and may therefore be used by GSS-API applications for
      communication with their users.  The byte array name formats are
      assumed to be in non-printable formats (e.g.  the byte array
      returned from the export method of the GSSName interface).

   A GSSName object can be converted to a contiguous representation by
   using the toString method.  This will guarantee that the name will be
   converted to a printable format.  Different initialization methods in
   the GSSName interface are defined allowing support for multiple
   syntaxes for each supported namespace, and allowing users the freedom
   to choose a preferred name representation.  The toString method
   should use an implementation-chosen printable syntax for each
   supported name-type.  To obtain the printable name type,
   getStringNameType method can be used.

   There is no guarantee that calling the toString method on the GSSName
   interface will produce the same string form as the original imported
   string name.  Furthermore, it is possible that the name was not even
   constructed from a string representation.  The same applies to name-
   space identifiers which may not necessarily survive unchanged after a
   journey through the internal name-form.  An example of this might be
   a mechanism that authenticates X.500 names, but provides an
   algorithmic mapping of Internet DNS names into X.500.  That
   mechanism's implementation of GSSName might, when presented with a
   DNS name, generate an internal name that contained both the original
   DNS name and the equivalent X.500 name.  Alternatively, it might only
   store the X.500 name.  In the latter case, the toString method of
   GSSName would most likely generate a printable X.500 name, rather
   than the original DNS name.

   The context acceptor can obtain a GSSName object representing the
   entity performing the context initiation (through the usage of
   getSrcName method).  Since this name has been authenticated by a
   single mechanism, it contains only a single name (even if the
   internal name presented by the context initiator to the GSSContext

Top      ToC       Page 24 
   object had multiple components).  Such names are termed internal
   mechanism names, or "MN"s and the names emitted by GSSContext
   interface in the getSrcName and getTargName are always of this type.
   Since some applications may require MNs without wanting to incur the
   overhead of an authentication operation, creation methods are
   provided that take not only the name buffer and name type, but also
   the mechanism oid for which this name should be created.  When
   dealing with an existing GSSName object, the canonicalize method may
   be invoked to convert a general internal name into an MN.

   GSSName objects can be compared using their equal method, which
   returns "true" if the two names being compared refer to the same
   entity.  This is the preferred way to perform name comparisons
   instead of using the printable names that a given GSS-API
   implementation may support.  Since GSS-API assumes that all primitive
   names contained within a given internal name refer to the same
   entity, equal can return "true" if the two names have at least one
   primitive name in common.  If the implementation embodies knowledge
   of equivalence relationships between names taken from different
   namespaces, this knowledge may also allow successful comparisons of
   internal names containing no overlapping primitive elements.

   When used in large access control lists, the overhead of creating an
   GSSName object on each name and invoking the equal method on each
   name from the ACL may be prohibitive.  As an alternative way of
   supporting this case, GSS-API defines a special form of the
   contiguous byte array name which may be compared directly (byte by
   byte).  Contiguous names suitable for comparison are generated by the
   export method.  Exported names may be re-imported by using the byte
   array constructor and specifying the NT_EXPORT_NAME as the name type
   object identifier.  The resulting GSSName name will also be a MN.
   The GSSName interface defines public static Oid objects representing
   the standard name types.  Structurally, an exported name object
   consists of a header containing an OID identifying the mechanism that
   authenticated the name, and a trailer containing the name itself,
   where the syntax of the trailer is defined by the individual
   mechanism specification.  Detailed description of the format is
   specified in the language-independent GSS-API specification
   [GSSAPIv2-UPDATE].

   Note that the results obtained by using the equals method will in
   general be different from those obtained by invoking canonicalize and
   export, and then comparing the byte array output.  The first series
   of operation determines whether two (unauthenticated) names identify
   the same principal; the second whether a particular mechanism would
   authenticate them as the same principal.  These two operations will
   in general give the same results only for MNs.

Top      ToC       Page 25 
   It is important to note that the above are guidelines as how GSSName
   implementations should behave, and are not intended to be specific
   requirements of how names objects must be implemented.  The mechanism
   designers are free to decide on the details of their implementations
   of the GSSName interface as long as the behavior satisfies the above
   guidelines.

4.14.  Channel Bindings

   GSS-API supports the use of user-specified tags to identify a given
   context to the peer application.  These tags are intended to be used
   to identify the particular communications channel that carries the
   context.  Channel bindings are communicated to the GSS-API using the
   ChannelBinding object.  The application may use byte arrays to
   specify the application data to be used in the channel binding as
   well as using instances of the InetAddress.  The InetAddress for the
   initiator and/or acceptor can be used within an instance of a
   ChannelBinding.  ChannelBinding can be set for the GSSContext object
   using the setChannelBinding method before the first call to init or
   accept has been performed.  Unless the setChannelBinding method has
   been used to set the ChannelBinding for a GSSContext object, "null"
   ChannelBinding will be assumed.  InetAddress is currently the only
   address type defined within the Java platform and as such, it is the
   only one supported within the ChannelBinding class.  Applications
   that use other types of addresses can include them as part of the
   application specific data.

   Conceptually, the GSS-API concatenates the initiator and acceptor
   address information, and the application supplied byte array to form
   an octet string.  The mechanism calculates a MIC over this octet
   string and binds the MIC to the context establishment token emitted
   by init method of the GSSContext interface.  The same bindings are
   set by the context acceptor for its GSSContext object and during
   processing of the accept method a MIC is calculated in the same way.
   The calculated MIC is compared with that found in the token, and if
   the MICs differ, accept will throw a GSSException with the  major
   code set to BAD_BINDINGS, and the context will not be established.
   Some mechanisms may include the actual channel binding data in the
   token (rather than just a MIC); applications should therefore not use
   confidential data as channel-binding components.

   Individual mechanisms may impose additional constraints on addresses
   that may appear in channel bindings.  For example, a mechanism may
   verify that the initiator address field of the channel binding
   contains the correct network address of the host system.  Portable
   applications should therefore ensure that they either provide correct
   information for the address fields, or omit setting of the addressing
   information.

Top      ToC       Page 26 
4.15.  Stream Objects

   The context object provides overloaded methods which use input and
   output streams as the means to convey authentication and per-message
   GSS-API tokens.  It is important to note that the streams are
   expected to contain the usual GSS-API tokens which would otherwise be
   handled through the usage of byte arrays.  The tokens are expected to
   have a definite start and an end.  The callers are responsible for
   ensuring that the supplied streams will not block, or expect to block
   until a full token is processed by the GSS-API method.  Only a single
   GSS-API token will be processed per invocation of the stream based
   method.

   The usage of streams allows the callers to have control and
   management of the supplied buffers.  Because streams are non-
   primitive objects, the callers can make the streams as complicated or
   as simple as desired simply by using the streams defined in the
   java.io package or creating their own through the use of inheritance.
   This will allow for the application's greatest flexibility.

4.16.  Optional Parameters

   Whenever the application wishes to omit an optional parameter the
   "null" value shall be used.  The detailed method descriptions
   indicate which parameters are optional.  Methods overloading has also
   been used as a technique to indicate default parameters.



(page 26 continued on part 2)

Next RFC Part