[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                                 K. Damour
Updates: 4178 (if approved)                                 D. McPherson
Intended status: Informational                     Microsoft Corporation
Expires: January 8, 2009                                    July 7, 2008


          The Extended GSS-API Negotiation Mechanism (NEGOEX)
                          draft-zhu-negoex-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 8, 2009.

Abstract

   This document defines the Extended Generic Security Service
   Application Program Interface (GSS-API) Negotiation Mechanism
   (NegoEx).  NegoEx is a pseudo-security mechanism that logically
   extends the SPNEGO protocol as defined in RFC4178.

   The NegoEx protocol itself is a security mechanism negotiated by
   SPNEGO.  When selected as the common mechanism, NegoEx OPTIONALLY
   adds a pair of meta-data messages for each negotiated security
   mechanism.  The meta-data exchange allows security mechanisms to
   exchange auxiliary information such as trust configurations, thus
   NegoEx provides additional flexibility beyond the negotiation



Zhu, et al.              Expires January 8, 2009                [Page 1]


Internet-Draft                   NEGOEX                        July 2008


   capabilities based on exchanging object identifiers offered by
   SPNEGO.

   NegoEx preserves the optimistic token semantics of SPNEGO and applies
   that recursively.  Consequently a context establishment mechanism
   token can be included in the initial NegoEx message, and NegoEx does
   not require an extra round-trip when the initiator's optimistic token
   is accepted by the target.

   Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a
   security mechanism MUST support in order to be negotiated by NegoEx.
   This document defines these GSS-API extensions.

   Unlike SPNEGO however, NegoEx defines its own way for signing the
   protocol messages in order to protect the protocol negotiation.  The
   NegoEx message signing or verification can occur before the security
   context for the negotiated real security mechanism is fully
   established.

































Zhu, et al.              Expires January 8, 2009                [Page 2]


Internet-Draft                   NEGOEX                        July 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Requirements Terminology  . . . . . . . . . . . . . . . . . . . 6
   3.  Presentation Language . . . . . . . . . . . . . . . . . . . . . 6
   4.  Cryptographic Computations  . . . . . . . . . . . . . . . . . . 6
   5.  The NegoEx Protocol . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Supporting GSS-API Extensions . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   10. Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Apendix A. Protocol Data Structures and Constant
                Values . . . . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9



































Zhu, et al.              Expires January 8, 2009                [Page 3]


Internet-Draft                   NEGOEX                        July 2008


1.  Introduction

   If more than one GSS-API mechanism is shared between the client and
   the server, the Simple and Protected (GSS-API) Negotiation Mechanism
   (SPNEGO) as defined in [RFC4178] can be deployed to choose a mutually
   preferred one.  This pseudo mechanism does well in the most basic
   scenarios but suffers from a couple of drawbacks, notably:

   o  First, the SPNEGO negotiation model is inefficient when
      negotiating based on mechanism specific configuration information.
      SPNEGO negotiation is based on by exchanging object identifiers
      only, and it does not allow exchange of auxiliary information in
      any other from.  This is inefficient and often impractical in that
      one object identifier effectively conveys only one bit of
      information.

   o  Secondly, the SPNEGO negotiation model is inadequate when the
      choice cannot be made by the acceptor in the initial response.  In
      SPNEGO, the negotiation information is sent one-way from the
      initiator for the acceptor to make a choice, and the acceptor must
      choose one when it makes the initial response.  This negotiation
      model is counter intuitive.  The selection of a security mechanism
      is typically the result of selecting one type of credentials from
      the available set, and the initiator typically does not wish to
      reveal credentials information often associated with user
      identities.  In practice, in order to operate in this model, the
      Kerberos GSS-API mechanism [RFC4121] must acquire the context
      establishment token in the initial call to GSS_Init_sec_context().
      If the initiator fails to acquire the Kerberos token, it must not
      offer Kerberos; otherwise the SPNEGO context negotiation will fail
      without being able to select the next available mechanism that
      could work.  Obtaining the initial Kerberos GSS-API context token
      may require multiple round-trips of network calls and the cost of
      the operation can be substantial.  It is evidently suboptimal when
      multiple GSS-API mechanisms have to operate this way.  The cost of
      authentication of any real security mechanism should be avoided or
      minimized by SPNEGO when the security mechanism is not negotiated
      eventually but such considerations are not facilitated by the
      SPNEGO negotiation model.

   The Extended Generic Security Service Application Program Interface
   (GSS-API) Negotiation Mechanism (NegoEx) is defined to address these
   concerns.  NegoEx is a pseudo security mechanism that is negotiated
   by SPNEGO and when negotiated, it can recursively negotiate real
   security mechanisms.

   Any security mechanism negotiated by NegoEx MUST support integrity
   protection.



Zhu, et al.              Expires January 8, 2009                [Page 4]


Internet-Draft                   NEGOEX                        July 2008


   The basic form of NegoEx works as follows:

   1.  The initiator proposes a list of mechanisms in decreasing
       preference order.  For each of these mechanism, NegoEx
       OPTIOINALLY includes a mechanism specific meta-data token.  GSS-
       API extensions are defined later in this document for NegoEx to
       query the meta-data token for inclusion in the NegoEx message.

   2.  The acceptor then passes the meta-data token from the initiator
       to the intended security mechanism.  A meta-token for a security
       mechanism not supported on the acceptor side is ignored.  New
       GSS-API extensions are defined later in this document for a
       security mechanism to consume the meta-data token.  When
       processing the received meta-data token, a security mechanism
       that reports a failure is removed from the set of mutually
       supported mechanisms.  The acceptor then responds with the list
       of mutually supported mechanisms in decreasing preference order.
       For each of these mechanism, NegoEx again OPTIOINALLY supplies a
       mechanism specific meta-data token in the response.  These meta-
       data tokens are returned to NegoEx via new GSS-API extensions as
       described in the initial step.

   3.  The initiator then passes the meta-data token to the intended
       security mechanism by invoking the new GSS-API extensions.  When
       processing the received meta-data token, a security mechanism
       that reports a failure is removed from the set of mutually
       supported mechanisms.  The initiator then selects a security
       mechanism from the set of mutually-supported ones.  If more than
       one security mechanism is available, unless otherwise specified,
       the preferred one in the server preference order SHOULD be
       selected.  Once the common security mechanism is identified, the
       security mechanism may also negotiate mechanism-specific options
       during its context establishments.  This will be inside the
       mechanism tokens, and invisible to the NegoEx protocol.

   4.  The selected security mechanism provides keying materials to
       NegoEx, and NegoEx then signs and verifies the negotiation NegoEx
       messages to protect the negotiation.

   5.  The initiator and the acceptor proceed to exchange tokens till
       the GSS-API context for selected security mechanism is
       established, Once the security context is established, the per-
       message tokens are generated and verified in accordance with the
       selected security mechanism.

   NegoEx does not work outside of SPNEGO.  When negotiated by SPNEGO,
   NegoEx uses the concepts developed in the GSS-API specification [1].
   The negotiation data is encapsulated in context-level tokens.



Zhu, et al.              Expires January 8, 2009                [Page 5]


Internet-Draft                   NEGOEX                        July 2008


   Therefore, callers of the GSS-API do not need to be aware of the
   existence of the negotiation tokens but only of the SPENGO pseudo-
   security mechanism.

   In its basic form NegoEx requires at least one extra round-trip.
   Network connection setup is a critical performance characteristic of
   any network infrastructure and extra round trips over WAN links,
   packet radio networks, etc. really make a difference.  In order to
   avoid such an extra round trip the initial security token of the
   preferred mechanism for the initiator may be embedded in the initial
   NegoEx token.  The optimistic mechanism token may be accompanied by
   the meta-data tokens and the optimistic mechanism token MUST be that
   of the first mechanism in the list of the mechanisms proposed by the
   initiator.  The signature of NegoEx messages for protecting the
   NegoEx negotiation can also be included along with the mechanism
   token.  If the target preferred mechanism matches the initiator's
   preferred mechanism, and when the NegoEx negotiation protection
   messages are included along with the mechanism token, no additional
   round trips are incurred by using the negotiation protocol.


2.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Presentation Language

   This document deals with the formatting of data in an external
   representation.  The following very basic and somewhat casually
   defined presentation syntax will be used.  The syntax draws from
   several sources in its structure.  Although it resembles the
   programming language "C" in its syntax, it would be risky to draw too
   many parallels.  The purpose of this presentation language is to
   document NegoEx only; it has no general application beyond that
   particular goal.


4.  Cryptographic Computations

   The message signing and verificaiton in NegoEx is based on[RFC3961].
   [RFC3961] is used here as a generic framework and this application is
   not Kerberos specifc.






Zhu, et al.              Expires January 8, 2009                [Page 6]


Internet-Draft                   NEGOEX                        July 2008


5.  The NegoEx Protocol

   TBD.


6.  Supporting GSS-API Extensions

   TBD.


7.  Security Considerations

   TBD


8.  Acknowledgements

   TBD.


9.  IANA Considerations

   There is no action required for IANA.


10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, February 2005.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              July 2005.

   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
              Simple and Protected Generic Security Service Application
              Program Interface (GSS-API) Negotiation Mechanism",



Zhu, et al.              Expires January 8, 2009                [Page 7]


Internet-Draft                   NEGOEX                        July 2008


              RFC 4178, October 2005.


Appendix A.  Apendix A. Protocol Data Structures and Constant Values

   TBD


Authors' Addresses

   Larry Zhu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   Email: lzhu@microsoft.com


   Kevin Damour
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   Email: kdamour@microsoft.com


   Dave McPherson
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   Email: davemm@microsoft.com
















Zhu, et al.              Expires January 8, 2009                [Page 8]


Internet-Draft                   NEGOEX                        July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Zhu, et al.              Expires January 8, 2009                [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/