Protocol Action: Common Authentication Technology Protocols to Proposed Standard

[IESG Secretary <[e-mail]>]

The IESG has approved the Internet-Drafts:
  
  o "Generic Security Service Application Program Interface"
    <draft-ietf-cat-genericsec-04.txt>

  o "The Kerberos Network Authentication Service (V5)"
    <draft-ietf-cat-kerberos-02.txt, .ps> 

  o "Generic Security Service API : C-bindings"
    <draft-ietf-cat-secservice-02.txt>

as a Proposed Standard. This document is the product of the Common 
Authentication Technology Working Group. The IESG contact person is 
Stephen Crocker.                                                    
 
Technical Summary
 
  The top-level GSS-API document has been reviewed by three
  independent individuals, all of whom provided comments that have been
  accommodated by the document's editor.  The GSS-API C bindings and
  Kerberos V5 specifications have also been independently reviewed.
  Each of the documents has been the basis for implementation
  activities.

  The publication of these specifications as Internet standards should
  foster widespread deployment of authentication and integrity services
  in connection-oriented protocols, e.g., TELNET and FTP. By insulating
  protocols from the details of the security services, the CAT approach
  frees them to focus on completing their task and assures that all
  protocols benefit from the availability of robust and stable security
  services,i.e., each protocol need not revisit the issues.

  Technical Summary of <draft-ietf-cat-genericsec-04.txt>

    This Generic Security Service Application Program Interface (GSS-API)
    definition provides security services to callers in a generic
    fashion, supportable with a range of underlying mechanisms and
    technologies and hence allowing source-level portability of
    applications to different environments. This specification defines
    GSS-API services and primitives at a level independent of underlying
    mechanism and programming language environment, and is to be
    complemented by other, related specifications:
   
    o documents defining specific parameter bindings for particular
      language environments
   
    o documents defining token formats, protocols, and procedures to be
      implemented in order to realize GSS-API services atop particular
      security mechanisms
   
    The operational paradigm in which GSS-API operates is as follows. A
    typical GSS-API caller is itself a communications protocol, calling
    on GSS-API in order to protect its communications with
    authentication, integrity, and/or confidentiality security services.
    A GSS-API caller accepts tokens provided to it by its local GSS-API
    implementation and transfers the tokens to a peer on a remote system;
    that peer passes the received tokens to its local GSS-API
    implementation for processing. The security services available
    through GSS-API in this fashion are implementable (and have been
    implemented) over a range of underlying mechanisms based on
    secret-key and public-key cryptographic technologies.
   
    The GSS-API separates the operations of initializing a security
    context between peers, achieving peer entity authentication, from the
    operations of providing per-message data origin authentication and
    data integrity protection for messages subsequently transferred in
    conjunction with that context. Per-message calls provide the data
    origin authentication and data integrity services and also support
    selection of confidentiality services as a caller option. Additional
    calls provide supportive functions to the GSS-API's users.

    The GSS-API design assumes and addresses several basic goals,
    including:
 
    o Mechanism independence: The GSS-API defines an interface to
      cryptographically implement strong authentication and other
      security services at a generic level which is independent of
      particular underlying mechanisms. For example, GSS-API-provided
      services can be implemented by secret-key technologies (e.g.,
      Kerberos) or public-key approaches (e.g., X.509).
   
    o Protocol environment independence: The GSS-API is independent of
      the communications protocol suites with which it is employed,
      permitting use in a broad range of protocol environments. In
      appropriate environments, an intermediate implementation "veneer"
      which is oriented to a particular communication protocol (e.g.,
      Remote Procedure Call (RPC)) may be interposed between applications
      which call that protocol and the GSS-API, thereby invoking GSS-API
      facilities in conjunction with that protocol's communications
      invocations.
   
    o Protocol association independence: The GSS-API's security context
      construct is independent of communications protocol association
      constructs. This characteristic allows a single GSS-API
      implementation to be utilized by a variety of invoking protocol
      modules on behalf of those modules' calling applications. GSS-API
      services can also be invoked directly by applications, wholly
      independent of protocol associations.
   
    o Suitability to a range of implementation placements: GSS- API
      clients are not constrained to reside within any Trusted Computing
      Base (TCB) perimeter defined on a system where the GSS-API is
      implemented; security services are specified in a manner suitable
      to both intra-TCB and extra-TCB callers.

  Technical Summary of <draft-ietf-cat-secservice-02.txt>

    This draft document specifies C language bindings for the Generic
    Security Service Application Program Interface (GSS-API), which is
    described at a language-independent conceptual level in the preceding
    draft. It has been the basis for multiple prototyping and
    implementation activities, and has been refined as a result of the
    experience gained.

  Technical Summary of <draft-ietf-cat-kerberos-02.<txt,ps>>

    This document gives an overview and specification of Version 5 of the
    protocol for the Kerberos network authentication system.  Version 4,
    described elsewhere, is presently in production use at MIT's Project
    Athena, and at other Internet sites.

Working Group Summary
 
  The CAT Working Group was chartered to create the GSS-API
  specifications and specifications for supporting mechanisms; the
  current set of documents represent substantial work, working group
  consensus, and have been available as Internet-Drafts since 1992.  It
  is recognized, and was recognized when the WG was chartered, that API
  definition is an unusual activity for (traditionally
  protocol-oriented) IETF WGs; the fact that this API is targeted for
  consumption by IETF-standardized protocols as a means for integrating
  security into those protocols provides rationale for carrying out
  this work in the IETF environment. The current Kerberos V5
  specification as proposed for advancement represents the culmination
  of many years' implementation and specification effort.  It is
  expected that additional CAT mechanisms will be documented in
  Internet standards-track and experimental specifications.
 
Protocol Quality

  The documents are well-written and easy to understand.  

  It is the belief of the WG that this set of specifications will be
  sufficient to support independent implementations, and indeed the set
  has served as the basis for several prototype and development
  activities.  While no implementations available at this time are
  wholly complete and updated to match the current document versions,
  it is anticipated that advancement of the specifications to Proposed
  Standards will engender broadened and intensified development
  efforts.