Skip to main content

A Simple Anonymous GSS-API Mechanism
draft-howard-gss-sanon-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Luke Howard
Last updated 2020-04-10 (Latest revision 2020-04-09)
Replaced by draft-ietf-kitten-gss-sanon
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-howard-gss-sanon-06
Network Working Group                                          L. Howard
Internet-Draft                                                      PADL
Intended status: Informational                            April 11, 2020
Expires: October 13, 2020

                  A Simple Anonymous GSS-API Mechanism
                       draft-howard-gss-sanon-06

Abstract

   This document defines protocols, procedures and conventions for a
   Generic Security Service Application Program Interface (GSS-API)
   security mechanism that provides key agreement without authentication
   of either party.

Status of This Memo

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

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

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

   This Internet-Draft will expire on October 13, 2020.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Howard                  Expires October 13, 2020                [Page 1]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1.  Authentication  . . . . . . . . . . . . . . . . . . . . . .   3
   1.2.  Application Services  . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements notation . . . . . . . . . . . . . . . . . . . .   3
   3.  Discovery and Negotiation . . . . . . . . . . . . . . . . . .   3
   4.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.1.  Name Types  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.1.1.  GSS_C_NT_USER_NAME  . . . . . . . . . . . . . . . . . . .   4
   4.1.2.  GSS_C_NT_HOSTBASED_SERVICE  . . . . . . . . . . . . . . .   4
   4.1.3.  GSS_C_NT_DOMAINBASED_SERVICE  . . . . . . . . . . . . . .   4
   4.1.4.  GSS_C_NT_ANONYMOUS  . . . . . . . . . . . . . . . . . . .   4
   4.2.  Canonicalization  . . . . . . . . . . . . . . . . . . . . .   5
   4.3.  Mechanism Selection Hints . . . . . . . . . . . . . . . . .   5
   5.  Definitions and Token Formats . . . . . . . . . . . . . . . .   5
   5.1.  Context Establishment Tokens  . . . . . . . . . . . . . . .   5
   5.1.1.  Initial context token . . . . . . . . . . . . . . . . . .   5
   5.1.2.  Acceptor context token  . . . . . . . . . . . . . . . . .   6
   5.1.3.  Initiator context completion  . . . . . . . . . . . . . .   6
   5.2.  Per-Message Tokens  . . . . . . . . . . . . . . . . . . . .   7
   5.3.  Context Deletion Tokens . . . . . . . . . . . . . . . . . .   7
   5.4.  Exported Name Tokens  . . . . . . . . . . . . . . . . . . .   7
   6.  Key derivation  . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Pseudo-Random Function  . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   10.1.  Normative References . . . . . . . . . . . . . . . . . . .   8
   10.2.  Informative References . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Mechanism Attributes . . . . . . . . . . . . . . . .  10
   Appendix C.  NegoEx . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The Generic Security Service Application Program Interface (GSS-API)
   [RFC2743] provides a framework for authentication and message
   protection services through a common programming interface.

   The Simple Anonymous mechanism described in this document (hereafter
   SAnon) is a simple protocol based on the X25519 elliptic curve
   Diffie-Hellman (ECDH) key agreement scheme defined in [RFC7748].  No
   authentication of initiator or acceptor is provided.  A potential use
   of SAnon is to provide a degree of privacy when bootstrapping unkeyed
   entities.

Howard                  Expires October 13, 2020                [Page 2]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

1.1.  Authentication

   The GSS-API protocol involves a client, known as the initiator,
   sending an initial security context token of a chosen GSS-API
   security mechanism to a peer, known as the acceptor.  The two peers
   subsequently exchange, synchronously, as many security context tokens
   as necessary to complete the authentication or fail.  The specific
   number of context tokens exchanged varies by security mechanism: in
   the case of the SAnon mechanism, it is two (i.e. a single round
   trip).  Once authentication is complete, the initiator and acceptor
   share a security context which can be used for integrity or
   confidentiality, protecting subsequent application messages.

1.2.  Application Services

   GSS-API provides a number of a services to the calling application:

   GSS_Wrap()  integrity and optional confidentiality for a message

   GSS_GetMIC()  integrity for a message sent separately

   GSS_Pseudo_random()  shared key derivation (e.g., for keying external
      confidentiality and integrity layers)

   These services are used with security contexts that have a shared
   session key to protect application-layer messages.

2.  Requirements notation

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

3.  Discovery and Negotiation

   The SAnon mechanism is identified by the following OID:

       sanon-x25519 OBJECT IDENTIFIER ::=
           {iso(1)identified-organization(3)dod(6)internet(1)
            private(4)enterprise(1)padl(5322)gss-sanon(26)
            mechanisms(1)sanon-x25519(110)}

   The means of discovering GSS-API peers and their supported mechanisms
   is out of this specification's scope.  To avoid multiple layers of
   negotiation, SAnon is not crypto-agile.  A future variant using a
   different key exchange algorithm would be assigned a different OID.

Howard                  Expires October 13, 2020                [Page 3]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

   If anonymity is not desired then SAnon MUST NOT be used.  Either
   party can test for the presence of GSS_C_ANON_FLAG to check if
   anonymous authentication was performed.

4.  Naming

   The GSS-API provides a rich security principal naming model.  At its
   most basic the query forms of names consist of a user-entered/
   displayable string and a name type.  Name types are constants with
   names prefixed with "GSS_C_NT_" in the GSS-API.

4.1.  Name Types

4.1.1.  GSS_C_NT_USER_NAME

   This name type is supported by SAnon when the input name string is
   the well known anonymous name string, WELLKNOWN/
   ANONYMOUS@WELLKNOWN:ANONYMOUS.  In all other cases, importing the
   name MUST fail.

4.1.2.  GSS_C_NT_HOSTBASED_SERVICE

   This name type identifies a host-based service and is generally used
   by acceptors.  SAnon does not authenticate the acceptor to the
   initiator: when importing a name of this type, the name string SHOULD
   be ignored.  This allows existing applications that assert an
   acceptor identity but do not require mutual authentication to work
   unmodified with SAnon.

4.1.3.  GSS_C_NT_DOMAINBASED_SERVICE

   Other service name types such as the one defined in [RFC5179] are
   treated identically to GSS_C_NT_HOSTBASED_SERVICE.

4.1.4.  GSS_C_NT_ANONYMOUS

   When importing a name of this type the name string MUST be ignored.
   Functions that return a name type to the caller MUST always return
   this name type.  The display form is the well known anonymous name
   string, WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS.  A SAnon peer always
   observes this name.

   The well known anonymous name has the same display form as in
   Kerberos [RFC8062], allowing acceptors to perform name-based
   authorization in a mechanism-agnostic manner.

Howard                  Expires October 13, 2020                [Page 4]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

4.2.  Canonicalization

   The SAnon GSS-API mechanism has a single anonymous identity, the well
   known anonymous name.  The canonical form is the well known anonymous
   name string with the GSS_C_NT_ANONYMOUS name type.

4.3.  Mechanism Selection Hints

   Many deployed applications do not have explicit support for anonymous
   authentication.  To ease deployment, we recommend allowing anonymous
   authentication to be requested by the initiator acquiring a
   credential with the well known anonymous name, or specifying that
   name as the authentication target.  Where the initiator credential
   name is entered by the end-user, this allows anonymous authentication
   to be requested without requiring the application be modified to
   support GSS_C_ANON_FLAG.

   This approach may, however, disadvantage applications that wish to
   use GSS_C_ANON_FLAG to select anonymous authentication, as importing
   a non-anonymous initiator name will fail with this approach.  We
   consider this an acceptable compromise given the limited deployment
   of GSS_C_ANON_FLAG in existing implementations.

5.  Definitions and Token Formats

5.1.  Context Establishment Tokens

5.1.1.  Initial context token

   The initial context token is framed per Section 1 of [RFC2743]:

   GSS-API DEFINITIONS ::=
       BEGIN

       MechType ::= OBJECT IDENTIFIER -- 1.3.6.1.4.1.5322.26.1.110
       GSSAPI-Token ::=
       [APPLICATION 0] IMPLICIT SEQUENCE {
            thisMech MechType,
            innerToken ANY DEFINED BY thisMech
                -- 32 byte initiator public key
       }
       END

   On the first call to GSS_Init_sec_context(), the mechanism checks for
   one of the following:

      The caller set anon_req_flag (GSS_C_ANON_FLAG); or

Howard                  Expires October 13, 2020                [Page 5]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

      The claimant_cred_handle identity is the well known anonymous
      name; or

      The claimant_cred_handle is the default credential and targ_name
      an anonymous name.

   If none of the above are the case, the call MUST fail with
   GSS_S_UNAVAILABLE.

   If proceeding, the initiator generates a fresh secret and public key
   pair per [RFC7748] Section 6.1 and returns GSS_S_CONTINUE_NEEDED,
   indicating that a subsequent context token from the acceptor is
   expected.  The innerToken field of the output_token contains the
   initiator's 32 byte public key.

5.1.2.  Acceptor context token

   Upon receiving a context token from the initiator, the acceptor
   validates that the token is well formed and contains a public key of
   the requisite length.  The acceptor generates a fresh secret and
   public key pair.  The context session key is computed as specified in
   Section 6.

   The acceptor constructs an output_token by concatenating its public
   key with the token emitted by calling GSS_GetMIC() with the default
   QOP and zero-length octet string.  The output token is sent to the
   initiator without additional framing.

   The acceptor then returns GSS_S_COMPLETE, setting src_name to the
   well known anonymous name.  The reply_det_state (GSS_C_REPLAY_FLAG),
   sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG),
   integ_avail (GSS_C_INTEG_FLAG) and anon_state (GSS_C_ANON_FLAG)
   security context flags are set to TRUE.  The context is ready to use.

5.1.3.  Initiator context completion

   Upon receiving the acceptor context token and verifying it is well
   formed, the initiator extracts the acceptor's public key (being the
   first 32 bytes of the input token) and computes the context session
   key per Section 6.

   The initiator calls GSS_VerifyMIC() with the MIC extracted from the
   context token and the zero-length octet string.  If successful, the
   initiator returns GSS_S_COMPLETE to the caller, to indicate the
   initiator is authenticated and the context is ready for use.  No
   output token is emitted.  Security context flags are set as for the
   acceptor context.

Howard                  Expires October 13, 2020                [Page 6]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

5.2.  Per-Message Tokens

   The per-message tokens definitions are imported from [RFC4121]
   Section 4.2.  The base key used to derive specific keys for signing
   and sealing messages is defined in Section 6.  The [RFC3961]
   encryption and checksum algorithms use the aes128-cts-hmac-sha256-128
   encryption type defined in [RFC8009].  The AcceptorSubkey flag as
   defined in [RFC4121] Section 4.2.2 MUST be set.

5.3.  Context Deletion Tokens

   Context deletion tokens are empty in this mechanism.  The behavior of
   GSS_Delete_sec_context() [RFC2743] is as specified in [RFC4121]
   Section 4.3.

5.4.  Exported Name Tokens

   The exported name token format is the standard exported name format
   specified by [RFC2743] Section 3.2, where MECH_OID is the mechanism
   OID given in Section 3 and NAME is the well known anonymous name
   string.

6.  Key derivation

   The context session key is known as the base key, and is computed
   using a key derivation function from [SP800-108] Section 5.1 (using
   HMAC as the PRF):

       base key = HMAC-SHA-256(K1, i | label | 0x00 | context | L)

   where:

   K1            the output of X25519(local secret key, peer public key)
                 as specified in [RFC7748] Section 6.1

   i             the constant 0x00000001, representing the iteration
                 count

   label         the string "sanon-x25519" (without quotation marks)

   context       initiator public key | acceptor public key | channel
                 binding application data (if present)

   L             the constant 0x00000080, being length in bits of the
                 key to be outputted expressed in big-endian binary
                 representation of 4 bytes

Howard                  Expires October 13, 2020                [Page 7]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

   The inclusion of channel bindings in the key derivation function
   means that the acceptor cannot ignore initiator channel bindings;
   this differs from some other mechanisms.

   The base key provides the acceptor-asserted subkey defined in
   [RFC4121] Section 2 and is used to generate keys for per-message
   tokens and the GSS-API PRF.  Its encryption type is aes128-cts-hmac-
   sha256-128 per [RFC8009].  The [RFC3961] algorithm protocol
   parameters are as given in [RFC8009] Section 5.

7.  Pseudo-Random Function

   The [RFC4401] GSS-API pseudo-random function for this mechanism
   imports the definitions from [RFC8009], using the base key for both
   GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL usages.

8.  Security Considerations

   This document defines a GSS-API security mechanism, and therefore
   deals in security and has security considerations text embedded
   throughout.  This section only addresses security considerations
   associated with the SAnon mechanism described in this document.  It
   does not address security considerations associated with the GSS-API
   itself.

   This mechanism provides only for key agreement.  It does not
   authenticate the identity of either party.  It MUST not be selected
   if either party requires identification of its peer.

9.  Acknowledgements

   AuriStor, Inc funded the design of this protocol, along with an
   implementation for the Heimdal GSS-API library.

   Jeffrey Altman, Greg Hudson, Simon Josefsson, and Nicolas Williams
   provided valuable feedback on this document.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Howard                  Expires October 13, 2020                [Page 8]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743,
              DOI 10.17487/RFC2743, January 2000,
              <https://www.rfc-editor.org/info/rfc2743>.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
              2005, <https://www.rfc-editor.org/info/rfc3961>.

   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              DOI 10.17487/RFC4121, July 2005,
              <https://www.rfc-editor.org/info/rfc4121>.

   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
              Extension for the Generic Security Service Application
              Program Interface (GSS-API)", RFC 4401,
              DOI 10.17487/RFC4401, February 2006,
              <https://www.rfc-editor.org/info/rfc4401>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8009]  Jenkins, M., Peck, M., and K. Burgin, "AES Encryption with
              HMAC-SHA2 for Kerberos 5", RFC 8009, DOI 10.17487/RFC8009,
              October 2016, <https://www.rfc-editor.org/info/rfc8009>.

10.2.  Informative References

   [I-D.zhu-negoex]
              Short, M., Zhu, L., Damour, K., and D. McPherson, "SPNEGO
              Extended Negotiation (NEGOEX) Security Mechanism", draft-
              zhu-negoex-04 (work in progress), January 2011.

   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
              Simple and Protected Generic Security Service Application
              Program Interface (GSS-API) Negotiation Mechanism",
              RFC 4178, DOI 10.17487/RFC4178, October 2005,
              <https://www.rfc-editor.org/info/rfc4178>.

   [RFC5179]  Williams, N., "Generic Security Service Application
              Program Interface (GSS-API) Domain-Based Service Names
              Mapping for the Kerberos V GSS Mechanism", RFC 5179,
              DOI 10.17487/RFC5179, May 2008,
              <https://www.rfc-editor.org/info/rfc5179>.

Howard                  Expires October 13, 2020                [Page 9]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

   [RFC5587]  Williams, N., "Extended Generic Security Service Mechanism
              Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009,
              <https://www.rfc-editor.org/info/rfc5587>.

   [RFC8062]  Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed.,
              "Anonymity Support for Kerberos", RFC 8062,
              DOI 10.17487/RFC8062, February 2017,
              <https://www.rfc-editor.org/info/rfc8062>.

   [SP800-108]
              Chen, L., "Recommendation for Key Derivation Using
              Pseudorandom Functions (Revised)", October 2009.

Appendix A.  Test Vectors

   initiator secret key  69 df cc 04 2b 7a 33 f8 1a 43 fb f0 33 0a b5 3f
                         bc 20 e6 c1 4f f8 26 ce 6a 4d bc 8c 6e e4 2b a9

   initiator public key  d2 1e 3e 58 60 b0 16 6c d1 cb 38 1a aa 89 62 93
                         07 13 ae e1 76 86 93 10 46 57 a7 a1 9c 1d 76 2e

   initiator token       60 2c 06 0a 2b 06 01 04 01 a9 4a 1a 01 6e d2 1e
                         3e 58 60 b0 16 6c d1 cb 38 1a aa 89 62 93 07 13
                         ae e1 76 86 93 10 46 57 a7 a1 9c 1d 76 2e

   acceptor secret key   3e 4f e6 5b ea 85 94 3b 5a a2 b7 83 f6 26 84 1a
                         10 39 d5 d3 6d af 85 aa a1 6f 12 97 57 99 6c ff

   acceptor public key   a8 32 14 9d 58 33 13 ce 1c 55 7b 2b d1 8a e7 a5
                         59 8c a6 4b 02 20 83 5e 16 be 09 ca 2f 90 60 31

   base key              af f1 8d b7 45 c6 27 cd a8 da d4 9b d7 e7 01 25

   acceptor token        a8 32 14 9d 58 33 13 ce 1c 55 7b 2b d1 8a e7 a5
                         59 8c a6 4b 02 20 83 5e 16 be 09 ca 2f 90 60 31
                         04 04 05 ff ff ff ff ff 00 00 00 00 00 00 00 00
                         45 02 7b a8 15 1c 33 05 22 bb c4 36 84 d2 e1 8c

Appendix B.  Mechanism Attributes

   The [RFC5587] mechanism attributes for this mechanism are:

      GSS_C_MA_MECH_CONCRETE

      GSS_C_MA_ITOK_FRAMED

      GSS_C_MA_AUTH_INIT_ANON

Howard                  Expires October 13, 2020               [Page 10]
Internet-Draft           SAnon GSS-API Mechanism              April 2020

      GSS_C_MA_AUTH_TARG_ANON

      GSS_C_MA_INTEG_PROT

      GSS_C_MA_CONF_PROT

      GSS_C_MA_MIC

      GSS_C_MA_WRAP

      GSS_C_MA_REPLAY_DET

      GSS_C_MA_OOS_DET

      GSS_C_MA_CBINDINGS

      GSS_C_MA_PFS

      GSS_C_MA_CTX_TRANS

Appendix C.  NegoEx

   When SAnon is negotiated by [I-D.zhu-negoex], the authentication
   scheme identifier is DEE384FF-1086-4E86-BE78-B94170BFD376.

   The initiator and acceptor keys for NegoEx checksum generation and
   verification are derived using the GSS-API PRF (see Section 7), with
   the input data "sanon-x25519-initiator-negoex-key" and "sanon-x25519-
   acceptor-negoex-key" respectively (without quotation marks).

   No NegoEx metadata is specified.  Any metadata present MUST be
   ignored.  If the GSS-API implementation supports both SPNEGO
   [RFC4178] and NegoEx, SAnon SHOULD be advertised by both to maximise
   interoperability.

Author's Address

   Luke Howard
   PADL Software Pty Ltd
   PO Box 59
   Central Park, VIC  3145
   Australia

   Email: lukeh@padl.com

Howard                  Expires October 13, 2020               [Page 11]