idnits 2.17.1 draft-wibrown-ldapssotoken-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2222]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The extended operation requestValue MUST not be set for LDAP SSO Token revocation. -- The document date (February 27, 2017) is 2586 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) -- Obsolete informational reference (is this intentional?): RFC 2078 (Obsoleted by RFC 2743) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Brown 3 Internet-Draft Red Hat Asia-Pacific Pty Ltd 4 Intended status: Standards Track S. Sorce, Ed. 5 Expires: August 31, 2017 Red Hat, Inc. 6 K. Andrews, Ed. 7 The University of Adelaide 8 February 27, 2017 10 Draft LDAP Single Sign On Token Processing 11 draft-wibrown-ldapssotoken-02 13 Abstract 15 LDAP Single Sign On Token is a SASL (Simple Authentication and 16 Security Layer RFC 2222 [RFC2222]) mechanism to allow single sign-on 17 to an LDAP Directory Server environment. Tokens generated by the 18 LDAP server can be transmitted through other protocols and channels, 19 allowing a broad range of clients and middleware to take advantage of 20 single sign-on in environments where Kerberos v5 or other Single Sign 21 On mechanisms may not be avaliable. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 31, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. SASL Component . . . . . . . . . . . . . . . . . . . . . . . 3 61 4.1. Token formats . . . . . . . . . . . . . . . . . . . . . . 3 62 4.2. SASL Client . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.3. SASL Authentication . . . . . . . . . . . . . . . . . . . 6 64 4.4. Valid Not Before Attribute . . . . . . . . . . . . . . . 7 65 5. LDAP Component . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Token Generation . . . . . . . . . . . . . . . . . . . . 7 67 5.1.1. Token Generation Extended Operation . . . . . . . . . 8 68 5.2. Token Revocation . . . . . . . . . . . . . . . . . . . . 8 69 5.2.1. Token Revocation Extended Operation . . . . . . . . . 9 70 5.3. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The need for new, simple single sign-on capable systems has arisen 81 with the development of new technologies and systems. For these 82 systems we should be able to provide a simple, localised and complete 83 single sign-on service. This does not aim to replace Kerberos V5. 84 It is designed for when Kerberos is too invasive for installation in 85 an environment. 87 Tokens generated by this system should be able to be transmitted over 88 different protocols allowing middleware to relay tokens to clients. 89 Clients can then contact the middleware natively and the middleware 90 can negotiate the client authentication with the LDAP server. 92 This implementation will provide an LDAP extended operation to create 93 tokens which a client may cache, or relay to a further client. The 94 token can then be sent in a SASL bind request to the LDAP server. 95 The token remains valid over many binds. Finally, Tokens for a 96 client are always able to be revoked at the LDAP Server using an LDAP 97 extended operation, allowing global logout by the user or 98 administrator. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 3. Format 108 This document has two components. A SASL Mechanism, and LDAP 109 extended operations. 111 There is no strict requirement for the two to coexist: The LDAP 112 Operation is an implementation of the service providing tokens, and 113 the SASL Mechanism to authenticate them. 115 In theory, an alternate protocol and database could generate and 116 authenticate these tokens. 118 4. SASL Component 120 4.1. Token formats 122 Token formats are server implementation specific: As they are the 123 only entity that will decrypt and consume them, they have the option 124 to provide these in any format they wish. 126 This means the client will only see an opaque data structure, and 127 will only need to transmit this opaque structure as part of the 128 authentication request. 130 For the token system to operate correctly the server MUST generate 131 tokens that contain at least these three values: 133 o Date Time Issued 135 o Date Time Until 137 o User Unique Id 139 As the client does not ever see the contents the User Unique Id can 140 be anything within the database that uniquely identifies the user 141 that is the holder of the token. 143 The User Unique Id MUST be an UTF8 String. 145 The token format MUST be encrypted. The token format can be 146 decrypted with either a asymmetric or symmetric keying system. 148 The token format MUST have a form of data authentication. This can 149 be through authenticated encryption, or validation of a hash. 151 The Date Time Issued MUST be a complete timestamp in UTC, to prevent 152 issues with changing timezones. 154 Without these guarantees, the token system is not secure, and is 155 vulnerable to credential forgery attacks. 157 Here is an EXAMPLE ASN.1 format that would be encrypted and sent to 158 the client: 160 LDAPSSOToken ::= SEQUENCE { 161 DateTimeIssued GeneralizedTime, 162 DateTimeUntil GeneralizedTime, 163 UserUniqueId UTF8String } 165 Figure 1 167 This would be encrypted with AES-GCM and transmitted to the client. 169 Another example would be to use a fernet token Fernet Specification 170 [FERNETSPEC]. 172 Version || Timestamp || IV || Ciphertext || HMAC 174 Figure 2 176 Timestamp can be considered to be the DateTimeIssued as: 178 "This field is a 64-bit unsigned big-endian integer. It records the 179 number of seconds elapsed between January 1, 1970 UTC and the time 180 the token was created." 182 We can then create a Cipher text containing: 184 Date Time Until || User Unique Id 186 Figure 3 188 The Date Time Until is a 64-bit unsigned big-endian integer. It is, 189 like Date Time Issued, the number of seconds since January 1, 1970 190 UTC, and the token creation time added to the number of seconds of 191 the requested life time. 193 This example format satisfies all of our data requirements for the 194 sso token system. 196 4.2. SASL Client 198 The client will request a token from the authentication server. The 199 acquisition method for the token is discussed in section XXX. 201 For authentication, the client MUST send the token as it was 202 received. IE changes to formatting are not permitted. 204 The client MUST send the an appropriate authid in RFC 2078 [RFC2078] 205 form. This authid MUST internally match the User Unique Id in the 206 token. The server is responsible for this validation. 208 The client MAY transform the token if acting in a proxy fashion. 209 However this transformation must be deterministic and able to be 210 reversed to satisfy the previous requirement. 212 +-------+ +-------------+ +--------+ 213 | LDAP | | HTTP server | | Client | 214 | | | | <- Login -- | | 215 | | <-- Bind -- | | | | 216 | | - Success -> | | | | 217 | | <- Req Token | | | | 218 | | -- Token --> | | | | 219 | | <- Unbind - | | | | 220 | | - Success -> | | | | 221 | | | Html Escape | | | 222 | | | | -- Safe --> | | 223 | | | | Token | | 224 | | | | | Store | 225 | | | | < Request +- | | 226 | | | Reverse esc | Token | | 227 | | < Token Bind | | | | 228 | | - Success -> | | | | 229 | | <- Operation | | | | 230 | | <- Unbind - | | | | 231 | | - Success -> | | | | 232 | | | | - Response > | | 233 +-------+ +-------------+ +--------+ 235 Figure 4 237 This example shows how a client is issued with a token when 238 communicating with a web server via the HTTP intermediate. The 239 Client does not need to be aware of the SASL/LDAP system in the 240 background, or the token's formatting rules. Provided the HTTP 241 server in proxy, if required to transform the token, is able to undo 242 the transformations, this is a valid scenario. For example, HTML 243 escaping a base64 token. 245 4.3. SASL Authentication 247 The client issues a SASL bind request with the mechanism name 248 LDAPSSOTOKEN. 250 The client sends an appropriate authid in RFC 2078 [RFC2078] form. 252 The client provides the encrypted token that was provided in the 253 LDAPSSOTokenResponse Token Field. 255 The token is decrypted and authenticated based on the token format 256 selected by the server. The server MAY attempt multiple token keys 257 and or formats to find the correct issuing format and key. 259 If the token decryption fails, the attempt with this key and format 260 MUST be considered to fail. 262 If the values have been tampered with, IE hash authentication fails, 263 the attempt with the key and format MUST be considered to fail. 265 The token decryption MUST return a valid DateTimeUntil, 266 DateTimeIssued and User Unique Id. If this is not returned, the 267 decryption MUST be considered to fail. 269 If all token formats and keys fail to decrypt, this MUST cause an 270 invalidCredentials error. 272 The DateTimeUntil field is checked against the servers current time. 273 If the current time exceeds or is equal to DateTimeUntil, 274 invalidCredentials MUST be returned. 276 The User Unique Id is validated to exist on the server. If the User 277 Unique Id does not exist, invalidCredentials MUST be returned. 279 The authid provided by the SASL client is verified with the User 280 Unique Id. For example if the authid is william@EXAMPLE.COM, the 281 server maps this to an identity. Once this identity is validated, 282 the identity is check to match the User Unique Id. If they do not 283 match, the authentication MUST fail. 285 The DateTimeIssued field is validated against the User Unique Id 286 object's attribute or related attribute that contains "Valid Not 287 Before". If the value of "Valid Not Before" exceeds or is equal to 288 DateTimeIssued, invalidCredentials MUST be returned. 290 Only if all of these steps have succeeded, then the authentication is 291 considered successful. 293 4.4. Valid Not Before Attribute 295 The management and details of the "Valid Not Before" attribute are 296 left to the implementation to decide how to implement and manage. 297 The implementation should consider how an administrator or 298 responsible party could revoke tokens for users other than their own. 299 The Valid Not Before SHOULD be replicated between LDAP servers to 300 allow correct revocation across many LDAP servers. For example, 301 Valid Not Before MAY be an attribute on the User Unique Id object, or 302 MAY be on another object with a unique relation to the User Unique 303 Id. 305 5. LDAP Component 307 5.1. Token Generation 309 An ldap extended operation is issued as per Section 4.12 of RFC 4511 310 [RFC4511]. 312 The LDAP OID to be used for the LDAPSSOTokenRequest is 313 2.16.840.1.113730.3.5.14. 315 The LDAP OID to be used for the LDAPSSOTokenResponse is 316 2.16.840.1.113730.3.5.15. 318 A User Unique Id is selected. This may be the Bind DN, UUID or other 319 utf8 identifier that uniquely determines an object. 321 The extended operation must fail if the LDAP connection security 322 stregth factors is 0. 324 Tokens must not be generated for Anonymous binds. This means, tokens 325 may only be generated for connections with a valid bind dn set. 327 Token requests MUST contain a requested lifetime in seconds. The 328 server MAY choose to ignore this lifetime and set it's own value. 330 A token request of a negative or zero value SHOULD default to a 331 server definied minimum lifetime. 333 The token is created as per an example token format in 4.1. This 334 value is then encrypted with an encryption algorithm of the servers 335 choosing. The client does not need to be aware of the encryption 336 algorithm. 338 The DateTimeIssued, DateTimeUntil and User Unique Id are collected in 339 the format required by the token format we are choosing to use in the 340 server. The token is then generated by the chosen algorithm. 342 The encrypted token is sent to the client in the LDAPSSOTokenResponse 343 structure, along with the servers chosen valid life time as a guide 344 for the client to approximate the expiry of the token. This valid 345 life time value is in seconds. 347 If the token cannot be generated due to a server error, 348 LDAP_OPERATION_ERROR MUST be returned. 350 5.1.1. Token Generation Extended Operation 352 LDAPSSOTokenRequest ::= SEQUENCE { 353 ValidLifeTime INTEGER } 355 LDAPSSOTokenResponse ::= SEQUENCE { 356 ValidLifeTime INTEGER, 357 EncryptedToken OCTET STRING 358 } 360 Figure 5 362 5.2. Token Revocation 364 An ldap extended operation is issued as per Section 4.12 RFC 4511 365 [RFC4511]. 367 The LDAP OID to be used for LDAPSSOTOKENRevokeRequest is 368 2.16.840.1.113730.3.5.16. 370 The extended operation MUST fail if the connection is anonymous. 372 The extended operation MUST fail if the LDAP connection security 373 strength factors is 0. 375 The extended operation MUST only act upon the "Valid Not Before" 376 attribute related to the bind DN of the connection. 378 Upon recieving the extended operation to revoke tokens, the directory 379 server MUST set the current BindDN's related "Valid Not Before" 380 attribute timestamp to the current datetime. This will have the 381 effect, that all previously issued tokens are invalidated. 383 This revocation option must work regardless of directory server 384 access controls on the attribute containing "Valid Not Before". 386 5.2.1. Token Revocation Extended Operation 388 The extended operation requestValue MUST not be set for LDAP SSO 389 Token revocation. 391 The extended operation does not provide a response OID. The result 392 is set in the LDAPResult. 394 5.3. Binding 396 The SASL bind attempt MUST fail if the LDAP connection security 397 strength factors is 0. 399 The SASL Authentication is attempted as per Section 4.3. If this 400 does not succeed, the bind attempt MUST fail. 402 The LDAP Object is retrived from the User Unique Id, and a Bind DN 403 Determined. If no Bind DN can be determined, the bind attempt MUST 404 fail. 406 The current Bind DN MUST be set to the Bind DN of the LDAP object 407 that is determined, and the result ldap success is returned to the 408 LDAP client. 410 6. Security Considerations 412 Due to the design of this token, it is possible to use it in a replay 413 attack. Notable threats are storage on the client and man in the 414 middle attacks. To minimise the man in the middle attack thread, 415 LDAP security strength factor of greater than 0 is a requirement. 416 Client security is not covered by this document. 418 7. Requirements 420 The SASL mechanism, LDAPSSOTOKEN, MUST be registered to IANA as per 421 RFC 2222 [RFC2222] Section 6.4 423 8. References 425 8.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 8.2. Informative References 434 [FERNETSPEC] 435 Maher, T. and K. Rarick, "Fernet Specification", 2013, 436 . 438 [RFC2078] Linn, J., "Generic Security Service Application Program 439 Interface, Version 2", RFC 2078, DOI 10.17487/RFC2078, 440 January 1997, . 442 [RFC2222] Myers, J., "Simple Authentication and Security Layer 443 (SASL)", RFC 2222, DOI 10.17487/RFC2222, October 1997, 444 . 446 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 447 Protocol (LDAP): The Protocol", RFC 4511, 448 DOI 10.17487/RFC4511, June 2006, 449 . 451 Authors' Addresses 453 William Brown 454 Red Hat Asia-Pacific Pty Ltd 455 Level 1, 193 North Quay 456 Brisbane, Queensland 4000 457 AU 459 Email: wibrown@redhat.com 461 Simo Sorce (editor) 462 Red Hat, Inc. 464 Email: simo@redhat.com 466 Kieran Andrews (editor) 467 The University of Adelaide 468 Adelaide, South Australia 5005 469 AU 471 Email: kieran.andrews@adelaide.edu.au