x

git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14336 ec53bebd-3082-4978-b11e-865c3cabbd6b

doc/standardisation/draft-hartman-gss-naming-01.txt

@@ -0,0 +1,674 @@
+
+
+
+Network Working Group                                         S. Hartman
+Internet-Draft                                                       MIT
+Expires: April 24, 2005                                 October 24, 2004
+
+
+           GSSAPI Mechanisms without a Single Canonical Name
+                    draft-hartman-gss-naming-01.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 April 24, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   The Generic Security Services API (GSSAPI) provides a naming
+   architecture that supports  name-based authorization.  GSSAPI
+   authenticates two named parties to each other.  Names can be stored
+   on access control lists to make authorization decisions.  Advances in
+   security mechanisms and the way implementers wish to use GSSAPI
+   require this model to be extended.  Some mechanisms such as
+   public-key mechanisms do not have a single name to be used.  Other
+   mechanisms such as Kerberos allow names to change as people move
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 1]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+   around organizations.  This document proposes expanding the
+   definition of GSSAPI names to deal with these situations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 2]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+1.  Introduction
+
+   The Generic  Security Services API [1] provides a function called
+   gss_export_name that will flatten a GSSAPI name  into a binary blob
+   suitable for comparisons.  This binary blob can be stored on ACLs and
+   then authorization decisions can be made simply by comparing the name
+   exported from a newly accepted context to the name on the ACL.
+
+   As a side effect of this model, each mechanism name needs to be able
+   to be represented in a single canonical form and anyone importing
+   that name needs to be able to retrieve the canonical form.
+
+   Several security mechanisms have been proposed for which this naming
+   architecture is too restrictive.  In some cases it is not always
+   possible to canonicalize any name that is imported.  In other cases
+   there is no single canonical name.  In addition, there is a desire to
+   have more complex authorization models  in GSSAPI than the current
+   name based authorization model.
+
+   This draft discusses two different cases where the current GSSAPI
+   naming seems inadequate.  Two proposals that have been discussed
+   within the IETF Kitten community are discussed.  Finally, the
+   problems that need to be resolved to adopt either of these proposals
+   are discussed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 3]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+2.  Kerberos Naming
+
+   The Kerberos Referrals draft [2] proposes a new type of Kerberos name
+   called an enterprise name.  The intent is that the enterprise name is
+   an alias that the user knows for themselves and can use to login.
+   The Kerberos KDC translates this name into a normal Kerberos
+   principal and gives the user tickets for this principal.  This normal
+   principal is used for authorization.  The intent is that the
+   enterprise name tracks the user as they move throughout the
+   organization, even if they move to parts of the organization that
+   have different naming policies.  The name they type at login remains
+   constant, but the Kerberos principal used to authenticate them to
+   services changes.
+
+   Performing a mapping from enterprise  name to principal name is not
+   generally possible for unauthenticated services.  So in order to
+   canonicalize an enterprise name to get a principal, a service must
+   have credentials.  However it may not be desirable to allow services
+   to map enterprise names to principal names in the general case.
+   Also, Kerberos does not (and does not plan to) provide a mechanism
+   for mapping enterprise names to principals besides authentication as
+   the enterprise name.  So any such mapping would be vendor-specific.
+   With this feature in Kerberos, it is not possible to implement
+   gss_canonicalize_name for enterprise name types.
+
+   Another issue arises with enterprise names.  IN some cases it would
+   be desirable to put   the enterprise name on the ACL instead of a
+   principal name.  Thus, it would be desirable to include the
+   enterprise name in the name exported by gss_export_name.  However
+   then the exported name would change whenever the mapping changed,
+   defeating the purpose  of including the enterprise name.  So in some
+   cases it would be desirable to have the exported name be based on the
+   enterprise name and in others based on the principal name, but this
+   is not currently possible.
+
+   Another development also complicates GSSAPI naming for Kerberos.
+   Several vendors have been looking at mechanisms to include group
+   membership information in Kerberos authorization data.  It is
+   desirable to put these group names on ACLs.  Again, GSSAPI currently
+   has no mechanism to use this information.
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 4]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+3.  X.509 Names
+
+   X.509 names are at least as complex as Kerberos names.  It seems like
+   you might want to use the subject name as the name to be exported in
+   a GSSAPI mechanism.  However RFC 3280 [3] does not even require the
+   subject name to be a non-empty sequence.  Instead there are cases
+   where the subjectAltName extension is the only thing to identify the
+   subject of the certificate.  As in the case of Kerberos group
+   memberships, there may be many subjectAltName extensions available in
+   a certificate.  Different applications will care about different
+   extensions.  Thus there is no single value that can be  defined as
+   the exported GSSAPI name that will be generally useful.
+
+   A profile of a particular X.509  GSSAPI mechanism could require a
+   specific name be used.  However this would limit that mechanism to
+   require a particular type of certificate.  There is interest in being
+   able to use arbitrary X.509 certificates with GSSAPI for some
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 5]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+4.  Composite Names
+
+   One proposal to solve these problems is to extend the concept of a
+   GSSAPI name to include a set of name attributes.  Each attribute
+   would be an octet-string labeled by an OID.  Examples of attributes
+   would include Kerberos enterprise names, group memberships in an
+   authorization infrastructure, Kerberos authorization data attributes
+   and subjectAltName attributes in a certificate.  Several new
+   operations would be needed:
+   1.  Add attribute to name
+   2.  Query attributes of name
+   3.  Query values of an attribute
+   4.  Delete an attribute from a name
+
+4.1  Usage of Name Attributes
+
+   Since attributes are part of GSSAPI names, the acceptor can retrieve
+   the attributes of the initiator's name from the context.  These
+   attributes can then be used for authorization.
+
+   Most name attributes will probably not come from explicit operations
+   to add attributes to a name.  Instead, name attributes will probably
+   come from mechanism specific credentials.  Mechanism specific naming
+   and group membership can be  mapped into name attributes by the
+   mechanism implementation.  The specific form of this mapping will
+   general require protocol specification for each mechanism.
+
+4.2  Open issues
+
+   This section describes parts of the proposal to add attributes to
+   names that will need to be explored before the proposal can become a
+   protocol specification.
+
+   Are mechanisms expected to be able to carry arbitrary name attributes
+   as part of a context establishment?   At first it seems like this
+   would be desirable.  However the point of GSSAPI is to establish an
+   authenticated context between two peers.  In particular, a context
+   authenticates two named entities to each other.  The names of these
+   entities and attributes associated with these names will be used for
+   authorization decisions.  If an initiator or acceptor is allowed to
+   assert name attributes and the authenticity of these assertions is
+   not validated by the mechanisms, then security problems may result.
+   On the other hand, requiring that name attributes be mechanism
+   specific and only be carried by mechanisms that understand the name
+   attributes and can validate them compromises GSSAPI's place as a
+   generic API.  Application authors would be forced to understand
+   mechanism-specific attributes to make authorization decisions.  In
+   addition if mechanisms are not required to transport arbitrary
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 6]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+   attributes, then application authors will need to deal with different
+   implementations of the same mechanism that support different sets of
+   name attributes.  One possible solution is to carry a source along
+   with each name attribute; this source could indicate whether the
+   attribute comes from a mechanism data structure or from the other
+   party in the authentication.
+
+   Another related question is how will name attributes be mapped into
+   their mechanism-specific forms.  For example it would be desirable to
+   map many  Kerberos authorization data elements into name attributes.
+   In the case of the Microsoft PAC, it would be desirable for some
+   applications to get the entire PAC.  However in many cases, the
+   specific lists of security IDs contained in the PAC would be more
+   directly useful to an application.  So there may not be a good
+   one-to-one mapping between the mechanism-specific elements and the
+   representation desirable at the GSSAPI layer.
+
+   Specific name matching rules need to be developed.  How do names with
+   attributes compare?  What is the effect of a name attribute on a
+   target name in gss_accept_sec_context?
+
+4.3  Handling gss_export_name
+
+   For many mechanisms, there will be  an obvious choice to use for the
+   name exported by gss_export_name.  For example in the case of
+   Kerberos, the principal name can continue to be used as the exported
+   name.  This will allow applications depending on existing GSSAPI
+   name-based authorization to continue to work.  However it is probably
+   desirable to allow GSSAPI mechanisms for which gss_export_name cannot
+   meaningfully be defined.  The behavior of gss_export_name in such
+   cases should probably be to return some error.  Such mechanisms may
+   not work with existing applications and cannot conform to the current
+   version of the GSSAPI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 7]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+5.  Credential Extensions
+
+   An alternative to the name attributes proposal  is to extend GSSAPI
+   credentials  with extensions labeled by OIDs.  Interfaces would be
+   needed to manipulate these credential extensions and to retrieve the
+   credential extensions for credentials used to establish a context.
+   Even if name attributes are used, credential extensions may be useful
+   for other unrelated purposes.
+
+   It is possible to solve problems discussed in this document using
+   some credential extension mechanism.  Doing so will have many of the
+   same open issues as discussed in the  name attributes proposal.  The
+   main advantage of a credential extensions proposal is that  it avoids
+   specifying how name attributes interact with name comparison or
+   target names.
+
+   The primary advantage of the name attributes proposal over credential
+   extensions is that name attributes seem to fit better into the GSSAPI
+   authorization model.  Names are already available at all points when
+   authorization decisions are made.  In addition, for many mechanisms
+   the sort of information carried as name attributes will also be
+   carried as part of the name in the mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 8]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+6.  Mechanisms for Export Name
+
+   Another proposal is to define some GSSAPI mechanisms whose only
+   purpose is to have an exportable name form that is useful.  For
+   example, you might be able to export a name as a local machine user
+   ID with such a mechanism.
+
+   This solution works well especially for name information that can be
+   looked up in a directory.  It was unclear from the discussion whether
+   this solution would allow mechanism-specific name information to be
+   extracted from a context.  If so, then this solution would meet many
+   of the goals of this document.
+
+   One advantage of this solution is that it requires few if any changes
+   to GSSAPI semantics.  It is not as flexible as other solutions.
+   Also, it is not clear how to handle mechanisms that do not have a
+   well defined name to export with this solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 9]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+7.  Security Considerations
+
+   GSSAPI sets up a security context between two named parties.  The
+   GSSAPI names are security assertions that are authenticated by the
+   context establishment process.  As such  the GSS naming architecture
+   is critical to the security of GSSAPI.
+
+   Currently GSSAPI uses a simplistic naming model for authorization.
+   Names can be compared  against a set of names on an access control
+   list.  This architecture is relatively simple and its security
+   properties are well understood.  However it does not provide the
+   flexibility and feature set for future deployments of GSSAPI.
+
+   This proposal will significantly increase the complexity of the GSS
+   naming architecture.  As this proposal is fleshed out, we need to
+   consider ways of managing security exposures created by this
+   increased complexity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 10]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+8.  Acknowledgements
+
+   John Brezak, Paul Leach and Nicolas Williams all participated in
+   discussions that defined the problem this proposal attempts to solve.
+   Nicolas Williams and I discussed details of proposals to solve this
+   problem.  However the details and open issues presented here have
+   only been reviewed by me and so I am responsible for their errors.
+
+9  Informative References
+
+   [1]  Linn, J., "Generic Security Service Application Program
+        Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [2]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
+        KDC Referrals to locate Kerberos realms",
+        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
+        2004.
+
+   [3]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
+        Public Key Infrastructure Certificate and Certificate Revocation
+        List (CRL) Profile", rfc 3280, April 2002.
+
+
+Author's Address
+
+   Sam Hartman
+   MIT
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 11]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+Intellectual Property Statement
+
+   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.
+
+
+Disclaimer of Validity
+
+   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 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 12]
+
+

doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt

@@ -0,0 +1,961 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Obsoletes: 2478 (if approved)                      Microsoft Corporation
+Expires: April 25, 2005                                 October 25, 2004
+
+
+           Generating KDC Referrals to locate Kerberos realms
+                  draft-ietf-krb-wg-kerberos-referrals-05
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 April 25, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   The memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path.  The clients will use this
+   referral information to reach the realm of the target principal and
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 1]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+   then receive the ticket.
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . .   5
+   3.   Requesting a Referral  . . . . . . . . . . . . . . . . . . .   6
+   4.   Realm Organization Model . . . . . . . . . . . . . . . . . .   7
+   5.   Client Name Canonicalization . . . . . . . . . . . . . . . .   8
+   6.   Client Referrals . . . . . . . . . . . . . . . . . . . . . .   9
+   7.   Server Referrals . . . . . . . . . . . . . . . . . . . . . .  10
+   8.   Cross Realm Routing  . . . . . . . . . . . . . . . . . . . .  12
+   9.   Compatibility with Earlier Implementations of Name
+        Canonicalization . . . . . . . . . . . . . . . . . . . . . .  13
+   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  14
+   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  15
+   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
+   12.1   Normative References . . . . . . . . . . . . . . . . . . .  16
+   12.2   Informative References . . . . . . . . . . . . . . . . . .  16
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  16
+        Intellectual Property and Copyright Statements . . . . . . .  17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 2]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [KRBCLR], use principal names constructed from a known
+   user or service name and realm.  A service name is typically
+   constructed from a name of the service and the DNS host name of the
+   computer that is providing the service.  Many existing deployments of
+   Kerberos use a single Kerberos realm where all users and services
+   would be using the same realm.  However in an environment where there
+   are multiple trusted Kerberos realms, the client needs to be able to
+   determine what realm a particular user or service is in before making
+   an AS or TGS request.  Traditionally this requires client
+   configuration to make this possible.
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request.  However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an RFC 822 style email name [RFC822].  This document
+   describes a mechanism that would allow a user to specify a user
+   principal name that is an alias for the user's Kerberos principal
+   name.  In practice this would be the name that the user specifies to
+   obtain a TGT from a Kerberos KDC.  The user principal name no longer
+   has a direct relationship with the Kerberos principal or realm.  Thus
+   the administrator is able to move the user's principal to other
+   realms without the user having to know that it happened.
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm.  To do this requires that the client
+   be able to determine what realm the target service principal is in
+   before making the TGS request.  Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  In order for this to work on the client, each
+   application canonicalizes the host name of the service, for example
+   by doing a DNS lookup followed by a reverse lookup using the returned
+   IP address.  The returned primary host name is then used in the
+   construction of the principal name for the target service.  In order
+   for the correct realm to be added for the target host, the mapping
+   table [domain_to_realm] is consulted for the realm corresponding to
+   the DNS host name.  The corresponding realm is then used to complete
+   the target service principal name.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 3]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+   the environment.
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+   organization (remote server).  The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization.  Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name.  This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name.  You could give that remote server an identity in the local
+   realm and then have that remote server maintain a separate secret for
+   each alias it is known as.  Alternatively you could arrange to have
+   the local realm issue a referral to the remote realm and notify the
+   requesting client of the server's remote name that should be used in
+   order to request a ticket.
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and provide a mechanism for
+   the KDC to determine the trusted realm authentication path by being
+   able to generate referrals to other realms in order to locate
+   principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1.  Client referrals, in which the client doesn't know which realm
+      contains a user account.
+   2.  Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 4]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 5]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+3.  Requesting a Referral
+
+   In order to request referrals defined in section 5, 6, and 7, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [KRBCLR] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+                   -- other KDCOptions values omitted
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [KRBCLR].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 6]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship.  The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm.  This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+                        MS.COM
+                      /        \
+                     /          \
+              OFFICE.MS.COM  NTDEV.MS.COM
+
+   In this configuration, all users in the MS.COM enterprise could have
+   a principal name such as alice@MS.COM, with the same realm portion.
+   In addition, servers at MS.COM should be able to have DNS host names
+   from any DNS domain independent of what Kerberos realm their
+   principals reside in.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 7]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+5.  Client Name Canonicalization
+
+   A client account may have multiple principal names.  More useful,
+   though, is a globally unique name that allows unification of email
+   and security principal names.  For example, all users at MS may have
+   a client principal name of the form "joe@MS.COM" even though the
+   principals are contained in multiple realms.  This global name is
+   again an alias for the true client principal name, which indicates
+   what realm contains the principal.  Thus, accounts "alice" in the
+   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
+   "alice@MS.COM" and "bob@MS.COM".
+
+   This utilizes a new client principal name type, as the AS-REQ message
+   only contains a single realm field, and the realm portion of this
+   name doesn't correspond to any Kerberos realm.  Thus, the entire name
+   "alice@MS.COM" is transmitted as a single component in the client
+   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
+   [KRBCLR].  The KDC will recognize this name type and then transform
+   the requested name into the true principal name.  The true principal
+   name can be using a name type different from the requested name type.
+   Typically the true principal name will be a NT-PRINCIPAL [KRBCLR].
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client principal name and type in the AS response and ticket returned
+   from the name type of the client name in the request.  For example
+   the AS request may specify a client name of "bob@MS.COM" as an
+   NT-ENTERPRISE name with the "canonicalize" KDC option set and the KDC
+   will return with a client name of "104567" as a NT-UID.
+
+   It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out of band mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 8]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+6.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine.  In the case of the name alice@MS.COM, the client
+   MAY optimistically choose to send the request to MS.COM.  The realm
+   in the AS-REQ is always the name of the realm that the request is for
+   as specified in [KRBCLR].
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply structure with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC will try to lookup
+   the entire name, alice@MS.COM, using a name service.  If this lookup
+   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
+   [KRBCLR].  If the lookup is successful, it MUST return an error
+   KDC_ERR_WRONG_REALM [KRBCLR] and in the error message the crealm
+   field will contain either the true realm of the client or another
+   realm that MAY have better information about the client's true realm.
+   The client SHALL NOT use a cname returned from a referral until that
+   name is validated.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message from the first request.  The client SHOULD
+   repeat these steps until it finds the true realm of the client.  To
+   avoid infinite referral loops, an implementation should limit the
+   number of referrals.  A suggested limit is 5 referrals before giving
+   up.
+
+   In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitional direct rusts between them.
+
+   The true principal name of the client, carried via the KRB_ERROR
+   message, can be validated in a subsequent TGS message exchange where
+   its value is communicated back to the KDC via the authenticator in
+   the PA-TGS-REQ padata [KRBCLR].
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 9]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+7.  Server Referrals
+
+   The primary difference in server referrals is that the KDC MUST
+   return a referral TGT rather than an error message as is done in the
+   client referrals.  There needs to be a place to include in the reply
+   information about what realm contains the server.  This is done by
+   returning information about the server name in the pre-authentication
+   data field of the KDC reply [KRBCLR], as specified later in this
+   section.
+
+   If the KDC resolves the server principal name into a principal in the
+   realm specified by the service realm name, it will return a normal
+   ticket.
+
+   If the "canonicalize" flag in the KDC options is not set, the KDC
+   MUST only look up the name as a normal principal name in the
+   specified server realm.  If the "canonicalize" flag in the KDC
+   options is set and the KDC doesn't find the principal locally, the
+   KDC MAY return a cross-realm ticket granting ticket to the next hop
+   on the trust path towards a realm that may be able to resolve the
+   principal name.  The true principal name of the server SHALL be
+   returned in the padata of the reply if it is different from what is
+   specified the request.
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response.  This referral information in
+   pre-authentication data MUST be encrypted using the session key from
+   the reply ticket.  The key usage value for the encryption operation
+   used by PA-SERVER-REFERRAL is 26.
+
+   The pre-authentication data returned by the KDC, which contains the
+   referred realm and the true principal name of server, is encoded in
+   DER as follows.
+
+          PA-SERVER-REFERRAL      25
+
+          PA-SERVER-REFERRAL-DATA ::= EncryptedData
+                                -- ServerReferralData --
+
+          ServerReferralData ::= SEQUENCE {
+                 referred-realm         [0] Realm, OPTIONAL
+                                -- target realm of the referral TGT
+                 true-principal-name    [1] PrincipalName OPTIONAL,
+                                -- true server principal name
+                 ...
+          }
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 10]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+   Clients SHALL NOT accept a reply ticket, whose the server principal
+   name is different from that of the request,  if the KDC response does
+   not contain a PA-SERVER-REFERRAL padata entry.
+
+   The referred-realm field is present if and only if the returned
+   ticket is a referral TGT, not a service ticket for the requested
+   server principal.
+
+   When a referral TGT is returned and the true-principal-name field is
+   present, the client MUST use that name in the subsequent requests to
+   the server realm when following the referral.
+
+   Client SHALL NOT accept a true server principal name for a service
+   ticket if the true-principal-name field is not present in the
+   PA-SERVER-REFERRAL data.
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
+
+          +NC = Canonicalize KDCOption set
+          +PA-REFERRAL = returned PA-SERVER-REFERRAL
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
+          S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
+             containing MS.COM as the referred realm with no
+             true-principal-name
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
+          S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
+             containing NTDEV.MS.COM as the referred realm with no
+             true-principal-name
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
+          S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 11]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+8.  Cross Realm Routing
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain.  As a result, the client need to be aware of the trust
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+   Instead, using the server referral routing mechanism as defined in
+   Section 7, The KDC will determine the best path for the client and
+   return a cross-realm TGT as the referral TGT, and the target realm
+   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
+
+   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
+   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
+   response does not contain the PA-SERVER-REFERRAL padata.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 12]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+9.  Compatibility with Earlier Implementations of Name Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) The TGS referral data is returned inside of the KDC message as
+      "encrypted pre-authentication data".
+
+
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 key-expiration     [3] KerberosTime OPTIONAL,
+                 flags              [4] TicketFlags,
+                 authtime           [5] KerberosTime,
+                 starttime          [6] KerberosTime OPTIONAL,
+                 endtime            [7] KerberosTime,
+                 renew-till         [8] KerberosTime OPTIONAL,
+                 srealm             [9] Realm,
+                 sname             [10] PrincipalName,
+                 caddr             [11] HostAddresses OPTIONAL,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   2) The preauth data type definition in the encrypted preauth data is
+      as follows:
+
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 13]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+10.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 14]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+11.  Acknowledgments
+
+   The authors wish to thank Ken Raeburn for his comments and
+   suggestions.
+
+   Sam Hartman, Ken Raeburn, and authors came up with the idea of using
+   the ticket key to encrypt the referral data, which prevents cut and
+   paste attack using the referral data and referral TGTs.
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 15]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+12.  References
+
+12.1  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [KRBCLR]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 
+              Kerberos Network Authentication Service (V5)", 
+              draft-ietf-krb-wg-kerberos-clarifications. Work in 
+              progress.
+              
+   [RFC822]   Crocker, D., "Standard for the Format of ARPA Internet 
+              Text Messages", RFC 822, August 1982.
+
+12.2  Informative References
+
+   [XPR]      Trostle, J., Kosinovsky, I., and Swift, M., 
+              "Implementation of Crossrealm Referral Handling in the 
+              MIT Kerberos Client", In Network and Distributed System 
+              Security Symposium, February 2001.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 16]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+Intellectual Property Statement
+
+   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.
+
+
+Disclaimer of Validity
+
+   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 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 17]
+
+

doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt

@@ -0,0 +1,249 @@
+
+
+GSSAPI Java CSharp                                             C. Morris
+INTERNET-DRAFT                                               Novell, Inc.
+draft-morris-java-gssapi-update-for-csharp-00.txt     comorris@novell.com
+Expires 10 March 2004                                           July 2004
+
+
+         Generic Security Service API Version 2 : Java & C# Bindings
+
+Status of this Memo
+
+   Comments should be submitted to comorris@novell.com.
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed, or
+   will be disclosed, and any of which I become aware will be disclosed,
+   in accordance with RFC 3668.
+
+   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 a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+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
+   proposes an update to RFC 2853, Generic Security Service API Version 
+   2 : Java Bindings, to include C# bindings.
+
+4.17.  C# Modifications
+
+   This section describes the language dependent modifications necessary
+   to implement the interface in C#. 
+   
+4.17.1   C# Assembly Name
+
+   The C# namespace is org.ietf.gss. See section 4.17.5 for an example.
+   
+4.17.2   C# Class Definitions
+   
+   All class definitions & methods remain the same as specified in the 
+   Java bindings.
+   
+4.17.3   C# Data Types
+
+   All data types remain the same.
+
+4.17.4   C# Exception Handling
+
+   All exception codes remain the same as specified in the Java bindings.
+   However, C# does not have a 'throws' statement. Therefore, method prototypes do
+   not include the exception type. For example,
+   
+   Java method prototype :
+   
+      public abstract GSSName createName(String nameStr, Oid nameType)
+         throws GSSException;
+  
+   Equivalent C# method prototype :
+  
+      public abstract GSSName createName(String nameStr, Oid nameType);
+    
+   C# does implement the throw and catch keywords, for example:
+   
+      public class GSSName createName(String nameStr, Oid nameType)
+      {
+         int majorCode = 0;
+         ...
+         
+         majorCode = validateParms(nameStr, nameType);
+         
+         if (majorCode)
+            throw new GSSException(majorCode);
+            
+         ...
+      }
+
+
+4.17.5   C# Example Code
+
+   Client example : 
+   
+   using ietf.org.gss;
+
+   class GssapiClient
+   {
+      private static TcpClient client;
+      private static NetworkStream stream;
+
+	   static void Main(string[] args)
+	   {
+		   Connect("127.0.0.1", "message from client");
+
+	   try
+	   {
+	      GSSManager manager = GSSManager.getInstance();
+
+	      Oid krb5Mechanism = new Oid("1.2.840.113554.1.2.2");
+	      Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");
+
+	      // Optionally Identify who the client wishes to be
+	      // GSSName name = manager.createName("test@gsserver", GSSName.NT_USER_NAME);
+      	
+	      // Obtain default credential
+	      GSSCredential userCreds = manager.createCredential(GSSCredential.INITIATE_ONLY);
+	      GSSName name = userCreds.getName(krb5PrincipalNameType);
+
+	      Console.WriteLine("Just acquired credentials for " + name.toString());
+
+	      int acceptLife = userCreds.getRemainingAcceptLifetime(new Oid("2.3.4"));
+	      int initLife   = userCreds.getRemainingInitLifetime(new Oid("1..3."));
+	      int remLife    = userCreds.getRemainingLifetime();
+	      int usage      = userCreds.getUsage();
+   	   
+	      GSSName namea = userCreds.getName();
+	      Oid[] oa = userCreds.getMechs();
+
+         // Instantiate and initialize a security context that will be
+         // established with the server
+	      GSSContext context = manager.createContext(name,
+						      krb5Mechanism,
+						      userCreds,
+						      GSSContext.DEFAULT_LIFETIME);
+
+	      userCreds.dispose();
+
+	      // Optionally Set Context Options, must be done before iniSecContext call
+	      context.requestMutualAuth(true);
+	      context.requestConf(true);
+	      context.requestInteg(true);
+	      context.requestSequenceDet(true);
+	      context.requestCredDeleg(true);
+
+	      MemoryStream ins = new MemoryStream();
+	      MemoryStream outs = new MemoryStream();
+
+	      // loop until context is setup and no more tokens to receive
+	      while (!context.isEstablished())
+	      {
+   	      outs = new MemoryStream();
+	         context.initSecContext(ins, outs);
+
+	         // send token if present
+	         if (outs.Length > 0)
+	         {
+		         Console.WriteLine("Sending token...");
+		         sendToken(outs);
+	         }
+
+	         // check if we should expect more tokens
+	         if (context.isEstablished())
+		         break;
+
+	         // another token expected from peer
+	         Console.WriteLine("Still expecting another token from server...");
+	         ins = recvToken();
+	      }
+
+	      //
+	      // display context information
+	      //
+
+	      // Did the server authenticate back to client?
+	      Console.WriteLine("\n{0} Mutual Authentication", 
+	      context.getMutualAuthState() ? "Using" : "Not using");
+	      Console.WriteLine("Credentials were delegated = " 
+   	      + context.getCredDelegState());
+	      Console.WriteLine("Remaining lifetime in seconds = " 
+	         + context.getLifetime());
+	      Console.WriteLine("Context mechanism = " + context.getMech());
+	      Console.WriteLine("Initiator = " + context.getSrcName().toString());
+	      Console.WriteLine("Acceptor = " + context.getTargName().toString());
+	      Console.WriteLine("Confidentiality (i.e., privacy) is {0}available", 
+	      context.getConfState() ? "" : "not ");
+	      Console.WriteLine("Integrity is {0}available", 
+	      context.getIntegState() ? "" : "not ");
+	      Console.WriteLine("Is initiator = " + context.isInitiator());
+	      Console.WriteLine("Is transferable = " + context.isTransferable());
+	      Console.WriteLine("Is protReady = " + context.isProtReady());
+	      Console.WriteLine("ReplayDetState = " + 
+	      context.getReplayDetState());
+	      Console.WriteLine("SequenceDetState = " + 
+	      context.getSequenceDetState());
+
+	      // perform wrap on an application supplied message
+	      // using QOP = 0, and requesting privacy service
+
+	      MessageProp msgProp = new MessageProp(0, true);
+	      byte [] message = System.Text.Encoding.ASCII.GetBytes("Hello GSS-API!");
+	      byte [] token = System.Text.Encoding.ASCII.GetBytes("tok");
+
+	      // Byte aray method is equivalent to stream method
+	      //byte []token = context.wrap(message, 0, appMsg.length, msgProp);
+	      //sendToken(token);
+
+	      ins = new MemoryStream();
+	      outs = new MemoryStream();
+	      ins.Write(token, 0, token.Length);
+	      context.getMIC(ins, outs, msgProp);
+	      sendToken(outs);
+
+	      outs = new MemoryStream();
+	      outs.Write(message, 0, message.Length);
+	      sendToken(outs);
+
+	      ins = new MemoryStream();
+	      outs = new MemoryStream();
+	      ins.Write(message, 0, message.Length);
+	      context.wrap(ins, outs, msgProp);
+	      sendToken(outs);
+
+         // Optionally export context to another thead
+	      GSSContext ctx = manager.createContext(context.export());
+	      Console.WriteLine("New context isTransferable = " + ctx.isTransferable());
+	      Console.WriteLine("New context isInitiator = " +ctx.isInitiator());
+	      Console.WriteLine("New context protReady = " +ctx.isProtReady());
+	      Console.WriteLine("New context srcName = " +ctx.getSrcName().toString());
+	      Console.WriteLine("New context targName = " +ctx.getTargName().toString());
+
+	      // release the local-end of the context
+	      ctx.dispose();
+
+	      stream.Close();
+	      Console.WriteLine("Leaving...");
+	   }
+	   catch (GSSException e)
+	   {
+	      Console.WriteLine(e.getMessage());
+	      Console.WriteLine(e.StackTrace);
+	   }
+	}
+
+
+Expires 10 March 2004                                 
+
+

doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt

@@ -0,0 +1,557 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+
+            GSS-API Domain-Based Service Names and Name Type
+            draft-williams-gssapi-domain-based-names-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document describes domainname-based service principal names and
+   the corresponding name type for the GSS-API.
+
+
+   Domain-based service names are similar to host-based service names,
+   but using a domain name (not necessarily and Internat domain name)
+   instead of or in addition to a hostname.  The primary purpose of
+   domain-based service names is to provide a way to name clustered
+   services after the domain which they service, thereby allowing their
+   clients to authorize the service's servers based on authentication of
+   their names.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+Table of Contents
+
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   3. Name Type OID and Symbolic Name  . . . . . . . . . . . . . . . . 5
+   4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . . 6
+   5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 8
+   7. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
+      Intellectual Property and Copyright Statements . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+1.  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 December 30, 2004                [Page 3]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+2.  Introduction
+
+
+   The use of hostbased principal names for domain-wide services
+   presents the problem of how to distinguish between an instance of a
+   hostbased service that is authorized to respond for a domain and one
+   that isn't.
+
+
+   Consider LDAP.  LDAP with SASL and the Kerberos V GSS-API mechanism
+   uses a hostbased principal with a service name of "ldap", a
+   reasonable approach, provided there is only one logical LDAP
+   directory in a Kerberos realm's domain, and that all ldap servers in
+   that realm serve that one LDAP directory.  If there were other LDAP
+   directories, then clients could not tell which service is authorized
+   to serve which directory, not without assuming a secure method for
+   finding LDAP servers (e.g., DNSSEC).  This is a significant, and
+   oft-unstated restriction on users of LDAP.
+
+
+   Domain based names can eliminate this problem by allowing LDAP
+   service names to indicate which LDAP directory they are authorized to
+   serve.
+
+
+   A domain-based name consists of three required elements:
+   o  a service name
+   o  a domain name
+   o  a hostname
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+3.  Name Type OID and Symbolic Name
+
+
+   The new name type has an OID of
+      [NOTE:  OID assignment to be made with IANA.]
+
+
+      {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6)
+      gss-domain-based(5)}
+
+
+   The recommended symbolic name for this GSS-API name type is
+   "GSS_C_NT_DOMAINBASED_SERVICE".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+4.  Query and Display Syntaxes
+
+
+   There is a single syntax that applies to both query and display forms
+   of domain-based names.  (We ignore string profile matters here as the
+   GSS-API's, and its mechanisms' use of character strings are out of
+   scope for this document.)
+
+
+   The syntax is:
+      domain-based-name :=
+         | <service> '@' <domain> '@' <hostname>
+         | <service> '@@' <hostname>
+
+
+   The domain name element is only optional in the query syntax of
+   domain-based names.
+
+
+   A missing domain name is always to be added by the GSS-API mechanisms
+   during name canonicalization, using whatever default values are
+   appropriate for the mechanisms.
+
+
+   Therefore the display form of domain-based MNs (see [RFC2743]) MUST
+   include all three elements of domain-based names.
+
+
+   Note that for Internet domain names the trailing '.' is not and MUST
+   NOT be included in the domain name (or hostname) parts of the display
+   form GSS-API domain-based MNs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+5.  Examples
+
+
+   o  ldap@@ds1.example.tld
+   o  ldap@example.tld@ds1.example.tld
+
+
+   o  kadmin@@kdc1.example.tld
+   o  kadmin@example.tld@kdc1.example.tld
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+6.  Security Considerations
+
+
+   Use of GSS-API domain-based names may not be negotiable by some
+   GSS-API mechanisms, and some acceptors may not support GSS-API
+   domain-based names.  In such cases initiators are left to fallback on
+   the use of hostbased names, in which case the initiators MUST also
+   verify that the acceptor's hostbased name is authorized to provide
+   the given service for the domain that the initiator had wanted.
+
+
+   The above security consideration also applies to all GSS-API
+   initiators who lack support for domain-based service names.
+
+
+7  Normative
+
+
+   [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.
+
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+Author's Address
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+Intellectual Property Statement
+
+
+   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.
+
+
+
+Disclaimer of Validity
+
+
+   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 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  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.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9] 

doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt

@@ -0,0 +1,617 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+     Namespace Considerations and Registries for GSS-API Extensions
+              draft-williams-gssapi-extensions-iana-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document describes the ways in which the GSS-API may be extended
+   and directs the creation of IANA registries for GSS-API namespaces
+   that may be affected by any extensions.
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+Table of Contents
+
+   1. Conventions used in this document  . . . . . . . . . . . . . .   3
+   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3. Extensions to the GSS-API  . . . . . . . . . . . . . . . . . .   5
+   4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . .   6
+   5. Language Binding-Specific GSS-API Namespaces . . . . . . . . .   7
+   6. Extension-Specific GSS-API Namespaces  . . . . . . . . . . . .   8
+   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .   9
+   8. Security Considerations  . . . . . . . . . . . . . . . . . . .  10
+   9. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  10
+      Intellectual Property and Copyright Statements . . . . . . . .  11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+1.  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 December 30, 2004                [Page 3]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+2.  Introduction
+
+   There is a need for generic and mechanism-specific extensions to the
+   Generic Security Services Application Programming Interface
+   (GSS-API).  As such extensions are designed and standardized, both at
+   the IETF and elsewhere, there is a non-trivial risk of namespace
+   pollution and conflicts.  To avoid this we set out guidelines for
+   extending the GSS-API and create IANA registries of GSS-API
+   namespaces.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+3.  Extensions to the GSS-API
+
+   Extensions to the GSS-API can be categorized as follows:
+   o  Generic
+   o  Implementation-specific
+   o  Mechanism-specific
+   o  Language binding-specific
+   o  Any combination of two or all three of the last three
+
+   Extensions to the GSS-API may be purely semantic, without effect on
+   the GSS-API's namespaces.  Or they may introduce new functions,
+   constants, types, etc...; these clearly affect the GSS-API
+   namespaces.
+
+   Extensions that affect the GSS-API namespaces should be registered
+   with the IANA< along with their specific effects on the GSS-API
+   namespaces.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+4.  Generic GSS-API Namespaces
+
+   All the function, constant and type names, as well as all the
+   constant values specified in the base GSS-API specification for the
+   basic generic GSS-API namespace.
+
+   The generic GSS-API namespaces are:
+   o  Type names
+   o  Function names
+   o  Constant names for each type
+   o  Constant values for each type
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+5.  Language Binding-Specific GSS-API Namespaces
+
+   <Add text; discuss header, module, library, class namespaces and
+   whatever else comes up that is language-specific and appropriate for
+   registration with the IANA.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+6.  Extension-Specific GSS-API Namespaces
+
+   Extensions to the GSS-API may create additional namespaces.  IANA
+   registries SHOULD be created for any such new namespaces.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+7.  IANA Considerations
+
+   The following registries should be established upon publication of
+   this document as an RFC:
+   o  GSS-API Type Name Registry
+   o  GSS-API Function Name Registry
+   o  GSS-API Constant Name Registry
+   o  GSS-API Constant Value Registry
+   o  GSS-API Class/Header/Library/Module Name Registry
+
+   Entries in these registries should consist of:
+   o  Namespace name
+   o  Symbol name or prefix, OR value or value range.
+   o  [optional] Reference to normative reference for the registration.
+   o  [optional] Programming language
+   o  [optional] Entry sub-type (e.g., "header name")
+   o  [optional] Mechanism OID(s) and/or OID prefix(es) associated with
+      the entry
+   o  [optional] Magic
+   o  [optional] Expert Review (body or people who reviewed the
+      registration)
+   o  [optional] Description (in English)
+
+   <Add text on guidelines for IANA consideration of registration
+   applications, particularly with respect to entries w/o normative
+   references, "magic" entries (e.g., special values of 'time' types
+   which indicate something other than absolute or relative time, such
+   as GSS_C_INDEFINITE), expert review requirements for registrations w/
+   o normative references, etc....>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+8.  Security Considerations
+
+   This document has no security considerations.
+
+9  Normative
+
+   [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.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 10]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+Intellectual Property Statement
+
+   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.
+
+
+Disclaimer of Validity
+
+   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 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004               [Page 11]
+
+

doc/standardisation/draft-williams-gssapi-prf-00.txt

@@ -0,0 +1,498 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                    S. Hartman
+                                                                     MIT
+                                                               July 2004
+
+
+
+                  A PRF API extension for the GSS-API
+                    draft-williams-gssapi-prf-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document defines a Pseudo-Random Function (PRF) extension to the
+   GSS-API for keying application protocols given an established GSS-API
+   security context.
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 1]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+Table of Contents
+
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  5
+   3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   5.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  6
+       Intellectual Property and Copyright Statements . . . . . . . .  8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 2]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+1.  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 & Hartman     Expires December 30, 2004                [Page 3]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+2.  Introduction
+
+
+   A need has arisen for users of the GSS-API to key applications'
+   cryptographic protocols using established GSS-API security contexts.
+   Such applications can use the GSS-API for authentication, but not for
+   transport security (for whatever reasons), and since the GSS-API does
+   not provide a method for obtaining keying material from established
+   security contexts such applications cannot make effective use of the
+   GSS-API.
+
+
+   To address this need we define a PRF extension to the GSS-API.
+
+
+   At this point EAP may be the primary consumer of this extension.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 4]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+3.  GSS_Pseudo_random()
+
+
+   Inputs:
+
+
+   o  context CONTEXT handle,
+   o  prf_in OCTET STRING
+
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  prf_out OCTET STRING
+
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
+      as input.
+   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
+      provided as input.
+   o  GSS_S_FAILURE indicates failure or lack of support; the minor
+      status code may provide additional information.
+
+
+   This function applies the context's mechanism's keyed PRF function to
+   the input data (prf_in), keyed with key material associated with the
+   given security context and outputs the result (prf_out).
+
+
+3.1  C-Bindings
+
+
+   OM_uint32 gss_pseudo_random(
+     OM_uint32                  *minor_status,
+     gss_ctx_id_t                       context,
+     const gss_buffer_t         prf_in,
+     gss_buffer_t            prf_out
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 5]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+4.  Security Considerations
+
+
+   GSS mechanisms' PRF functions should use a key derived from contexts'
+   session keys and should preserve the forward security properties of
+   the mechanisms' key exchanges.
+
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.  Cryptographic hash functions which do not provide strong
+   collision resistance should not be used, except through HMAC.
+
+
+   GSS mechanisms' PRF functions may output fewer octets than the
+   application may need, therefore GSS-API applications that use
+   GSS_Pseudo_random() may require a "PRF+" construction based on
+   GSS_Pseudo_random().
+
+
+   [Question:  Should GSS_Pseudo_random() have an input roughly
+   corresponding to the "key usage" used for key derivation in Kerberos
+   V?]
+
+
+5  Normative
+
+
+   [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.
+
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+Authors' Addresses
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+   Sam Hartman
+   Massachussets Institute of Technology
+   ...
+   ..., MA  ...
+   US
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 6]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 7]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+Intellectual Property Statement
+
+
+   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.
+
+
+
+Disclaimer of Validity
+
+
+   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 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  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.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 8] 

doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt

@@ -0,0 +1,466 @@
+
+INTERNET-DRAFT                                          Nicolas Williams
+                                                        Sun Microsystems
+                                                          September 2003
+
+
+
+           GSS-APIv2 Extension for Storing Delegated Credentials
+             <draft-williams-gssapi-store-deleg-creds-01.txt>
+
+
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [RFC2026].
+
+   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 draft expires on January 30th, 2004. Please send comments to
+   the authors.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines a new function for the GSS-API which allows
+   applications to store delegated (and other) credentials in the
+   implicit GSS-API credential store.  This is needed for GSS-API
+   applications to use delegated credentials as they would use other
+   credentials.
+
+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].
+
+N. Williams							[Page 1]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+
+Table of Contents
+
+   1  Introduction
+   2  GSS_Store_cred()
+   2.1  C-Bindings for GSS_Store_cred()
+   3  Examples
+   4  Security Considerations
+   5  References
+   5.1  Normative References
+   6  Author's Address
+
+1  Introduction
+
+   The GSS-API [RFC2743] clearly assumes that credentials exist in an
+   implicit store whence they can be acquired using GSS_Acquire_cred()
+   and GSS_Add_cred() or through use of the default credential.
+   Multiple credential stores may exist on a given host, but only one
+   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
+   given time.
+
+   [NOTE:  This assumption can be seen in sections 1.1.1.2 and 1.1.1.3
+           of RFC2743 as well as in section 3.5 of RFC2744.
+
+	   Note to the RFC editor: please remove this note before
+	   publication.]
+
+   Applications may be able to change the credential store from which
+   credentials can be acquired, either by changing user contexts (where
+   the applications have the privilege to do so) or by other means
+   (where a user may have multiple credential stores).
+
+   Some GSS-API acceptor applications always change user contexts, after
+   accepting a GSS-API security context and making appropriate
+   authorization checks, to the user context corresponding to the
+   initiator principal name or to a context requested by the initiator.
+   The means by which credential stores are managed are generally beyond
+   the scope of the GSS-API.
+
+   In the case of delegated credential handles however, such credentials
+   do not exist in the acceptor's credential store or in the credential
+   stores of the user contexts to which the acceptor application might
+   change - which is precisely the raison d'etre of credential
+   delegation.  But the GSS-API provides no mechanism by which delegated
+   credential handles can be made available for acquisition through
+   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
+   any credential import/export interfaces like the GSS-API context
+   import/export interfaces.
+
+   Thus acceptors are limited to making only direct use of delegated
+   credential handles and only with GSS_Init_sec_context(),
+   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
+   particularly onerous on Unix systems where a call to exec() to
+
+N. Williams							[Page 2]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+   replace the process image obliterates the delegated credentials
+   handle.  
+
+   [NOTE:  Delegated credentials are practically unusable on Unix
+	   implementations of Secure Shell (SSHv2) servers, except where
+	   there are extended interfaces for dealing with delegated
+	   credentials, which to date have always been
+	   mechanism-specific interfaces.
+
+	   Note to the RFC editor: please remove this note before
+	   publication.]
+
+   In order to make delegated credentials generally as useful as
+   credentials that can be acquired with GSS_Acquire_cred() and
+   GSS_Add_cred() a primitive is needed which allows storing of
+   credentials in the implicit credential store.  This primitive we call
+   "GSS_Store_cred()."
+
+   [NOTE:  Simon Wilkinson's patches to OpenSSH for GSS-API sport a
+           simple internal interface for storing delegated credentials
+	   in users' credential store - this internal interface wraps
+	   around two mechanism specific internal interfaces for storing
+	   GSI and Kerberos V credentials.
+
+	   Simon's code shows that:
+
+	   a) a generic method is needed for making delegated
+	      credentials available for indirect use through acquisition
+	      (as opposed to just using the actual delegated cred
+	      handle)
+
+           b) it is possible to design and implement such a generic
+	      method for storing delegated credentials.
+
+	   No new concepts are added to the GSS-API by this document,
+	   but the implicit existence of a credential store in the
+	   background is made explicit, and a deficiency of the GSS-API
+	   is corrected.
+
+	   Compare this to the GGF proposal which includes a credential
+	   import/export facility (like the existing context import/
+	   export facility), but with an option to export as
+	   "environment variables," meaning something like "store these
+	   input creds in some new credential store and then tell me the
+	   name of that credential store through some output environment
+	   variable"[*].  Thus, the GGF export-cred-to-environment-
+	   variable proposal adds knowledge of environment variables to
+	   the GSS-API, which this proposal does not.  Note that a
+	   credential import/export facility along the lines of the
+	   existing context import/export facility may be useful and
+	   complements the GSS_Store_cred() interface; in fact, with
+	   GSS_Store_cred() it should be possible to remove the
+	   'option_req' input parameter and export-to-env-var features
+
+N. Williams							[Page 3]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+	   of the GGF's GSS_Export_cred() credential export proposal.
+
+	   [*]  For the exact semantics see section 1.2, paragraph 6 of
+	        draft-engert-ggf-gss-extensions-00.txt
+
+	   One side effect of GSS_Store_cred(), however, is that it
+	   allows applications that can switch their current credential
+	   store to move credentials from one store to the other; this
+	   is a direct result of making it possible to store a
+	   credential given a GSS-API credential handle.  Perhaps there
+	   should be some text allowing, or recommending, that
+	   implementations of GSS_Store_cred() allow only the storage of
+	   credentials acquired through credential delegation.
+
+	   Note to the RFC editor: please remove this note before
+	   publication.]
+
+2  GSS_Store_cred()
+
+   Inputs:
+
+   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
+   -- NOT be GSS_C_NO_CREDENTIAL
+
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+   -- 2=ACCEPT-ONLY
+
+   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID
+   -- then store all the elements of the input_cred_handle, otherwise
+   -- store only the element of the corresponding mechanism
+
+   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
+   -- same principal in the credential store
+
+   o  default_cred BOOLEAN -- if TRUE make the stored credential
+   -- available as the default credential (for acquisition with
+   -- GSS_C_NO_NAME as the desired name or for use as
+   -- GSS_C_NO_CREDENTIAL)
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
+   -- mechanism OIDs for which credential elements were successfully
+   -- stored
+
+   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
+   -- kind of credential was stored (useful when the cred_usage input
+   -- parameter is set to INITIATE-AND-ACCEPT)
+
+
+N. Williams							[Page 4]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials were successfully
+   stored.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials
+   had expired or expired before they could be stored.
+
+   o  GSS_S_NO_CRED indicates that no input credentials were given.
+
+   o  GSS_S_UNAVAILABLE indicates that the credential store is not
+   available.
+
+   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
+   credential could not be stored because a credential for the same
+   principal exists in the current credential store and the
+   overwrite_cred input argument was FALSE.
+
+   o  GSS_S_FAILURE indicates that the credential could not be stored
+   for some other reason.  The minor status code may provide more
+   information if a non-GSS_C_NULL_OID desired_mech_element was given.
+
+   GSS_Store_cred() is used to store, in the current credential store, a
+   given credential that has either been acquired from a different
+   credential store or been accepted as a delegated credential.
+
+   Specific mechanism elements of a credential can be stored one at a
+   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
+   desired_mech_element input argument, in which case the minor status
+   output SHOULD have a mechanism-specific value when the major status
+   is not GSS_S_COMPLETE.
+
+   The initiator, acceptor or both usages of the input credential may be
+   stored as per the cred_usage input argument.
+
+   The credential elements that were actually stored, when the major
+   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
+   and mech_elements_stored function outputs.
+
+   If credentials already exist in the current store for the principal
+   of the input_cred_handle, then those credentials are not replaced
+   with the input credentials unless the overwrite_cred input argument
+   is TRUE.
+
+   Finally, if the current credential store has no default credential
+   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
+   if the default_cred input argument is TRUE, and the input credential
+   can be successfully stored, then the input credential will be
+   available for acquisition with GSS_C_NO_NAME as the desired name
+   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
+   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
+   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
+   GSS_Accept_sec_context().
+
+N. Williams							[Page 5]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+
+2.1  C-Bindings for GSS_Store_cred()
+
+   The C-bindings for GSS_Store_cred() make use of types from and are
+   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
+
+   OM_uint32 gss_store_cred(
+      OM_uint32         *minor_status,
+      gss_cred_id_t     input_cred,
+      gss_cred_usage_t  cred_usage,
+      const gss_OID     desired_mech,
+      OM_uint32         overwrite_cred,
+      OM_uint32         default_cred,
+      gss_OID_set       *elements_stored,
+      gss_cred_usage_t  *cred_usage_stored)
+
+   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
+   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
+   correspond to TRUE.
+
+3  Examples
+
+   The intended usage of GSS_Store_cred() is to make delegated
+   credentials available to child processes of GSS-API acceptor
+   applications.  Example pseudo-code:
+
+   /*
+    * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE, an
+    * initiator name (hereafter, "src_name") and a delegated credential
+    * handle (hereafter "deleg_cred").>
+    *
+    * <"requested_username" is a username derived from the initiator
+    * name or explicitly requested by the initiator application.>
+    */
+   ...
+
+   if (authorize_gss_client(src_name, requested_username)) {
+      /*
+       * For Unix-type platforms this may mean calling setuid() and it
+       * may or may not also mean setting/unsetting such environment
+       * variables as KRB5CCNAME and what not.
+       */
+      if (change_user_context(requested_username))
+         (void) gss_store_creds(&minor_status, deleg_cred,
+				GSS_C_INITIATE, actual_mech,
+				0, 1, NULL, NULL);
+      }
+      else ...
+   }
+   else ...
+
+4  Security Considerations
+
+
+N. Williams							[Page 6]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+   Acceptor applications MUST only store delegated credentials into
+   appropriate credential stores and only after proper authorization of
+   the authenticated initiator principal to the requested service(s).
+
+   Acceptor applications that have no use for delegated credentials MUST
+   release them (such acceptor applications that use the GSS-API
+   C-Bindings may simply provide a NULL value for the
+   delegated_cred_handle argument to gss_accept_sec_context()).
+
+5  References
+
+5.1  Normative References
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [RFC2119]
+      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
+      Indicate Requirement Levels," March 1997, Status: Best Current
+      Practice.
+
+   [RFC2743]
+      J. Linn, RFC2743: "Generic Security Service Application Program
+      Interface Version 2, Update 1," January 2000, Status: Proposed
+      Standard.
+
+   [RFC2744]
+      J. Wray, RFC2744: "Generic Security Service API Version 2 :
+      C-bindings," January 2000, Status: Proposed Standard.
+
+6  Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX 78727
+   Email: Nicolas.Williams@sun.com
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+
+N. Williams							[Page 7]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+N. Williams							[Page 8]

doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt

@@ -0,0 +1,432 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+
+   GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS
+                               Mechanism
+          draft-williams-krb5-gssapi-domain-based-names-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document describes the mapping of GSS-API domainname-based
+   service principal names onto Kerberos V principal names.
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+Table of Contents
+
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Domain-Based Names for the Kerberos V GSS-API Mechanism  . . . . 4
+   3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+   4. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
+   5. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
+      Intellectual Property and Copyright Statements . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+1.  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 December 30, 2004                [Page 3]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+2.  Domain-Based Names for the Kerberos V GSS-API Mechanism
+
+
+   In accordance with [DOMAIN-BASED-NAMES] this document provides the
+   mechanism-specific details needed to implement GSS-API [RFC2743]
+   domain-based service names with the Kerberos V GSS-API mechanism
+   [RFC1964].
+
+
+   GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal
+   names as follows:
+   o  the <service> name becomes the first (0th) component of the
+      Kerberos V principal name;
+   o  the <domain> name becomes the second component of the Kerberos V
+      principal name; if the <domain> name is missing in the GSS name
+      then a default domain name MUST be substituted (though no
+      mechanism for determining this default is given here; this is an
+      implementation-specific detail);
+   o  the <hostname>, if present, becomes the third component of the
+      Kerberos V principal name;
+   o  the realm of the resulting principal name is that which
+      corresponds to the domain name, treated as a hostname, or, if none
+      can be determined in this way, then the realm of the hostname, if
+      present, and, finally, if that is not possible, the default realm
+      for the GSS-API caller.
+
+
+   The same name canonicalization considerations and methods as used
+   elsewhere in the Kerberos V GSS-API mechanism [RFC1964] and Kerberos
+   V [RFC1510] in general apply here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+3.  Examples
+
+
+   o  "ldap@@ds1.example.tld" may map to "ldap/example.tld/
+      ds1.example.tld@EXAMPLE.TLD"
+   o  "ldap@example.tld@ds1.example.tld" may map to "ldap/example.tld/
+      ds1.example.tld@EXAMPLE.TLD"
+
+
+   o  "kadmin@@kdc1.example.tld" may map to "kadmin/example.tld/
+      kdc1.example.tld@EXAMPLE.TLD"
+   o  "kadmin@example.tld@kdc1.example.tld" may map to "kadmin/
+      example.tld/kdc1.example.tld@EXAMPLE.TLD"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+4.  Security Considerations
+
+
+   See [DOMAIN-BASED-NAMES].
+
+
+5  Normative
+
+
+   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
+              Authentication Service (V5)", RFC 1510, September 1993.
+
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+              1964, June 1996.
+
+
+   [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.
+
+
+
+Author's Address
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+Intellectual Property Statement
+
+
+   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.
+
+
+
+Disclaimer of Validity
+
+
+   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 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  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.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7] 

doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt

@@ -0,0 +1,373 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                    S. Hartman
+                                                                     MIT
+                                                               July 2004
+
+
+
+               A PRF for the Kerberos V GSS-API Mechanism
+                 draft-williams-krb5-gssapi-prf-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document defines the Pseudo-Random Function (PRF) for the
+   Kerberos V GSS-API mechanism, based on the PRF defined for the
+   Kerberos V cryptographic framework, for keying application protocols
+   given an established Kerberos V GSS-API security context.
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 1]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+Table of Contents
+
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
+   4. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
+      Intellectual Property and Copyright Statements . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 2]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+1.  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 & Hartman     Expires December 30, 2004                [Page 3]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+2.  Introduction
+
+
+   The GSS-API PRF function for the Kerberos V mechanism shall be the
+   output of the enctype's PRF function keyed with the negotiated
+   session key of the security context (e.g., the acceptor's subkey) and
+   key usage X (TBD).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 4]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+3.  Security Considerations
+
+
+   Kerberos V enctypes' PRF functions should use a key derived from
+   contexts' session keys and should preserve the forward security
+   properties of the mechanisms' key exchanges.
+
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.  Cryptographic hash functions which do not provide strong
+   collision resistance should not be used, except through HMAC.
+
+
+4  Normative
+
+
+   [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.
+
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+Authors' Addresses
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+   Sam Hartman
+   Massachussets Institute of Technology
+   ...
+   ..., MA  ...
+   US
+
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 5]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+Intellectual Property Statement
+
+
+   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.
+
+
+
+Disclaimer of Validity
+
+
+   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 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  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.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 6]