idnits 2.17.1 draft-ietf-kitten-gss-sanon-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 414 has weird spacing: '...ret key b0 d...' -- The document date (July 5, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'APPLICATION 0' is mentioned on line 169, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8009 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Howard 3 Internet-Draft PADL 4 Intended status: Standards Track July 5, 2020 5 Expires: January 6, 2021 7 A Simple Anonymous GSS-API Mechanism 8 draft-ietf-kitten-gss-sanon-01 10 Abstract 12 This document defines protocols, procedures and conventions for a 13 Generic Security Service Application Program Interface (GSS-API) 14 security mechanism that provides key agreement without authentication 15 of either party. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 6, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 53 3. Discovery and Negotiation . . . . . . . . . . . . . . . . . . 3 54 4. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4.1. Mechanism Names . . . . . . . . . . . . . . . . . . . . . . 3 56 4.2. Display Name Format . . . . . . . . . . . . . . . . . . . . 3 57 4.3. Exported Name Format . . . . . . . . . . . . . . . . . . . 3 58 5. Definitions and Token Formats . . . . . . . . . . . . . . . . 4 59 5.1. Context Establishment Tokens . . . . . . . . . . . . . . . 4 60 5.1.1. Initial context token . . . . . . . . . . . . . . . . . . 4 61 5.1.2. Acceptor context token . . . . . . . . . . . . . . . . . 5 62 5.1.3. Initiator context completion . . . . . . . . . . . . . . 5 63 5.2. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 6 64 5.3. Context Deletion Tokens . . . . . . . . . . . . . . . . . . 6 65 6. Key derivation . . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Pseudo-Random Function . . . . . . . . . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 9 73 Appendix B. Mechanism Attributes . . . . . . . . . . . . . . . . 10 74 Appendix C. NegoEx . . . . . . . . . . . . . . . . . . . . . . . 10 75 Appendix D. IANA Considerations . . . . . . . . . . . . . . . . 11 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 The Generic Security Service Application Program Interface (GSS-API) 81 [RFC2743] provides a framework for authentication and message 82 protection services through a common programming interface. 84 The Simple Anonymous mechanism (hereafter SAnon) described in this 85 document is a simple protocol based on the X25519 elliptic curve 86 Diffie-Hellman (ECDH) key agreement scheme defined in [RFC7748]. No 87 authentication of initiator or acceptor is provided. A potential use 88 of SAnon is to provide a degree of privacy when bootstrapping unkeyed 89 entities. 91 2. Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Discovery and Negotiation 99 The SAnon mechanism is identified by the following OID: 101 sanon-x25519 OBJECT IDENTIFIER ::= 102 {iso(1)org(3)dod(6)internet(1) 103 security(5)mechanisms(5)sanon-x25519(tbd)} 105 The means of discovering GSS-API peers and their supported mechanisms 106 is out of this specification's scope. To avoid multiple layers of 107 negotiation, SAnon is not crypto-agile; a future variant using a 108 different algorithm would be assigned a different OID. 110 If anonymity is not desired then SAnon MUST NOT be used. Either 111 party can test for anon_state (GSS_C_ANON_FLAG) to check if anonymous 112 authentication was performed. 114 4. Naming 116 4.1. Mechanism Names 118 A SAnon mechanism name is abstractly a boolean indicating whether it 119 represents an anonymous identity. Anonymous identities are names 120 imported with the GSS_C_NT_ANONYMOUS name type. Implementations MAY 121 map other names to anonymous identities according to local policy. 122 Names representing non-anonymous identities MUST be importable so 123 that initiators with non-default credentials can engage SAnon by 124 setting anon_req_flag (GSS_C_ANON_FLAG). 126 4.2. Display Name Format 128 When GSS_Display_name() is called on a mechanism name representing an 129 anonymous identity, the display string is WELLKNOWN/ 130 ANONYMOUS@WELLKNOWN:ANONYMOUS [RFC8062] and the name type is 131 GSS_C_NT_ANONYMOUS. This is always the name observed by a SAnon 132 peer. All context APIs that return peer names MUST return this name 133 for both parties if the context is established. 135 4.3. Exported Name Format 137 SAnon uses the mechanism-independent exported name object format 138 defined in [RFC2743] Section 3.2. All lengths are encoded as big- 139 endian integers. The export of non-anonymous mechanism names MUST 140 fail with GSS_S_BAD_NAME. 142 +--------------+--------------+---------------------------------+ 143 | Length | Name | Description | 144 +--------------+--------------+---------------------------------+ 145 | 2 | TOK_ID | 04 01 | 146 | | | | 147 | 2 | MECH_OID_LEN | Length of the mechanism OID | 148 | | | | 149 | MECH_OID_LEN | MECH_OID | The SAnon mechanism OID, in DER | 150 | | | | 151 | 4 | NAME_LEN | 00 00 00 01 | 152 | | | | 153 | 1 | NAME | 01 | 154 +--------------+--------------+---------------------------------+ 156 5. Definitions and Token Formats 158 5.1. Context Establishment Tokens 160 5.1.1. Initial context token 162 The initial context token is framed per Section 1 of [RFC2743]: 164 GSS-API DEFINITIONS ::= 165 BEGIN 167 MechType ::= OBJECT IDENTIFIER -- TBD 168 GSSAPI-Token ::= 169 [APPLICATION 0] IMPLICIT SEQUENCE { 170 thisMech MechType, 171 innerToken ANY DEFINED BY thisMech 172 -- 32 byte initiator public key 173 -- 8 byte protocol flags (optional) 174 } 175 END 177 On the first call to GSS_Init_sec_context(), the mechanism checks if 178 one or more of the following are true: 180 The caller set anon_req_flag (GSS_C_ANON_FLAG) 182 The claimant credential identity is anonymous (see Section 4.1) 184 The claimant credential is the default one and target identity is 185 anonymous 187 If none of these are the case, the call MUST fail with 188 GSS_S_UNAVAILABLE. 190 If proceeding, the initiator generates a fresh secret and public key 191 pair per [RFC7748] Section 6.1 and returns GSS_S_CONTINUE_NEEDED, 192 indicating that a subsequent context token from the acceptor is 193 expected. The innerToken field of the output_token contains the 194 initiator's 32 byte public key, optionally concatenated with a 64-bit 195 big-endian integer containing flags that are not optional and the 196 acceptor would be otherwise be unable to infer (such as those defined 197 in [RFC4757] Section 7.1). 199 Portable initiators are RECOMMENDED to use default credentials 200 whenever possible and request anonymity only through anon_req_flag 201 (see [RFC8062] Section 6). 203 5.1.2. Acceptor context token 205 Upon receiving a context token from the initiator, the acceptor 206 validates that the token is well formed. The acceptor generates a 207 fresh secret and public key pair. The context session key is 208 computed as specified in Section 6. 210 The acceptor constructs an output_token by concatenating its public 211 key with the token emitted by calling GSS_GetMIC() with the default 212 QOP and zero-length octet string. The output token is sent to the 213 initiator without additional framing. 215 The acceptor then returns GSS_S_COMPLETE, setting src_name to the 216 canonical anonymous name. The reply_det_state (GSS_C_REPLAY_FLAG), 217 sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG), 218 integ_avail (GSS_C_INTEG_FLAG) and anon_state (GSS_C_ANON_FLAG) 219 security context flags are set, along with any additional flags 220 received from the initiator that are supported by the acceptor. The 221 context is ready to use. 223 5.1.3. Initiator context completion 225 Upon receiving the acceptor context token and verifying it is well 226 formed, the initiator extracts the acceptor's public key (being the 227 first 32 bytes of the input token) and computes the context session 228 key per Section 6. 230 The initiator calls GSS_VerifyMIC() with the MIC extracted from the 231 context token and the zero-length octet string. If successful, the 232 initiator returns GSS_S_COMPLETE to the caller, to indicate the 233 initiator is authenticated and the context is ready for use. No 234 output token is emitted. The security context flags are set as for 235 the acceptor, including any additional flags sent in the initial 236 context token. 238 5.2. Per-Message Tokens 240 The per-message tokens definitions are imported from [RFC4121] 241 Section 4.2. The base key used to derive specific keys for signing 242 and sealing messages is defined in Section 6. The [RFC3961] 243 encryption and checksum algorithms use the aes128-cts-hmac-sha256-128 244 encryption type defined in [RFC8009]. The AcceptorSubkey flag as 245 defined in [RFC4121] Section 4.2.2 MUST be set. 247 5.3. Context Deletion Tokens 249 Context deletion tokens are empty in this mechanism. The behavior of 250 GSS_Delete_sec_context() [RFC2743] is as specified in [RFC4121] 251 Section 4.3. 253 6. Key derivation 255 The context session key is known as the base key, and is computed 256 using a key derivation function from [SP800-108] Section 5.1 (using 257 HMAC as the PRF): 259 base key = HMAC-SHA-256(K1, i | label | 0x00 | context | L) 261 where: 263 K1 the output of X25519(local secret key, peer public key) 264 as specified in [RFC7748] Section 6.1 266 i the constant 0x00000001, representing the iteration 267 count expressed in big-endian binary representation of 268 4 bytes 270 label the string "sanon-x25519" (without quotation marks) 272 context initiator public key | acceptor public key | flags | 273 channel binding application data (if present) 275 L the constant 0x00000080, being length in bits of the 276 key to be outputted expressed in big-endian binary 277 representation of 4 bytes 279 The flags input to the context contains any flags sent by the 280 initiator, defaulting to zero if none were sent, expressed in big- 281 endian binary representation of 8 bytes. 283 The inclusion of channel bindings in the key derivation function 284 means that the acceptor cannot ignore initiator channel bindings; 285 this differs from some other mechanisms. Being the only variable 286 length input to the key derivation function, the length is not 287 included. 289 The base key provides the acceptor-asserted subkey defined in 290 [RFC4121] Section 2 and is used to generate keys for per-message 291 tokens and the GSS-API PRF. Its encryption type is aes128-cts-hmac- 292 sha256-128 per [RFC8009]. The [RFC3961] algorithm protocol 293 parameters are as given in [RFC8009] Section 5. 295 7. Pseudo-Random Function 297 The [RFC4401] GSS-API pseudo-random function for this mechanism 298 imports the definitions from [RFC8009], using the base key for both 299 GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL usages. 301 8. Security Considerations 303 This document defines a GSS-API security mechanism, and therefore 304 deals in security and has security considerations text embedded 305 throughout. This section only addresses security considerations 306 associated with the SAnon mechanism described in this document. It 307 does not address security considerations associated with the GSS-API 308 itself. 310 This mechanism provides only for key agreement. It does not 311 authenticate the identity of either party. It MUST NOT be selected 312 if either party requires identification of its peer. 314 SAnon mechanism names are not unary: there may be many real 315 identities that map to either the anonymous or non-anonymous 316 mechanism name. As such, implementations MUST ensure that 317 GSS_Compare_name() always sets name_equal to FALSE when comparing 318 mechanism names. 320 9. Acknowledgements 322 AuriStor, Inc funded the design of this protocol, along with an 323 implementation for the Heimdal GSS-API library. 325 Jeffrey Altman, Greg Hudson, Simon Josefsson, and Nicolas Williams 326 provided valuable feedback on this document. 328 10. References 329 10.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC2743] Linn, J., "Generic Security Service Application Program 337 Interface Version 2, Update 1", RFC 2743, 338 DOI 10.17487/RFC2743, January 2000, 339 . 341 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 342 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 343 2005, . 345 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 346 Version 5 Generic Security Service Application Program 347 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 348 DOI 10.17487/RFC4121, July 2005, 349 . 351 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 352 Extension for the Generic Security Service Application 353 Program Interface (GSS-API)", RFC 4401, 354 DOI 10.17487/RFC4401, February 2006, 355 . 357 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 358 for Security", RFC 7748, DOI 10.17487/RFC7748, January 359 2016, . 361 [RFC8009] Jenkins, M., Peck, M., and K. Burgin, "AES Encryption with 362 HMAC-SHA2 for Kerberos 5", RFC 8009, DOI 10.17487/RFC8009, 363 October 2016, . 365 10.2. Informative References 367 [I-D.zhu-negoex] 368 Short, M., Zhu, L., Damour, K., and D. McPherson, "SPNEGO 369 Extended Negotiation (NEGOEX) Security Mechanism", draft- 370 zhu-negoex-04 (work in progress), January 2011. 372 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 373 Simple and Protected Generic Security Service Application 374 Program Interface (GSS-API) Negotiation Mechanism", 375 RFC 4178, DOI 10.17487/RFC4178, October 2005, 376 . 378 [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC 379 Kerberos Encryption Types Used by Microsoft Windows", 380 RFC 4757, DOI 10.17487/RFC4757, December 2006, 381 . 383 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 384 Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009, 385 . 387 [RFC8062] Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed., 388 "Anonymity Support for Kerberos", RFC 8062, 389 DOI 10.17487/RFC8062, February 2017, 390 . 392 [SP800-108] 393 Chen, L., "Recommendation for Key Derivation Using 394 Pseudorandom Functions (Revised)", October 2009. 396 Appendix A. Test Vectors 398 The example exchange below contains no additional flags or channel 399 binding information. 401 [[CREF1: These test vectors will need to be regenerated once an OID 402 is assigned by IANA. --LH]] 404 initiator secret key 83 33 f2 ea 2a 22 eb aa 05 39 c6 06 1d 6a 99 05 405 84 24 49 9e 2c 16 c1 b1 34 d9 22 27 f3 f4 5e bd 407 initiator public key 5f 40 66 22 5a 3c fd 72 57 23 c1 8f ae 71 3e 8c 408 ab 32 a7 2c 93 b9 76 66 04 4b 8f e4 a0 c9 69 19 410 initiator token 60 2c 06 0a 2b 06 01 04 01 a9 4a 1a 01 6e 5f 40 411 66 22 5a 3c fd 72 57 23 c1 8f ae 71 3e 8c ab 32 412 a7 2c 93 b9 76 66 04 4b 8f e4 a0 c9 69 19 414 acceptor secret key b0 db 16 32 39 0a dd 93 1e f7 62 bc d3 c9 1d 03 415 e8 d9 59 52 48 eb e2 f2 b5 f7 d8 06 ec dd 50 60 417 acceptor public key 2f 81 51 9f a8 9c 07 f8 eb b2 95 6c 0c c3 22 77 418 ae a1 0e 62 0c 79 33 81 ef 9a c5 b2 f0 d9 1e 06 420 base key 80 76 2c 43 32 6a 95 f5 be 30 6d ea 10 ba f3 d0 422 acceptor token 2f 81 51 9f a8 9c 07 f8 eb b2 95 6c 0c c3 22 77 423 ae a1 0e 62 0c 79 33 81 ef 9a c5 b2 f0 d9 1e 06 424 04 04 05 ff ff ff ff ff 00 00 00 00 00 00 00 00 425 4d 5e a9 e0 e1 9c 7a 61 c2 6a 9a c5 e8 17 5f 04 427 initiator negoex key 2a c8 f9 d0 31 87 40 42 cb d4 50 07 ce db c2 c2 429 acceptor negoex key 73 9f 4d a2 f1 2d f7 f7 d7 ea e4 9d a4 08 62 5b 431 Appendix B. Mechanism Attributes 433 The [RFC5587] mechanism attributes for this mechanism are: 435 GSS_C_MA_MECH_CONCRETE 437 GSS_C_MA_ITOK_FRAMED 439 GSS_C_MA_AUTH_INIT_ANON 441 GSS_C_MA_AUTH_TARG_ANON 443 GSS_C_MA_INTEG_PROT 445 GSS_C_MA_CONF_PROT 447 GSS_C_MA_MIC 449 GSS_C_MA_WRAP 451 GSS_C_MA_REPLAY_DET 453 GSS_C_MA_OOS_DET 455 GSS_C_MA_CBINDINGS 457 GSS_C_MA_PFS 459 GSS_C_MA_CTX_TRANS 461 Appendix C. NegoEx 463 When SAnon is negotiated by [I-D.zhu-negoex], the authentication 464 scheme identifier is DEE384FF-1086-4E86-BE78-B94170BFD376. 466 The initiator and acceptor keys for NegoEx checksum generation and 467 verification are derived using the GSS-API PRF (see Section 7), with 468 the input data "sanon-x25519-initiator-negoex-key" and "sanon-x25519- 469 acceptor-negoex-key" respectively (without quotation marks). No 470 metadata is defined and any, if present, SHOULD be ignored. 472 It is RECOMMENDED that GSS-API implementations supporting both SPNEGO 473 [RFC4178] and NegoEx advertise SAnon under both to maximise 474 interoperability. 476 Appendix D. IANA Considerations 478 The IANA is requested to assign a new entry for the sanon-x25519 479 mechanism in the sub-registry for SMI Security for Mechanism Codes, 480 and to reference this specification in the registry. Section 3 and 481 Appendix A should be updated accordingly. 483 Author's Address 485 Luke Howard 486 PADL Software Pty Ltd 487 PO Box 59 488 Central Park, VIC 3145 489 Australia 491 Email: lukeh@padl.com