idnits 2.17.1 draft-ietf-secsh-auth-kbdinteract-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 514. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 129 has weird spacing: '... string use...' == Line 130 has weird spacing: '... string ser...' == Line 132 has weird spacing: '... string lan...' == Line 133 has weird spacing: '... string sub...' == Line 204 has weird spacing: '... string nam...' == (8 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 21, 2005) is 6970 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) -- Looks like a reference, but probably isn't: '1' on line 300 == Unused Reference: 'SSH-CONNECT' is defined on line 472, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Cusack 2 INTERNET-DRAFT Google, Inc. 3 Expires September 21, 2005 M. Forssen 4 Appgate AB 5 March 21, 2005 7 Generic Message Exchange Authentication For SSH 8 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 . 32 The list of Internet-Draft Shadow Directories can be accessed at 33 . 35 This Internet-Draft will expire on September 21, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 SSH is a protocol for secure remote login and other secure network 44 services over an insecure network. This document describes a general 45 purpose authentication method for the SSH protocol, suitable for 46 interactive authentications where the authentication data should be 47 entered via a keyboard (or equivalent alphanumeric input device). 48 The major goal of this method is to allow the SSH client to support a 49 whole class of authentication mechanism(s) without knowing the 50 specifics of the actual authentication mechanism(s). 52 1. Introduction 54 The SSH authentication protocol [SSH-USERAUTH] is a general-purpose 55 user authentication protocol. It is intended to be run over the SSH 56 transport layer protocol [SSH-TRANS]. The authentication protocol 57 assumes that the underlying protocols provide integrity and 58 confidentiality protection. 60 This document describes a general purpose authentication method for 61 the SSH authentication protocol. This method is suitable for 62 interactive authentication methods which do not need any special 63 software support on the client side. Instead all authentication data 64 should be entered via the keyboard. The major goal of this method is 65 to allow the SSH client to have little or no knowledge of the 66 specifics of the underlying authentication mechanism(s) used by the 67 SSH server. This will allow the server to arbitrarily select or 68 change the underlying authentication mechanism(s) without having to 69 update client code. 71 The name for this authentication method is "keyboard-interactive". 73 This document should be read only after reading the SSH architecture 74 document [SSH-ARCH] and the SSH authentication document 75 [SSH-USERAUTH]. This document freely uses terminology and notation 76 from both documents without reference or further explanation. 78 This document also describes some of the client interaction with the 79 user in obtaining the authentication information. While this is 80 somewhat out of the scope of a protocol specification, it is 81 described here anyway since some aspects of the protocol are 82 specifically designed based on user interface issues, and omitting 83 this information may lead to incompatible or awkward implementations. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC-2119]. 89 2. Rationale 91 Currently defined authentication methods for SSH are tightly coupled 92 with the underlying authentication mechanism. This makes it 93 difficult to add new mechanisms for authentication as all clients 94 must be updated to support the new mechanism. With the generic 95 method defined here, clients will not require code changes to support 96 new authentication mechanisms, and if a separate authentication layer 97 is used, such as [PAM], then the server may not need any code changes 98 either. 100 This presents a significant advantage to other methods, such as the 101 "password" method (defined in [SSH-USERAUTH]), as new (presumably 102 stronger) methods may be added "at will" and system security can be 103 transparently enhanced. 105 Challenge-response and One Time Password mechanisms are also easily 106 supported with this authentication method. 108 This authentication method is however limited to authentication 109 mechanisms which do not require any special code, such as hardware 110 drivers or password mangling, on the client. 112 3. Protocol Exchanges 114 The client initiates the authentication with a 115 SSH_MSG_USERAUTH_REQUEST message. The server then requests 116 authentication information from the client with a 117 SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the 118 information from the user and then responds with a 119 SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send 120 another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the 121 answer from the client. 123 3.1 Initial Exchange 125 The authentication starts with the client sending the following 126 packet: 128 byte SSH_MSG_USERAUTH_REQUEST 129 string user name (ISO-10646 UTF-8, as defined in [RFC-3629]) 130 string service name (US-ASCII) 131 string "keyboard-interactive" (US-ASCII) 132 string language tag (as defined in [RFC-3066]) 133 string submethods (ISO-10646 UTF-8) 135 The language tag is deprecated and SHOULD be the empty string. It 136 may be removed in a future revision of this specification. The 137 server SHOULD instead select the language used based on the tags 138 communicated during key exchange [SSH-TRANS]. 140 If the language tag is not the empty string, the server SHOULD use 141 the specified language for any messages sent to the client as part of 142 this protocol. The language tag SHOULD NOT be used for language 143 selection for messages outside of this protocol. The language to be 144 used if the server does not support the requested language is 145 implementation-dependent. 147 The submethods field is included so the user can give a hint of which 148 actual methods he wants to use. It is a comma-separated list of 149 authentication submethods (software or hardware) which the user 150 prefers. If the client has knowledge of the submethods preferred by 151 the user, presumably through a configuration setting, it MAY use the 152 submethods field to pass this information to the server. Otherwise 153 it MUST send the empty string. 155 The actual names of the submethods is something which the user and 156 the server need to agree upon. 158 Server interpretation of the submethods field is implementation- 159 dependent. 161 One possible implementation strategy of the submethods field on the 162 server is that, unless the user may use multiple different 163 submethods, the server ignores this field. If the user may 164 authenticate using one of several different submethods the server 165 should treat the submethods field as a hint on which submethod the 166 user wants to use this time. 168 Note that when this message is sent to the server, the client has not 169 yet prompted the user for a password, and so that information is NOT 170 included with this initial message (unlike the "password" method). 172 The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS, 173 SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. 175 The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message 176 if the failure is based on the user name or service name; instead it 177 SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just 178 like the one(s) which would have been sent in cases where 179 authentication should proceed, and then send the failure message 180 (after a suitable delay, as described below). The goal is to make it 181 impossible to find valid usernames by just comparing the results when 182 authenticating as different users. 184 The server MAY reply with a SSH_MSG_USERAUTH_SUCCESS message if no 185 authentication is required for the user in question, however a better 186 approach, for reasons discussed above, might be to reply with a 187 SSH_MSG_USERAUTH_INFO_REQUEST message and ignore (don't validate) the 188 response. 190 3.2 Information Requests 192 Requests are generated from the server using the 193 SSH_MSG_USERAUTH_INFO_REQUEST message. 195 The server may send as many requests as are necessary to authenticate 196 the client; the client MUST be prepared to handle multiple exchanges. 197 However the server MUST NOT ever have more than one 198 SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may 199 not send another request before the client has answered. 201 The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: 203 byte SSH_MSG_USERAUTH_INFO_REQUEST 204 string name (ISO-10646 UTF-8) 205 string instruction (ISO-10646 UTF-8) 206 string language tag (as defined in [RFC-3066]) 207 int num-prompts 208 string prompt[1] (ISO-10646 UTF-8) 209 boolean echo[1] 210 ... 211 string prompt[num-prompts] (ISO-10646 UTF-8) 212 boolean echo[num-prompts] 214 The language tag is deprecated and SHOULD be the empty string. It 215 may be removed in a future revision of this specification. The 216 server SHOULD instead select the language used based on the tags 217 communicated during key exchange [SSH-TRANS]. 219 If the language tag is not the empty string, the server SHOULD use 220 the specified language for any messages sent to the client as part of 221 this protocol. The language tag SHOULD NOT be used for language 222 selection for messages outside of this protocol. The language to be 223 used if the server does not support the requested language is 224 implementation-dependent. 226 The server SHOULD take into consideration that some clients may not 227 be able to properly display a long name or prompt field (see next 228 section), and limit the lengths of those fields if possible. For 229 example, instead of an instruction field of "Enter Password" and a 230 prompt field of "Password for user23@host.domain: ", a better choice 231 might be an instruction field of 232 "Password authentication for user23@host.domain" and a prompt field 233 of "Password: ". It is expected that this authentication method 234 would typically be backended by [PAM] and so such choices would not 235 be possible. 237 The name and instruction fields MAY be empty strings, the client MUST 238 be prepared to handle this correctly. The prompt field(s) MUST NOT 239 be empty strings. 241 The num-prompts field may be `0', in which case there will be no 242 prompt/echo fields in the message, but the client SHOULD still 243 display the name and instruction fields (as described below). 245 3.3 User Interface 247 Upon receiving a request message, the client SHOULD prompt the user 248 as follows: 250 A command line interface (CLI) client SHOULD print the name and 251 instruction (if non-empty), adding newlines. Then for each prompt in 252 turn, the client SHOULD display the prompt and read the user input. 254 A graphical user interface (GUI) client has many choices on how to 255 prompt the user. One possibility is to use the name field (possibly 256 prefixed with the application's name) as the title of a dialog window 257 in which the prompt(s) are presented. In that dialog window, the 258 instruction field would be a text message, and the prompts would be 259 labels for text entry fields. All fields SHOULD be presented to the 260 user, for example an implementation SHOULD NOT discard the name field 261 because its windows lack titles; it SHOULD instead find another way 262 to display this information. If prompts are presented in a dialog 263 window, then the client SHOULD NOT present each prompt in a separate 264 window. 266 All clients MUST properly handle an instruction field with embedded 267 newlines. They SHOULD also be able to display at least 30 characters 268 for the name and prompts. If the server presents names or prompts 269 longer than 30 characters, the client MAY truncate these fields to 270 the length it can display. If the client does truncate any fields, 271 there MUST be an obvious indication that such truncation has 272 occurred. The instruction field SHOULD NOT be truncated. 274 Clients SHOULD use control character filtering as discussed in 275 [SSH-ARCH] to avoid attacks by including terminal control characters 276 in the fields to be displayed. 278 For each prompt, the corresponding echo field indicates whether or 279 not the user input should be echoed as characters are typed. Clients 280 SHOULD correctly echo/mask user input for each prompt independently 281 of other prompts in the request message. If a client does not honor 282 the echo field for whatever reason, then the client MUST err on the 283 side of masking input. A GUI client might like to have a checkbox 284 toggling echo/mask. Clients SHOULD NOT add any additional characters 285 to the prompt such as ": " (colon-space); the server is responsible 286 for supplying all text to be displayed to the user. Clients MUST 287 also accept empty responses from the user and pass them on as empty 288 strings. 290 3.4 Information Responses 292 After obtaining the requested information from the user, the client 293 MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message. 295 The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as 296 follows: 298 byte SSH_MSG_USERAUTH_INFO_RESPONSE 299 int num-responses 300 string response[1] (ISO-10646 UTF-8) 301 ... 302 string response[num-responses] (ISO-10646 UTF-8) 304 Note that the responses are encoded in ISO-10646 UTF-8. It is up to 305 the server how it interprets the responses and validates them. 306 However, if the client reads the responses in some other encoding 307 (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 308 before transmitting. 310 From an internationalization standpoint, it is desired that if a user 311 enters responses the authentication process will work regardless of 312 what OS and client software they are using. Doing so requires 313 normalization. Systems supporting non-ASCII passwords SHOULD always 314 normalize passwords and usernames whenever they are added to the 315 database, or compared (with or without hashing) to existing entries 316 in the database. SSH implementations that both store the passwords 317 and compare them SHOULD use [SASLPREP] for normalization. 319 If the num-responses field does not match the num-prompts field in 320 the request message, the server MUST send a failure message. 322 In the case that the server sends a `0' num-prompts field in the 323 request message, the client MUST send a response message with a `0' 324 num-responses field to complete the exchange. 326 The responses MUST be ordered as the prompts were ordered. That is, 327 response[n] MUST be the answer to prompt[n]. 329 After receiving the response, the server MUST send either a 330 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 331 SSH_MSG_USERAUTH_INFO_REQUEST message. 333 If the server fails to authenticate the user (through the underlying 334 authentication mechanism(s)), it SHOULD NOT send another request 335 message(s) in an attempt to obtain new authentication data, instead 336 it SHOULD send a failure message. The only time the server should 337 send multiple request messages is if additional authentication data 338 is needed (i.e., because there are multiple underlying authentication 339 mechanisms that must be used to authenticate the user). 341 If the server intends to respond with a failure message, it MAY delay 342 for an implementation-dependent time before sending to the client. 343 It is suspected that implementations are likely to make the time 344 delay configurable; a suggested default is 2 seconds. 346 4. Authentication Examples 348 Here are two example exchanges between a client and server. The 349 first is an example of challenge/response with a handheld token. 350 This is an authentication that is not otherwise possible with other 351 authentication methods. 353 C: byte SSH_MSG_USERAUTH_REQUEST 354 C: string "user23" 355 C: string "ssh-userauth" 356 C: string "keyboard-interactive" 357 C: string "" 358 C: string "" 360 S: byte SSH_MSG_USERAUTH_INFO_REQUEST 361 S: string "CRYPTOCard Authentication" 362 S: string "The challenge is '14315716'" 363 S: string "en-US" 364 S: int 1 365 S: string "Response: " 366 S: boolean TRUE 368 [Client prompts user for password] 370 C: byte SSH_MSG_USERAUTH_INFO_RESPONSE 371 C: int 1 372 C: string "6d757575" 374 S: byte SSH_MSG_USERAUTH_SUCCESS 376 The second example is of a standard password authentication, in 377 this case the user's password is expired. 379 C: byte SSH_MSG_USERAUTH_REQUEST 380 C: string "user23" 381 C: string "ssh-userauth" 382 C: string "keyboard-interactive" 383 C: string "en-US" 384 C: string "" 385 S: byte SSH_MSG_USERAUTH_INFO_REQUEST 386 S: string "Password Authentication" 387 S: string "" 388 S: string "en-US" 389 S: int 1 390 S: string "Password: " 391 S: boolean FALSE 393 [Client prompts user for password] 395 C: byte SSH_MSG_USERAUTH_INFO_RESPONSE 396 C: int 1 397 C: string "password" 399 S: byte SSH_MSG_USERAUTH_INFO_REQUEST 400 S: string "Password Expired" 401 S: string "Your password has expired." 402 S: string "en-US" 403 S: int 2 404 S: string "Enter new password: " 405 S: boolean FALSE 406 S: string "Enter it again: " 407 S: boolean FALSE 409 [Client prompts user for new password] 411 C: byte SSH_MSG_USERAUTH_INFO_RESPONSE 412 C: int 2 413 C: string "newpass" 414 C: string "newpass" 416 S: byte SSH_MSG_USERAUTH_INFO_REQUEST 417 S: string "Password changed" 418 S: string "Password successfully changed for user23." 419 S: string "en-US" 420 S: int 0 422 [Client displays message to user] 424 C: byte SSH_MSG_USERAUTH_INFO_RESPONSE 425 C: int 0 427 S: byte SSH_MSG_USERAUTH_SUCCESS 429 5. IANA Considerations 431 The userauth type "keyboard-interactive" is used for this 432 authentication method. 434 The following method-specific constants are used with this 435 authentication method: 437 SSH_MSG_USERAUTH_INFO_REQUEST 60 438 SSH_MSG_USERAUTH_INFO_RESPONSE 61 440 6. Security Considerations 442 The authentication protocol, and this authentication method, depend 443 on the security of the underlying SSH transport layer. Without the 444 confidentiality provided therein, any authentication data passed with 445 this method is subject to interception. 447 The number of client-server exchanges required to complete an 448 authentication using this method may be variable. It is possible 449 that an observer may gain valuable information simply by counting 450 that number. For example, an observer may guess that a user's 451 password has expired, and with further observation may be able to 452 determine the password lifetime imposed by a site's password 453 expiration policy. 455 7. References 457 7.1 Normative References 459 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Level", BCP 14, RFC 2119, March 1997. 462 [RFC-3629] Yergeau, F., "UTF-8, a transformation format of 463 Unicode and ISO 10646", RFC 3629, November 2003. 465 [RFC-3066] Alvestrand, H., "Tags for the Identification of 466 Languages", BCP 47, RFC 3066, January 2001. 468 [SSH-ARCH] Lonvick, C., "SSH Protocol Architecture", work in 469 progress, draft-ietf-secsh-architecture-22.txt, March 470 2005. 472 [SSH-CONNECT] Lonvick, C., "SSH Connection Protocol", work in 473 progress, draft-ietf-secsh-connect-25.txt, March 474 2005. 476 [SSH-TRANS] Lonvick, C., "SSH Transport Layer Protocol", work in 477 progress, draft-ietf-secsh-transport-24.txt, March 478 2005. 480 [SSH-USERAUTH] Lonvick, C., "SSH Authentication Protocol", work in 481 progress, draft-ietf-secsh-userauth-27.txt, March 482 2005. 484 [SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user 485 names and passwords", work in progress, 486 draft-ietf-sasl-saslprep-10, July 2004. 488 7.2 Informative References 490 [PAM] Samar, V., Schemers, R., "Unified Login With 491 Pluggable Authentication Modules (PAM)", OSF RFC 492 86.0, October 1995 494 8. Authors' Addresses 496 Frank Cusack 497 Google, Inc. 498 1600 Amphitheatre Parkway 499 Mountain View, CA 94043 500 Email: frank@google.com 502 Martin Forssen 503 Appgate AB 504 Stora Badhusgatan 18-20 505 SE-411 21 Gothenburg 506 SWEDEN 507 Email: maf@appgate.com 509 9. Intellectual Property and Copyright Statements 511 9.1 IPR Disclosure Acknowlegement 512 By submitting this Internet-Draft, I certify that any applicable patent 513 or other IPR claims of which I am aware have been disclosed, and any of 514 which I become aware will be disclosed, in accordance with RFC 3668. 516 9.2 Full Copyright Statement 517 Copyright (C) The Internet Society (2005). This document is subject to 518 the rights, licenses and restrictions contained in BCP 78 and except as 519 set forth therein, the authors retain all their rights. 521 This document and the information contained herein are provided on an "AS 522 IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 523 SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 524 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 525 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 526 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 527 FITNESS FOR A PARTICULAR PURPOSE. 529 Intellectual Property 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed 533 to pertain to the implementation or use of the technology described 534 in this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has made 536 any independent effort to identify any such rights. Information on the 537 procedures with respect to rights in RFC documents can be found in BCP 538 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any assurances 541 of licenses to be made available, or the result of an attempt made to 542 obtain a general license or permission for the use of such proprietary 543 rights by implementers or users of this specification can be obtained 544 from the IETF on-line IPR repository at . 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary rights 548 that may cover technology that may be required to implement this standard. 549 Please address the information to the IETF at . 551 The IETF has been notified of intellectual property rights claimed in 552 regard to some or all of the specification contained in this 553 document. For more information consult the online list of claimed 554 rights. 556 Acknowledgement 558 Funding for the RFC Editor function is currently provided by the 559 Internet Society.