Network Working Group L. Howard
Internet-Draft PADL
Intended status: Informational April 13, 2020
Expires: October 15, 2020
A Simple Anonymous GSS-API Mechanism
draft-howard-gss-sanon-07
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 15, 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 15, 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.2. Canonicalization . . . . . . . . . . . . . . . . . . . . . 4
4.3. Mechanism Selection Hints . . . . . . . . . . . . . . . . . 5
4.4. Exported Name Format . . . . . . . . . . . . . . . . . . . 5
5. Definitions and Token Formats . . . . . . . . . . . . . . . . 5
5.1. Context Establishment Tokens . . . . . . . . . . . . . . . 5
5.1.1. Initial context token . . . . . . . . . . . . . . . . . . 6
5.1.2. Acceptor context token . . . . . . . . . . . . . . . . . 6
5.1.3. Initiator context completion . . . . . . . . . . . . . . 7
5.2. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 7
5.3. Context Deletion Tokens . . . . . . . . . . . . . . . . . . 7
6. Key derivation . . . . . . . . . . . . . . . . . . . . . . . 7
7. Pseudo-Random Function . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Mechanism Attributes . . . . . . . . . . . . . . . . 11
Appendix C. NegoEx . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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 15, 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 15, 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
4.1. Name Types
The SAnon mechanism supports a variety of name types. Names are
preserved in order to round-trip through GSS_Export_name() and
GSS_Import_name(), however the mechanism is only concerned with
whether the name represents the anonymous identity.
+-------------------------+----------------------------------+------+
| Name type | Name string | Anon |
+-------------------------+----------------------------------+------+
| GSS_C_NT_USER_NAME | WELLKNOWN/ANONYMOUS@WELLKNOWN:AN | Y |
| | ONYMOUS | |
| | | |
| GSS_C_NT_HOSTBASED_SERV | WELLKNOWN@ANONYMOUS | Y |
| ICE | | |
| | | |
| GSS_C_NT_DOMAINBASED_SE | WELLKNOWN@ANONYMOUS@* | Y |
| RVICE (see [RFC5179]) | | |
| | | |
| GSS_C_NT_ANONYMOUS | Any name string | Y |
| | | |
| GSS_C_NT_EXPORT_NAME | Any valid exported name token | Y/N |
| | | |
| Any other name type | Any name string | N |
+-------------------------+----------------------------------+------+
When importing an exported name, the table is applied recursively to
the name's contents.
4.2. Canonicalization
The canonical form of the anonymous identity has the display string
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS and the GSS_C_NT_ANONYMOUS
name type. This name has the same display form as in Kerberos
[RFC8062], allowing acceptors to perform name-based authorization in
a mechanism-agnostic manner. This is the name observed by a SAnon
peer.
No canonicalization is performed on non-anonymous names.
Howard Expires October 15, 2020 [Page 4]
Internet-Draft SAnon GSS-API Mechanism April 2020
4.3. Mechanism Selection Hints
Many deployed applications do not have explicit support for
GSS_C_ANON_FLAG. To ease deployment, we recommend allowing anonymous
authentication to be requested by the initiator acquiring a
credential with the anonymous identity, or specifying it as the
authentication target. Where the initiator or target name are
entered by the end-user, this allows anonymous authentication to be
requested without requiring the application be modified.
4.4. Exported Name Format
SAnon uses the mechanism-independent exported name object format
defined in [RFC2743] Section 3.2. All lengths are encoded as big-
endian integers.
+-----------------+-----------------+-------------------------------+
| Length | Name | Description |
+-----------------+-----------------+-------------------------------+
| 2 | TOK_ID | 04 01 |
| | | |
| 2 | MECH_OID_LEN | Length of the mechanism OID |
| | | |
| MECH_OID_LEN | MECH_OID | The SAnon mechanism OID, in |
| | | DER |
| | | |
| 4 | NAME_LEN | Length of the remaining |
| | | fields |
| | | |
| 2 | NAME_TYPE_LEN | Length of the exported name |
| | | type |
| | | |
| NAME_TYPE_LEN | NAME_TYPE | Name type OID, in DER |
| | | |
| 4 | NAME_STRING_LEN | Length of the exported name |
| | | string |
| | | |
| NAME_STRING_LEN | NAME_STRING | Exported name string |
+-----------------+-----------------+-------------------------------+
5. Definitions and Token Formats
5.1. Context Establishment Tokens
Howard Expires October 15, 2020 [Page 5]
Internet-Draft SAnon GSS-API Mechanism April 2020
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
The claimant_cred_handle identity is anonymous (see Section 4.1);
or
The claimant_cred_handle is the default credential and targ_name
is anonymous.
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.
Howard Expires October 15, 2020 [Page 6]
Internet-Draft SAnon GSS-API Mechanism April 2020
The acceptor then returns GSS_S_COMPLETE, setting src_name to the
canonical 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.
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.
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
Howard Expires October 15, 2020 [Page 7]
Internet-Draft SAnon GSS-API Mechanism April 2020
i the constant 0x00000001, representing the iteration
count expressed in big-endian binary representation of
4 bytes
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
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.
Howard Expires October 15, 2020 [Page 8]
Internet-Draft SAnon GSS-API Mechanism April 2020
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>.
[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.
Howard Expires October 15, 2020 [Page 9]
Internet-Draft SAnon GSS-API Mechanism April 2020
[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>.
[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
Howard Expires October 15, 2020 [Page 10]
Internet-Draft SAnon GSS-API Mechanism April 2020
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
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.
Howard Expires October 15, 2020 [Page 11]
Internet-Draft SAnon GSS-API Mechanism April 2020
Author's Address
Luke Howard
PADL Software Pty Ltd
PO Box 59
Central Park, VIC 3145
Australia
Email: lukeh@padl.com
Howard Expires October 15, 2020 [Page 12]