doc/standardisation/draft-howard-gss-sanon-12.txt

   1
   2
   3
   4
   5 Network Working Group                                          L. Howard
   6 Internet-Draft                                                      PADL
   7 Intended status: Informational                            April 23, 2020
   8 Expires: October 25, 2020
   9
  10
  11                   A Simple Anonymous GSS-API Mechanism
  12                        draft-howard-gss-sanon-12
  13
  14 Abstract
  15
  16    This document defines protocols, procedures and conventions for a
  17    Generic Security Service Application Program Interface (GSS-API)
  18    security mechanism that provides key agreement without authentication
  19    of either party.
  20
  21 Status of This Memo
  22
  23    This Internet-Draft is submitted in full conformance with the
  24    provisions of BCP 78 and BCP 79.
  25
  26    Internet-Drafts are working documents of the Internet Engineering
  27    Task Force (IETF).  Note that other groups may also distribute
  28    working documents as Internet-Drafts.  The list of current Internet-
  29    Drafts is at https://datatracker.ietf.org/drafts/current/.
  30
  31    Internet-Drafts are draft documents valid for a maximum of six months
  32    and may be updated, replaced, or obsoleted by other documents at any
  33    time.  It is inappropriate to use Internet-Drafts as reference
  34    material or to cite them other than as "work in progress."
  35
  36    This Internet-Draft will expire on October 25, 2020.
  37
  38 Copyright Notice
  39
  40    Copyright (c) 2020 IETF Trust and the persons identified as the
  41    document authors.  All rights reserved.
  42
  43    This document is subject to BCP 78 and the IETF Trust's Legal
  44    Provisions Relating to IETF Documents
  45    (https://trustee.ietf.org/license-info) in effect on the date of
  46    publication of this document.  Please review these documents
  47    carefully, as they describe your rights and restrictions with respect
  48    to this document.  Code Components extracted from this document must
  49    include Simplified BSD License text as described in Section 4.e of
  50    the Trust Legal Provisions and are provided without warranty as
  51    described in the Simplified BSD License.
  52
  53
  54
  55
  56 Howard                  Expires October 25, 2020                [Page 1]
  57 \f
  58 Internet-Draft           SAnon GSS-API Mechanism              April 2020
  59
  60
  61 Table of Contents
  62
  63    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  64    2.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
  65    3.  Discovery and Negotiation . . . . . . . . . . . . . . . . . .   3
  66    4.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  67    4.1.  Mechanism Names . . . . . . . . . . . . . . . . . . . . . .   3
  68    4.2.  Display Name Format . . . . . . . . . . . . . . . . . . . .   3
  69    4.3.  Exported Name Format  . . . . . . . . . . . . . . . . . . .   3
  70    5.  Definitions and Token Formats . . . . . . . . . . . . . . . .   4
  71    5.1.  Context Establishment Tokens  . . . . . . . . . . . . . . .   4
  72    5.1.1.  Initial context token . . . . . . . . . . . . . . . . . .   4
  73    5.1.2.  Acceptor context token  . . . . . . . . . . . . . . . . .   5
  74    5.1.3.  Initiator context completion  . . . . . . . . . . . . . .   5
  75    5.2.  Per-Message Tokens  . . . . . . . . . . . . . . . . . . . .   6
  76    5.3.  Context Deletion Tokens . . . . . . . . . . . . . . . . . .   6
  77    6.  Key derivation  . . . . . . . . . . . . . . . . . . . . . . .   6
  78    7.  Pseudo-Random Function  . . . . . . . . . . . . . . . . . . .   7
  79    8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
  80    9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
  81    10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  82    10.1.  Normative References . . . . . . . . . . . . . . . . . . .   7
  83    10.2.  Informative References . . . . . . . . . . . . . . . . . .   8
  84    Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .   9
  85    Appendix B.  Mechanism Attributes . . . . . . . . . . . . . . . .   9
  86    Appendix C.  NegoEx . . . . . . . . . . . . . . . . . . . . . . .  10
  87    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10
  88
  89 1.  Introduction
  90
  91    The Generic Security Service Application Program Interface (GSS-API)
  92    [RFC2743] provides a framework for authentication and message
  93    protection services through a common programming interface.
  94
  95    The Simple Anonymous mechanism (hereafter SAnon) described in this
  96    document is a simple protocol based on the X25519 elliptic curve
  97    Diffie-Hellman (ECDH) key agreement scheme defined in [RFC7748].  No
  98    authentication of initiator or acceptor is provided.  A potential use
  99    of SAnon is to provide a degree of privacy when bootstrapping unkeyed
 100    entities.
 101
 102 2.  Requirements notation
 103
 104    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 105    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 106    document are to be interpreted as described in [RFC2119].
 107
 108
 109
 110
 111
 112 Howard                  Expires October 25, 2020                [Page 2]
 113 \f
 114 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 115
 116
 117 3.  Discovery and Negotiation
 118
 119    The SAnon mechanism is identified by the following OID:
 120
 121        sanon-x25519 OBJECT IDENTIFIER ::=
 122            {iso(1)identified-organization(3)dod(6)internet(1)
 123             private(4)enterprise(1)padl(5322)gss-sanon(26)
 124             mechanisms(1)sanon-x25519(110)}
 125
 126    The means of discovering GSS-API peers and their supported mechanisms
 127    is out of this specification's scope.  To avoid multiple layers of
 128    negotiation, SAnon is not crypto-agile; a future variant using a
 129    different algorithm would be assigned a different OID.
 130
 131    If anonymity is not desired then SAnon MUST NOT be used.  Either
 132    party can test for anon_state (GSS_C_ANON_FLAG) to check if anonymous
 133    authentication was performed.
 134
 135 4.  Naming
 136
 137 4.1.  Mechanism Names
 138
 139    A SAnon mechanism name is abstractly a boolean indicating whether it
 140    represents an anonymous identity.  Anonymous identities are names
 141    imported with the GSS_C_NT_ANONYMOUS name type.  Implementations MAY
 142    map other names to anonymous identities according to local policy.
 143    Names representing non-anonymous identities MUST be importable so
 144    that initiators with non-default credentials can engage SAnon by
 145    setting anon_req_flag (GSS_C_ANON_FLAG).
 146
 147 4.2.  Display Name Format
 148
 149    When GSS_Display_name() is called on a mechanism name representing an
 150    anonymous identity, the display string is WELLKNOWN/
 151    ANONYMOUS@WELLKNOWN:ANONYMOUS [RFC8062] and the name type is
 152    GSS_C_NT_ANONYMOUS.  This is always the name observed by a SAnon
 153    peer.  All context APIs that return peer names MUST return this name
 154    for both parties if the context is established.
 155
 156 4.3.  Exported Name Format
 157
 158    SAnon uses the mechanism-independent exported name object format
 159    defined in [RFC2743] Section 3.2.  All lengths are encoded as big-
 160    endian integers.  The export of non-anonymous mechanism names MUST
 161    fail with GSS_S_BAD_NAME.
 162
 163
 164
 165
 166
 167
 168 Howard                  Expires October 25, 2020                [Page 3]
 169 \f
 170 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 171
 172
 173      +--------------+--------------+---------------------------------+
 174      | Length       | Name         | Description                     |
 175      +--------------+--------------+---------------------------------+
 176      | 2            | TOK_ID       | 04 01                           |
 177      |              |              |                                 |
 178      | 2            | MECH_OID_LEN | Length of the mechanism OID     |
 179      |              |              |                                 |
 180      | MECH_OID_LEN | MECH_OID     | The SAnon mechanism OID, in DER |
 181      |              |              |                                 |
 182      | 4            | NAME_LEN     | 00 00 00 01                     |
 183      |              |              |                                 |
 184      | 1            | NAME         | 01                              |
 185      +--------------+--------------+---------------------------------+
 186
 187 5.  Definitions and Token Formats
 188
 189 5.1.  Context Establishment Tokens
 190
 191 5.1.1.  Initial context token
 192
 193    The initial context token is framed per Section 1 of [RFC2743]:
 194
 195    GSS-API DEFINITIONS ::=
 196        BEGIN
 197
 198        MechType ::= OBJECT IDENTIFIER -- 1.3.6.1.4.1.5322.26.1.110
 199        GSSAPI-Token ::=
 200        [APPLICATION 0] IMPLICIT SEQUENCE {
 201             thisMech MechType,
 202             innerToken ANY DEFINED BY thisMech
 203                 -- 32 byte initiator public key
 204        }
 205        END
 206
 207    On the first call to GSS_Init_sec_context(), the mechanism checks if
 208    one or more of the following are true:
 209
 210       The caller set anon_req_flag (GSS_C_ANON_FLAG)
 211
 212       The claimant credential identity is anonymous (see Section 4.1)
 213
 214       The claimant credential is the default one and target identity is
 215       anonymous
 216
 217    If none of these are the case, the call MUST fail with
 218    GSS_S_UNAVAILABLE.
 219
 220
 221
 222
 223
 224 Howard                  Expires October 25, 2020                [Page 4]
 225 \f
 226 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 227
 228
 229    If proceeding, the initiator generates a fresh secret and public key
 230    pair per [RFC7748] Section 6.1 and returns GSS_S_CONTINUE_NEEDED,
 231    indicating that a subsequent context token from the acceptor is
 232    expected.  The innerToken field of the output_token contains the
 233    initiator's 32 byte public key.
 234
 235    Portable initiators are RECOMMENDED to use default credentials
 236    whenever possible and request anonymity only through anon_req_flag
 237    (see [RFC8062] Section 6).
 238
 239 5.1.2.  Acceptor context token
 240
 241    Upon receiving a context token from the initiator, the acceptor
 242    validates that the token is well formed and contains a public key of
 243    the requisite length.  The acceptor generates a fresh secret and
 244    public key pair.  The context session key is computed as specified in
 245    Section 6.
 246
 247    The acceptor constructs an output_token by concatenating its public
 248    key with the token emitted by calling GSS_GetMIC() with the default
 249    QOP and zero-length octet string.  The output token is sent to the
 250    initiator without additional framing.
 251
 252    The acceptor then returns GSS_S_COMPLETE, setting src_name to the
 253    canonical anonymous name.  The reply_det_state (GSS_C_REPLAY_FLAG),
 254    sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG),
 255    integ_avail (GSS_C_INTEG_FLAG) and anon_state (GSS_C_ANON_FLAG)
 256    security context flags are set.  The context is ready to use.
 257
 258 5.1.3.  Initiator context completion
 259
 260    Upon receiving the acceptor context token and verifying it is well
 261    formed, the initiator extracts the acceptor's public key (being the
 262    first 32 bytes of the input token) and computes the context session
 263    key per Section 6.
 264
 265    The initiator calls GSS_VerifyMIC() with the MIC extracted from the
 266    context token and the zero-length octet string.  If successful, the
 267    initiator returns GSS_S_COMPLETE to the caller, to indicate the
 268    initiator is authenticated and the context is ready for use.  No
 269    output token is emitted.  Supported security context flags are as for
 270    the acceptor context.  The flags returned to the caller are the
 271    intersection of supported and requested flags, combined with
 272    anon_state (GSS_C_ANON_FLAG) which is set unconditionally.
 273
 274
 275
 276
 277
 278
 279
 280 Howard                  Expires October 25, 2020                [Page 5]
 281 \f
 282 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 283
 284
 285 5.2.  Per-Message Tokens
 286
 287    The per-message tokens definitions are imported from [RFC4121]
 288    Section 4.2.  The base key used to derive specific keys for signing
 289    and sealing messages is defined in Section 6.  The [RFC3961]
 290    encryption and checksum algorithms use the aes128-cts-hmac-sha256-128
 291    encryption type defined in [RFC8009].  The AcceptorSubkey flag as
 292    defined in [RFC4121] Section 4.2.2 MUST be set.
 293
 294 5.3.  Context Deletion Tokens
 295
 296    Context deletion tokens are empty in this mechanism.  The behavior of
 297    GSS_Delete_sec_context() [RFC2743] is as specified in [RFC4121]
 298    Section 4.3.
 299
 300 6.  Key derivation
 301
 302    The context session key is known as the base key, and is computed
 303    using a key derivation function from [SP800-108] Section 5.1 (using
 304    HMAC as the PRF):
 305
 306        base key = HMAC-SHA-256(K1, i | label | 0x00 | context | L)
 307
 308    where:
 309
 310    K1            the output of X25519(local secret key, peer public key)
 311                  as specified in [RFC7748] Section 6.1
 312
 313    i             the constant 0x00000001, representing the iteration
 314                  count expressed in big-endian binary representation of
 315                  4 bytes
 316
 317    label         the string "sanon-x25519" (without quotation marks)
 318
 319    context       initiator public key | acceptor public key | channel
 320                  binding application data (if present)
 321
 322    L             the constant 0x00000080, being length in bits of the
 323                  key to be outputted expressed in big-endian binary
 324                  representation of 4 bytes
 325
 326    The inclusion of channel bindings in the key derivation function
 327    means that the acceptor cannot ignore initiator channel bindings;
 328    this differs from some other mechanisms.
 329
 330    The base key provides the acceptor-asserted subkey defined in
 331    [RFC4121] Section 2 and is used to generate keys for per-message
 332    tokens and the GSS-API PRF.  Its encryption type is aes128-cts-hmac-
 333
 334
 335
 336 Howard                  Expires October 25, 2020                [Page 6]
 337 \f
 338 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 339
 340
 341    sha256-128 per [RFC8009].  The [RFC3961] algorithm protocol
 342    parameters are as given in [RFC8009] Section 5.
 343
 344 7.  Pseudo-Random Function
 345
 346    The [RFC4401] GSS-API pseudo-random function for this mechanism
 347    imports the definitions from [RFC8009], using the base key for both
 348    GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL usages.
 349
 350 8.  Security Considerations
 351
 352    This document defines a GSS-API security mechanism, and therefore
 353    deals in security and has security considerations text embedded
 354    throughout.  This section only addresses security considerations
 355    associated with the SAnon mechanism described in this document.  It
 356    does not address security considerations associated with the GSS-API
 357    itself.
 358
 359    This mechanism provides only for key agreement.  It does not
 360    authenticate the identity of either party.  It MUST NOT be selected
 361    if either party requires identification of its peer.
 362
 363    SAnon mechanism names are not unary.  Implementations MUST ensure
 364    that GSS_Compare_name() always sets name_equal to FALSE when
 365    comparing mechanism names.
 366
 367 9.  Acknowledgements
 368
 369    AuriStor, Inc funded the design of this protocol, along with an
 370    implementation for the Heimdal GSS-API library.
 371
 372    Jeffrey Altman, Greg Hudson, Simon Josefsson, and Nicolas Williams
 373    provided valuable feedback on this document.
 374
 375 10.  References
 376
 377 10.1.  Normative References
 378
 379    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 380               Requirement Levels", BCP 14, RFC 2119,
 381               DOI 10.17487/RFC2119, March 1997,
 382               <https://www.rfc-editor.org/info/rfc2119>.
 383
 384    [RFC2743]  Linn, J., "Generic Security Service Application Program
 385               Interface Version 2, Update 1", RFC 2743,
 386               DOI 10.17487/RFC2743, January 2000,
 387               <https://www.rfc-editor.org/info/rfc2743>.
 388
 389
 390
 391
 392 Howard                  Expires October 25, 2020                [Page 7]
 393 \f
 394 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 395
 396
 397    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
 398               Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
 399               2005, <https://www.rfc-editor.org/info/rfc3961>.
 400
 401    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 402               Version 5 Generic Security Service Application Program
 403               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 404               DOI 10.17487/RFC4121, July 2005,
 405               <https://www.rfc-editor.org/info/rfc4121>.
 406
 407    [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
 408               Extension for the Generic Security Service Application
 409               Program Interface (GSS-API)", RFC 4401,
 410               DOI 10.17487/RFC4401, February 2006,
 411               <https://www.rfc-editor.org/info/rfc4401>.
 412
 413    [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
 414               for Security", RFC 7748, DOI 10.17487/RFC7748, January
 415               2016, <https://www.rfc-editor.org/info/rfc7748>.
 416
 417    [RFC8009]  Jenkins, M., Peck, M., and K. Burgin, "AES Encryption with
 418               HMAC-SHA2 for Kerberos 5", RFC 8009, DOI 10.17487/RFC8009,
 419               October 2016, <https://www.rfc-editor.org/info/rfc8009>.
 420
 421 10.2.  Informative References
 422
 423    [I-D.zhu-negoex]
 424               Short, M., Zhu, L., Damour, K., and D. McPherson, "SPNEGO
 425               Extended Negotiation (NEGOEX) Security Mechanism", draft-
 426               zhu-negoex-04 (work in progress), January 2011.
 427
 428    [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 429               Simple and Protected Generic Security Service Application
 430               Program Interface (GSS-API) Negotiation Mechanism",
 431               RFC 4178, DOI 10.17487/RFC4178, October 2005,
 432               <https://www.rfc-editor.org/info/rfc4178>.
 433
 434    [RFC4757]  Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
 435               Kerberos Encryption Types Used by Microsoft Windows",
 436               RFC 4757, DOI 10.17487/RFC4757, December 2006,
 437               <https://www.rfc-editor.org/info/rfc4757>.
 438
 439    [RFC5587]  Williams, N., "Extended Generic Security Service Mechanism
 440               Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009,
 441               <https://www.rfc-editor.org/info/rfc5587>.
 442
 443
 444
 445
 446
 447
 448 Howard                  Expires October 25, 2020                [Page 8]
 449 \f
 450 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 451
 452
 453    [RFC8062]  Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed.,
 454               "Anonymity Support for Kerberos", RFC 8062,
 455               DOI 10.17487/RFC8062, February 2017,
 456               <https://www.rfc-editor.org/info/rfc8062>.
 457
 458    [SP800-108]
 459               Chen, L., "Recommendation for Key Derivation Using
 460               Pseudorandom Functions (Revised)", October 2009.
 461
 462 Appendix A.  Test Vectors
 463
 464    initiator secret key  69 df cc 04 2b 7a 33 f8 1a 43 fb f0 33 0a b5 3f
 465                          bc 20 e6 c1 4f f8 26 ce 6a 4d bc 8c 6e e4 2b a9
 466
 467    initiator public key  d2 1e 3e 58 60 b0 16 6c d1 cb 38 1a aa 89 62 93
 468                          07 13 ae e1 76 86 93 10 46 57 a7 a1 9c 1d 76 2e
 469
 470    initiator token       60 2c 06 0a 2b 06 01 04 01 a9 4a 1a 01 6e d2 1e
 471                          3e 58 60 b0 16 6c d1 cb 38 1a aa 89 62 93 07 13
 472                          ae e1 76 86 93 10 46 57 a7 a1 9c 1d 76 2e
 473
 474    acceptor secret key   3e 4f e6 5b ea 85 94 3b 5a a2 b7 83 f6 26 84 1a
 475                          10 39 d5 d3 6d af 85 aa a1 6f 12 97 57 99 6c ff
 476
 477    acceptor public key   a8 32 14 9d 58 33 13 ce 1c 55 7b 2b d1 8a e7 a5
 478                          59 8c a6 4b 02 20 83 5e 16 be 09 ca 2f 90 60 31
 479
 480    base key              af f1 8d b7 45 c6 27 cd a8 da d4 9b d7 e7 01 25
 481
 482    acceptor token        a8 32 14 9d 58 33 13 ce 1c 55 7b 2b d1 8a e7 a5
 483                          59 8c a6 4b 02 20 83 5e 16 be 09 ca 2f 90 60 31
 484                          04 04 05 ff ff ff ff ff 00 00 00 00 00 00 00 00
 485                          45 02 7b a8 15 1c 33 05 22 bb c4 36 84 d2 e1 8c
 486
 487 Appendix B.  Mechanism Attributes
 488
 489    The [RFC5587] mechanism attributes for this mechanism are:
 490
 491       GSS_C_MA_MECH_CONCRETE
 492
 493       GSS_C_MA_ITOK_FRAMED
 494
 495       GSS_C_MA_AUTH_INIT_ANON
 496
 497       GSS_C_MA_AUTH_TARG_ANON
 498
 499       GSS_C_MA_INTEG_PROT
 500
 501
 502
 503
 504 Howard                  Expires October 25, 2020                [Page 9]
 505 \f
 506 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 507
 508
 509       GSS_C_MA_CONF_PROT
 510
 511       GSS_C_MA_MIC
 512
 513       GSS_C_MA_WRAP
 514
 515       GSS_C_MA_REPLAY_DET
 516
 517       GSS_C_MA_OOS_DET
 518
 519       GSS_C_MA_CBINDINGS
 520
 521       GSS_C_MA_PFS
 522
 523       GSS_C_MA_CTX_TRANS
 524
 525 Appendix C.  NegoEx
 526
 527    When SAnon is negotiated by [I-D.zhu-negoex], the authentication
 528    scheme identifier is DEE384FF-1086-4E86-BE78-B94170BFD376.
 529
 530    The initiator and acceptor keys for NegoEx checksum generation and
 531    verification are derived using the GSS-API PRF (see Section 7), with
 532    the input data "sanon-x25519-initiator-negoex-key" and "sanon-x25519-
 533    acceptor-negoex-key" respectively (without quotation marks).
 534
 535    The initiator metadata, if present, contains a set of GSS-API flags
 536    encoded as a 4 byte little endian integer.  This is used to convey to
 537    the acceptor any Windows-specific GSS-API flags (see [RFC4757]
 538    Section 7.1).  Other GSS-API flags MUST NOT be present in the
 539    metadata.
 540
 541    It is RECOMMENDED that GSS-API implementations supporting both SPNEGO
 542    [RFC4178] and NegoEx advertise SAnon under both to maximise
 543    interoperability.
 544
 545 Author's Address
 546
 547    Luke Howard
 548    PADL Software Pty Ltd
 549    PO Box 59
 550    Central Park, VIC  3145
 551    Australia
 552
 553    Email: lukeh@padl.com
 554
 555
 556
 557
 558
 559
 560 Howard                  Expires October 25, 2020               [Page 10]