Internet DRAFT - draft-williams-kitten-impersonation-naming-attr

draft-williams-kitten-impersonation-naming-attr






Network Working Group                                        N. Williams
Internet-Draft                                              Cryptonector
Updates: 1964, 2743, 2744                               October 27, 2014
(if approved)
Intended status: Standards Track
Expires: April 30, 2015


    Impersonation Naming Attribute for the Generic Security Services
              Application Programming Interface (GSS-API)
           draft-williams-kitten-impersonation-naming-attr-01

Abstract

   This document describes a method for impersonation of one principal
   by another.  Relying parties are expected to apply policy to decide
   which impersonation attempts they accept.  Trusted third parties may
   provide assistance in evaluating policy.  The proposed system fails
   safe: applications that do not support it see their peers as the
   impersonators, not the impersonated principals.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 30, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Williams                 Expires April 30, 2015                 [Page 1]

Internet-Draft              GSS Impersonation               October 2014


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.          Introduction and Motivation  . . . . . . . . . . . . .  3
   1.1.        Comparison to S4U  . . . . . . . . . . . . . . . . . .  3
   1.1.1.      Comparison to S4U2Proxy  . . . . . . . . . . . . . . .  4
   1.2.        Conventions used in this document  . . . . . . . . . .  5
   2.          Generic Interfaces for Impersonation . . . . . . . . .  6
   2.1.        Naming Attributes for Generic Impersonation  . . . . .  6
   2.1.1.      C Bindings . . . . . . . . . . . . . . . . . . . . . .  7
   2.2.        GSS_Acquire_cred_impersonate_name()  . . . . . . . . .  7
   2.2.1.      C Bindings of GSS_Acquire_cred_impersonate_name()  . .  8
   2.3.        Apparent Credential Delegation . . . . . . . . . . . .  8
   2.4.        Intended Usage . . . . . . . . . . . . . . . . . . . .  8
   2.5.        Local Policy . . . . . . . . . . . . . . . . . . . . .  9
   2.6.        Third-Party Impersonation Policy Assistance  . . . . .  9
   3.          Kerberos Bindings of Impersonation Attributes  . . . . 10
   3.1.        Client Processing  . . . . . . . . . . . . . . . . . . 10
   3.2.        TGS Processing (OPTIONAL)  . . . . . . . . . . . . . . 11
   3.3.        Target Service Processing  . . . . . . . . . . . . . . 11
   4.          Sample Code  . . . . . . . . . . . . . . . . . . . . . 12
   5.          Security Considerations  . . . . . . . . . . . . . . . 13
   5.1.        Security Requirements and Recommendations  . . . . . . 13
   6.          IANA Considerations  . . . . . . . . . . . . . . . . . 15
   7.          References . . . . . . . . . . . . . . . . . . . . . . 16
   7.1.        Normative References . . . . . . . . . . . . . . . . . 16
   7.2.        Informative References . . . . . . . . . . . . . . . . 16
   Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 17
               Author's Address . . . . . . . . . . . . . . . . . . . 18

















Williams                 Expires April 30, 2015                 [Page 2]

Internet-Draft              GSS Impersonation               October 2014


1.  Introduction and Motivation

   A very common application design involves services that must
   impersonate their clients to other services.  There are two common
   designs for enabling this:

   credential delegation  where clients delegate credentials to the
      impersonators,

   explicit impersonation  where impersonators explicitly state that
      they are impersonating others.

   There exist protocols where the explicit impersonation concept is
   difficult to retrofit.  And there exist protocols where credential
   delegation is the commonly-deployed -and therefore expected- method
   for impersonation.  Therefore explicit impersonation is not
   universally available.

   On the other hand, unconstrained credential delegation is dangerous
   (for obvious reasons).  What to do?

   One answer has been constrained delegation.  In this design the
   credential issuer creates a credential for impersonating the client,
   but in a constrained way (e.g., to only a small set of downstream
   services).  But constrained credential delegation is difficult to
   manage: the constraints must be expressed by parties that aren't
   best-placed to know the desired policy.

   We propose a simple solution for Generic Security Services
   Application Programming Interface (GSS-API) [RFC2743] applications:
   have the impersonator use their own credential (or one specifically
   for this purpose) and assert the name of the principal to be
   impersonated as a name attribute.  This is very similar to the
   concept of "authz-id" in Simple Authentication and Security Layers
   (SASL) [RFC4422], but with some subtle differences as described
   below.  We also propose the addition of a name attribute with the
   same semantics as the SASL authz-id.

1.1.  Comparison to S4U

   There is an extension for Kerberos [RFC4120] known as Services for
   User (S4U) [S4U] which provides for impersonation.  S4FU is available
   to GSS-API applications via the Kerberos GSS-API mechanism [RFC1964]
   [RFC4121], naturally.

   A complete treatment of S4U is out of scope for this document,
   however, a brief summary is as follows.  S4U consists of two sub-
   protocols for impersonation:



Williams                 Expires April 30, 2015                 [Page 3]

Internet-Draft              GSS Impersonation               October 2014


   S4U2Self  Allows services to use their own credentials to obtain KDC-
      issued authorization-data for principals to be impersonated.

   S4U2Proxy  Allows services to use clients' service tickets as
      "evidence" tickets with which (and together with the
      impersonator's credentials) to obtain other tickets in the name of
      the client principals to be impersonated.

   This document concerns itself only with functionality like that of
   S4U2Proxy.

   There are several differences between this proposal and S4U2Proxy:

   1.  At no point does a KDC issue a ticket to an impersonator with the
       impersonated principal's name as the cname/crealm.  This permits
       access to services in the impersonated principal's home realm.

   2.  No "evidence" tickets are required or used.

   3.  No KDC support is required, but may be provided.

   4.  No KDC-side policy is required, but may be provided.

   (1) is the initial motivation for this work: S4U does not permit
   services not in the impersonated principal's realm to impersonate it
   to services in that same realm.  This is because any service ticket
   issued for such access would appear to transit a trust path back to
   the impersonated principal's realm, thus triggering loop detection.
   A better fix for this might be to permit exactly one full cycle
   precisely so as to permit this and other similar use cases.  However,
   the other differences and advantages over S4U2Proxy are compelling.

   This proposal _does not_ intend to entirely replace S4U. In
   particular, in use cases where Kerberos tickets carry KDC-issued
   authorization-data, the services to which principals are successfully
   impersonated may need to use S4U2Self in order to obtain that
   authorization-data if they have no other method available by which to
   get it.

1.1.1.  Comparison to S4U2Proxy

   Our method of impersonation has a number of advantages to S4U:

   o  it is simpler (no need for evidence tickets and related
      cryptographic sub-protocols, no need for KDC-side policy, and even
      where KDCs apply additional policy, this method imposes no new
      requirements for additional cryptographic operations on either the
      impersonator's nor the KDC's part);



Williams                 Expires April 30, 2015                 [Page 4]

Internet-Draft              GSS Impersonation               October 2014


   o  it adheres strictly to the Kerberos model whereby application-
      local policy has the last word and KDCs need not apply any policy;

   o  it fails safe when used with peers that do not implement it (and
      therefore do not apply local policy to impersonation attempts);

   o  it permits impersonation of principals whose names are not
      Kerberos principal names.

1.2.  Conventions used in this document

   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].





































Williams                 Expires April 30, 2015                 [Page 5]

Internet-Draft              GSS Impersonation               October 2014


2.  Generic Interfaces for Impersonation

   We provide three interfaces for impersonation:

   o  naming attributes [RFC6680] (see Section 2.1);

   o  a function, GSS_Acquire_cred_impersonate_name() and its C
      programming language bindings patterned after the GSS-APIv2u1 C
      bindings [RFC2744] (see Section 2.2);

   o  apparent credential delegation, even when credential delegation
      has not taken place (see Section 2.3).

2.1.  Naming Attributes for Generic Impersonation

   We define two generic GSS-API naming attributes [RFC6680] for
   impersonation:

   GSS_C_ATTR_IMPERSONATED_PRINCIPAL  This attribute notionally carries
      an exported name token representation of the name of the principal
      to be impersonated by the principal whose CREDENTIAL HANDLE's
      desired NAME has this attribute.  This is subtly different from
      SASL's authz-id concept in that the latter carries an application-
      specific name form while this one carries a mechanism-specific
      name form (though not necessarily the same mechanism as is used to
      authenticate the impersonator!).  When obtained with
      GSS_Get_name_attribute() the display_value of this attribute
      SHOULD be a display form of the impersonated name else it MUST be
      empty, whereas the non-display form MUST be an octet string
      suitable for use as an input to GSS_Import_name() with
      GSS_C_NT_EXPORTED_NAME or GSS_C_NT_COMPOSITE_EXPORT.

   GSS_C_ATTR_AUTHZ_ID  This attribute carries an application-specific
      name form corresponding to an identity that is to be impersonated
      (by the principal whose CREDENTIAL HANDLE's desired NAME has this
      attribute).  This attribute's semantics are exactly like SASL's.
      Interpretation of this attribute's non-display value is
      application-specific; the display value of this attribute is
      empty.

   Mechanisms MAY support credential delegation for credentials with
   these attributes set, however, if they do they MUST constrain the
   delegated credentials such that they may only be used to impersonate
   the same principal or assert the same authz-id as in the security
   context token exchange where the credential was delegated.
   Impersonator applications are encouraged to not delegate
   impersonation credentials; instead their peers should should use
   impersonation if necessary.



Williams                 Expires April 30, 2015                 [Page 6]

Internet-Draft              GSS Impersonation               October 2014


   [[anchor1: TBD: Should we specify a way to denote authz-id form,
   e.g., via a URN?  Perhaps by convention the authz-id should generally
   be prefixed with a URN denoting its form, and perhaps there should be
   a URN for denoting "private to the application using it".  Of course,
   that would be an optional convention, and anyways, it's not necessary
   (SASL doesn't have it).]]

2.1.1.  C Bindings

   [[anchor2: TBD.  Obviously the bindings consist of the same symbols
   as shown above; their values should be of type gss_buffer_desc,
   pointing to the URNs assigned herein (still TBD).]]

2.2.  GSS_Acquire_cred_impersonate_name()

   Inputs:

   impersonator_cred_handle CREDENTIAL HANDLE  A handle for the
      impersonator's credentials.

   desired_name NAME  The name of the principal to be impersonated.

   time_req INTEGER  Same as for GSS_Acquire_cred() [RFC2743].

   desired_mechs SET OF OBJECT IDENTIFIER  Same as for
      GSS_Acquire_cred() [RFC2743].

   cred_usage INTEGER  Same as for GSS_Acquire_cred() [RFC2743].

   Outputs:

   major status INTEGER

   minor status INTEGER

   output_cred_handle CREDENTIAL HANDLE  If returned, these are the
      credentials for impersonating the desired_name.

   actual_mechs SET OF OBJECT IDENTIFIER  Same as for GSS_Acquire_cred()
      [RFC2743].

   time_rec INTEGER  Same as for GSS_Acquire_cred() [RFC2743].

   This function is just like GSS_Acquire_cred(), from the base GSS-
   APIv2u1 RFC2743 specification, but with the addition of an input for
   the impersonator's credentials.

   This function may be used with S4U2Self or it may be equivalent to



Williams                 Expires April 30, 2015                 [Page 7]

Internet-Draft              GSS Impersonation               October 2014


   acquiring credentials for the impersonator's NAME but with one or
   both of the name attributes described in Section 2.1.

   [[anchor3: TBD: Describe any differences from GSS_Acquire_name() as
   to major status codes.]]

2.2.1.  C Bindings of GSS_Acquire_cred_impersonate_name()

    OM_uint32 gss_acquire_cred_impersonate_name(
            OM_uint32 *minor_status,
            const gss_cred_id_t impersonator_cred_handle,
            const gss_name_t desired_name,
            OM_uint32 time_req,
            const gss_OID_set desired_mechs,
            gss_cred_usage_t cred_usage,
            gss_cred_id_t *output_cred_handle,
            gss_OID_set *actual_mechs,
            OM_uint32 *time_rec);

               Figure 1: gss_acquire_cred_impersonate_name()

2.3.  Apparent Credential Delegation

   When an initiator uses impersonation but does not request and perform
   credential delegation, and the acceptor is so configured, the
   acceptor mechanism SHOULD pretend that the initiator delegated a
   credential to impersonate the same principal/authz-id as impersonated
   to the acceptor if the acceptor has credentials for a principal
   suitable for use as an impersonator.

   When an initiator uses impersonation and does request and
   successfully perform credential delegation, the issuer of the
   delegated credentials SHOULD constrain that credential to carry the
   same impersonation name attributes as the initiator's.

2.4.  Intended Usage

   Impersonator applications are expected to create a NAME object for
   their impersonator principal name, set one, the other, or even both
   of the impersonation attributes described in Section 2.1, acquire a
   credential for this NAME as the desired_name, then use this
   credential handle with GSS_Init_sec_context() (or even
   GSS_Accept_sec_context()) to authenticate to other services (or
   initiators).

   Impersonator applications SHOULD take care to use an impersonator
   name that does not denote any access or privilege beyond
   impersonation [to peers that will trust it so].



Williams                 Expires April 30, 2015                 [Page 8]

Internet-Draft              GSS Impersonation               October 2014


2.5.  Local Policy

   Applications that are not aware of impersonation MUST observe a
   security context's peer's name as the impersonator name:
   impersonation fails safe.

   Applications that are impersonation-aware SHOULD obtain the name of
   the principal to be impersonated and if so, MUST apply local policy
   to determine if the impersonator principal is permitted to
   impersonate the requested principal to the application.

2.6.  Third-Party Impersonation Policy Assistance

   Trusted third parties (e.g., Kerberos KDCs) may reject impersonation
   using policy local to them.  Trusted third parties may also bless
   impersonation attempts, but application local policy must still be
   applied (even if that policy is to accept a trusted third party's
   blessing).

   Trusted third party policy is conveyed to application via their use
   (or non-use) of the GSS_C_ATTR_GENERIC_UNCONSTRAINED or
   GSS_C_ATTR_GENERIC_UNCONSTRAINED_OK name attribute prefixes together
   with the 'authenticated' output of GSS_Get_name_attributes()
   [I-D.williams-kitten-generic-naming-attributes].

   See [I-D.williams-kitten-generic-naming-attributes] for more
   information on the semantics of the GSS_C_ATTR_GENERIC_UNCONSTRAINED
   and GSS_C_ATTR_GENERIC_UNCONSTRAINED_OK name attribute prefixes.























Williams                 Expires April 30, 2015                 [Page 9]

Internet-Draft              GSS Impersonation               October 2014


3.  Kerberos Bindings of Impersonation Attributes

   For Kerberos [RFC4120] we use authorization-data, which may be
   carried in either Tickets or Authenticators, and may or may not be
   embedded in AD-KDC-ISSUED or similar (when embedded in a Ticket).
   KDC policy approval is expressed via embedding these authorization-
   data in AD-KDC-ISSUED or similar (in a Ticket).  KDC policy
   application is requested by placing the authorization-data in a TGS-
   REQ's enc-authorization-data.

   KDC support for all these authorization-data elements is OPTIONAL.

   Use of these authorization-data elements entirely in the
   Authenticator is sufficient for most uses.  Use in Tickets is only
   required for a) application of more general KDC-side policy
   (otherwise the KDC doesn't see who is being impersonated), b) for
   requesting FORWARDED impersonation Tickets (which, as described
   Section 2.1, is OPTIONAL.

   The authorization-data element is:

   AD-IMPERSONATE-GSS  Indicates that the Ticket or Authenticator is
      intended to impersonate the given principal.  The octet string
      value of this element is an exported GSS-API name token

   AD-ASSERT-AUTHZID  Indicates that the Ticket or Authenticator is
      intended to impersonate the given authzid (SASL semantics).  The
      octet string value of this element is application-specific,
      therefore clients SHOULD NOT request this element be added to
      TGTs.

   (Note that no ASN.1 syntax is needed to describe these authorization-
   data elements' values.)

3.1.  Client Processing

   Clients MAY embed AD-IMPERSONATE-GSS and/or AD-ASSERT-AUTHZID in an
   AD-IF-RELEVANT authorization-data element in TGS requests for new
   Tickets, except when requesting forwarded/forwardable Tickets, in
   which case the element MUST be made critical (by not including it in
   any authorization-data element that denotes non-criticality).

   Clients that do not need or do not want KDC blessing SHOULD only
   include these authorization-data elements in Authenticators.  The
   client MAY include these elements in AD-IF-RELEVANT (on the theory
   that it's safe for the target service to observe the impersonator's
   name instead of the impersonated name), but the client SHOULD make
   these authorization-data elements critical to ensure that the target



Williams                 Expires April 30, 2015                [Page 10]

Internet-Draft              GSS Impersonation               October 2014


   service rejects the AP-REQ if it does not understand them.

3.2.  TGS Processing (OPTIONAL)

   TGSes need not have any further support for these authorization-data
   elements than is required by RFC4120.  However, a TGS may contribute
   its own local policy by including any AD-IMPERSONATE-GSS or AD-
   ASSERT-AUTHZID elements from a TGS-REQ's enc-authorization-data (or
   from a TGT's authorization-data) in AD-KDC-ISSUED (or similar)
   elements.  A TGS MUST NOT include these attributes in AD-KDC-ISSUED
   (or similar) without having applied local policy and determined that
   the client principal is permitted to make the requested assertions to
   the requested target service principal.

   A TGS can only interpret AD-ASSERT-AUTHZID elements relative to the
   target service principal name.  As there is no authzid concept for
   TGS principals, the TGS MUST NOT include AD-ASSERT-AUTHZID elements
   in any AD-KDC-ISSUED (or similar) elements when the sname of the
   Ticket to be issued is a TGS name.  But a TGS may be able to
   interpret (and therefore apply local policy) authzids in other cases.

   TGS policy MUST NOT bless (i.e., include these elements in AD-KDC-
   ISSUED or similar) requests with multiple instances of either AD-
   IMPERSONATE-GSS or AD-ASSERT-AUTHZID.

   As usual, per-RFC4120, if these authorization-data elements appear in
   the enc-authorization-data field of the TGS-REQ and/or the TGT, then
   the TGS should copy them to the issued Ticket.  But if the TGS has
   policy approving of the requested impersonation, then it SHOULD
   include the impersonation authorization-data elements in a critical
   AD-KDC-ISSUED (or similar) element.

3.3.  Target Service Processing

   Services must adhere to the authorization-data handling rules
   specified in RFC4120.  Services that implement these authorization-
   data element MUST expose them to applications in some manner (e.g.,
   as GSS-API naming attributes, as described in this document).

   Service implementations MAY apply local policy as to AD-IMPERSONATE-
   GSS on behalf of specific applications and, when local policy
   approves, may report the client's principal name as the impersonated
   principal name.  However, it is preferred that applications apply
   local policy, not the Kerberos implementation.

   Services MUST reject AP-REQs with multiple distinct AD-IMPERSONATE-
   GSS or AD-ASSERT-AUTHZID elements.




Williams                 Expires April 30, 2015                [Page 11]

Internet-Draft              GSS Impersonation               October 2014


4.  Sample Code

    <TBD>
    /*
     * Roughly this looks like:
     *  - if the impseronator application is an acceptor
     *    it calls gss_accept_sec_context() and gets a
     *    delegated credential handle even when the initiator
     *    didn't request delegation;
     *  - else the impersonator calls
     *    gss_acquire_cred_impersonate_name()
     *    to acquire a credential for impersonating a given
     *    principal;
     *
     * then the application calls gss_init_sec_context() with
     * the impersonation credential as the initiator credential
     * handle.
     */
     <TBD>

                     Figure 2: Impersonator-side code

    <TBD>
    /*
     * An impersonation-aware acceptor application
     * uses gss_get_name_attribute() to check whether
     * its peers' NAMEs (values of gss_name_t type output by
     * gss_accept_sec_context()) have either or both of the
     * GSS_C_ATTR_IMPERSONATED_PRINCIPAL and/or
     * GSS_C_ATTR_AUTHZ_ID name attributes -prefixed with
     * GSS_C_ATTR_GENERIC_UNCONSTRAINED_OK- set, and if so,
     * then they check local policy.
     *
     * Third-party policy can be checked by checking the
     * 'authenticated' boolean output of gss_get_name_attribute()
     * or by not prefixing with either these attributes with either
     * GSS_C_ATTR_GENERIC_UNCONSTRAINED_OK nor
     * GSS_C_ATTR_GENERIC_UNCONSTRAINED.
     */

                       Figure 3: Acceptor-side code

   [[anchor4: Also add sample code using the authz-id attribute.]]








Williams                 Expires April 30, 2015                [Page 12]

Internet-Draft              GSS Impersonation               October 2014


5.  Security Considerations

   This entire document deals with security.  Specifically this document
   provides a method for denoting impersonation while failing safe when
   peers do not support this method.  Failing safe means: peers observe
   the impersonator's name, not the impersonated name, and impersonator
   applications fail when their GSS-API implementation is not
   impersonation-aware.

   Local policy is to be used for deciding when impersonators may
   impersonate any one entity to another.  Such policy must be local to
   the impersonators' peers.  Third parties may apply policy as well in
   some cases, but local policy must always be able to reject
   impersonation.  Policy MUST be applied by applications.
   Implementations MAY provide a method by which local policy may be
   indicated in an indirect manner (e.g., via "environment variables")
   and evaluated by the GSS-API provider on behalf of the application;
   this is strictly to avoid having to modify existing GSS-API
   applications, but should not be encouraged beyond that purpose.

   [[anchor5: Should add text about when and why one might need or use
   impersonation.]]

5.1.  Security Requirements and Recommendations

   GSS_Set_name_attribute() is required to fail when used with
   attributes not understood by the mechanism.  This ensures that
   impersonators applications that set these attributes do not
   accidentally fail to actually use them when impersonating principals.
   Some additional safe-guards MAY be applied:

   o  impersonator applications SHOULD use a credential that denotes no
      other privileges;

   o  credential issuers (e.g., Kerberos KDCs) MAY constrain the use of
      credentials for known impersonator principals to requesting
      credentials for impersonation.

   In particular, for Kerberos, KDCs SHOULD NOT issue Ticket Granting
   Tickets (TGTs) with the FORWARDED or FORWARDABLE flags set if the
   Ticket's client principal is a known impersonator and the AD-
   IMPERSONATE-GSS authorization-data element is not present in the
   client's Ticket and/or TGS-REQ as a critical authorization-data
   element; if AD-IMPERSONATE-GSS is present in the Ticket as a critical
   and KDC-issued element but not in the TGS-REQ then the KDC SHOULD
   copy the AD-IMPERSONATE-GSS to the Ticket to be issued.

   Kerberos initiators should (as opposed to SHOULD, but perhaps this



Williams                 Expires April 30, 2015                [Page 13]

Internet-Draft              GSS Impersonation               October 2014


   should be a SHOULD) use impersonator names that begin with a zeroth
   component with this value: "IMPERSONATE".

   Our approach fails safe: service applications that are not aware of
   impersonation will not think that they are talking to the principal
   that an impersonator wishes to impersonate, and impersonator
   applications should fail when their GSS-API mechanism implementations
   do not support this feature.











































Williams                 Expires April 30, 2015                [Page 14]

Internet-Draft              GSS Impersonation               October 2014


6.  IANA Considerations

   [[anchor6: Request addition of the new GSS name attributes and
   Kerberos authorization-data to the relevant registries.]]















































Williams                 Expires April 30, 2015                [Page 15]

Internet-Draft              GSS Impersonation               October 2014


7.  References

7.1.  Normative References

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

   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
              RFC 1964, June 1996.

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

   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
              C-bindings", RFC 2744, January 2000.

   [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.

   [RFC6680]  Williams, N., Johansson, L., Hartman, S., and S.
              Josefsson, "Generic Security Service Application
              Programming Interface (GSS-API) Naming Extensions",
              RFC 6680, August 2012.

   [I-D.williams-kitten-generic-naming-attributes]
              Williams, N., "Generic Naming Attributes for the Generic
              Security Services Application Programming Interface (GSS-
              API)", draft-williams-kitten-generic-naming-attributes-01
              (work in progress), August 2013.

7.2.  Informative References

   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006.

   [S4U]      Unspecified, U., "[MS-SFU]: Kerberos Protocol Extensions:
              Service for User and Constrained Delegation Protocol",
              August 2013.







Williams                 Expires April 30, 2015                [Page 16]

Internet-Draft              GSS Impersonation               October 2014


Appendix A.  Acknowledgements

   This document resulted from Viktor Dukhovni's notes on S4U2Proxy's
   shortcomings and discussions between him and the author as to how
   best to address this.














































Williams                 Expires April 30, 2015                [Page 17]

Internet-Draft              GSS Impersonation               October 2014


Author's Address

   Nicolas Williams
   Cryptonector, LLC

   Email: nico@cryptonector.com













































Williams                 Expires April 30, 2015                [Page 18]