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]
