idnits 2.17.1 draft-vishwakarma-opsawg-ssh-cert-radius-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 15, 2020) is 1257 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC3986, mentioned in 'RFC3987', was also mentioned in 'RFC3986'. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 https://datatracker.ietf.org/submit/status/115698/cc21fb1021c60e49bc3970cd252f65a8/ 3 OPSAWG Devendra Vishwakarma 4 Internet-Draft Cisco Systems 5 Intended status: Informational Prakash Suthar 6 Expires: May 6, 2021 Google Inc. 7 Vivek Agarwal 8 Anil Jangam, Ed. 9 Cisco Systems 10 November 15, 2020 12 RADIUS Extension for Certificate-based SSH Authentication 13 draft-vishwakarma-opsawg-ssh-cert-radius-00 15 Abstract 17 A scalable and centralized mechanism is required for a certificate- 18 based administrative access to multitude of virtualized and physical 19 network functions. While there are mechanisms that exist today to 20 provide secure administrative command-line and API-based access, 21 there are certain management and maintenance overheads as well as 22 certain scalability challenges related to it. In this draft we 23 discuss these challenges and propose a standardized, centralized 24 server-based mechanism to authenticate a user over an SSH session 25 using its client certificate. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 6, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Centralized RADUIS Server based Solution . . . . . . . . 4 64 3. Operational Details . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Basic Setup . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. EAP TLS authentication . . . . . . . . . . . . . . . . . 5 67 3.3. RADIUS Access Request . . . . . . . . . . . . . . . . . . 6 68 3.4. Radius Accounting Request . . . . . . . . . . . . . . . . 7 69 3.5. Radius Access Accept . . . . . . . . . . . . . . . . . . 9 70 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2. Packet Types . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2.1. Access Request . . . . . . . . . . . . . . . . . . . 10 74 4.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.3.1. Service Type . . . . . . . . . . . . . . . . . . . . 11 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 9.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Conventions and Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 This document uses the terminology of [RFC3987] and [RFC3986] for 92 RADIUS entities. 94 2. Introduction 96 With the pervasive use of virtualized infrastructure (e.g., 97 microservices-based application designs), a high magnitude of 98 individual and autonomous software application components are working 99 together to realize a complete system functionality. With a large 100 number of highly interacting agents, an authentication and 101 authorization mechanism which is scalable and flexible is very 102 critical for administrative access. A typical service authentication 103 and authorization (AAA) infrastructure comprise of an identity 104 management, verification and, validations functions. 106 In a typical day of an IT (Information Technology) enabled 107 organization, IT engineers often connect to many different servers 108 while carrying their tasks such as, change of configurations, write a 109 software code, save a file, fetch an image, etc. There are mainly 110 three different ways engineers can authenticate to the servers they 111 are connecting to: 113 o Password based 115 o RSA key based 117 o OpenSSH certificate based local authentication 119 While these methods are currently being used, they suffer from the 120 following limitations respectively. 122 o Password based: In this method, user needs to enter the username 123 and password each time it tries to login to a server. With the 124 increasing frequency and number of servers, the manual 125 configuration becomes untenable. While script-based automation is 126 an option, it is highly insecure as passwords are stored in 127 cleartext. Also, a frequent password changes and adherence to 128 complex password policies are required to prevent against any 129 misuse. A 2-factor authentication mechanism provides some 130 protection but it still involves a certain level of human 131 interaction, which is difficult to automate. 133 o The RSA key-based authentication requires a frequent copy of files 134 to each device, server, cloud-native network function (CNF), and 135 virtual network functions (VNFs) and hence is not scalable. In 136 addition, if a key gets compromised, the revocation of it from all 137 servers and VNFs involves a lot of effort. 139 o OpenSSH certificate based local authentication requires root 140 certification authority (CA) certificate to be copied to each 141 individual device, server, and the VNF. If the developers are 142 using client certificate from multiple certification authorities, 143 all of the certification authority (CA) root certificate and 144 intermediate certificate has to be installed on each of the 145 servers that's being accessed. Also, a connectivity to the 146 certificate revocation list (CRL) is required from all the 147 devices, servers, and VNFs to check for revoked certificates. In 148 a typical customer environment all the device, servers, and VNFs 149 do not have access to a public CRL location. Also, any changes in 150 the certificates (e.g. expiry or revocation) requires a manual or 151 a script based cleanup of certificates from all the servers. 153 In order to address these limitations and move towards a password- 154 less mechanism, we propose an approach that uses certificate based 155 SSH authentication using RADIUS protocol. The centralized server- 156 based system also helps solve all the above outlined limitations. 158 2.1. Centralized RADUIS Server based Solution 160 As shown in Figure 1, a method is devised to authenticate SSH 161 sessions using client certificates, where the device, server, VNF, 162 and CNF uses RADIUS protocol to validate the authenticity of the 163 certificate from a centralized RADIUS server (e.g., Cisco Identity 164 Services Engine (ISE)). The RADIUS server will get the username from 165 the CN (common name) field in the client certificate. 167 The benefits of using certificates for SSH session authentication are 168 as follows: 170 o It does not require a frequent client certificate replacement 171 (e.g., a certificate is typically valid for a year), which solves 172 the problem seen in the password-based authentications. 174 o It does not require client public keys to be copied to each 175 device, server, VNF, or CNF that needs to be accessed. 177 o It doesn't need any secondary out-of-band authentication like OTP 178 or a complex MFA (Multi-factor Authentication) solution. 180 o All the root certificates and intermediate certificates needs to 181 be installed on the RADIUS server only. This makes it easy for 182 many administrative tasks including initial setup, adding a new 183 CA, retiring of an old CA, certificate revocation check, and the 184 centralized access to the internet to download the revocation 185 list. 187 o Both the certificate validation and revocation check happen at a 188 centralized AAA server. 190 +----+ +----+ 191 |VNF1| |VNF2| 192 +--+-+ +--+-+ 193 +-----------+ ;-----; | | +---------------+ 194 | | / \ +--+--------+-+ | Radius Server | 195 | Endpoint |--->( Network )--->| NFVI |--->| (AAA Server) | 196 | | \ / +-------------+ +-------+-------+ 197 +-----------+ `-----' | 198 | 199 +--------------------+ | 200 | Service Provider |<------------+ 201 | Cert Authority (CA)| 202 +--------------------+ 204 Figure 1: Centralized RADIUS-based AAA System 206 3. Operational Details 208 Operation is identical to that defined in [RFC2865], [RFC5216], and 209 [RFC4252]. 211 3.1. Basic Setup 213 The SSH client MUST support certificate-based authentication for the 214 SSH session. The SSH client MUST also have a X.509 client 215 certificate installed on the operating system. The client 216 certificate MUST have "client authentication" as value in the 217 enhanced key usage field of the certificate. This will ensure that 218 the client is ready to complete SSH authentication using the 219 installed X.509 client certificate. 221 The SSH server MUST be configured to send SSH authentication requests 222 to a RADIUS server. 224 The RADIUS server MUST have an X.509 server certificate installed on 225 the operating system. The server certificate MUST have ''server 226 authentication" as value in the enhanced key usage field of the 227 certificate. This will ensure that the RADIUS server is ready to 228 authenticate SSH clients using certificates. The RADIUS server MUST 229 also be configured to do EAP-TLS authentication as described in 230 [RFC3748]. 232 3.2. EAP TLS authentication 234 The SSH client will initiate an SSH connection to the SSH server. 235 The SSH server drives the authentication by telling the SSH client 236 which authentication methods can be used during the session. 238 The SSH client MUST choose a client certificate installed in the 239 operating system as described in the section 2.1 Basic Setup. If 240 there are multiple client certificates then the SSH client SHOULD 241 choose a client certificate. If there is no certificate installed on 242 the SSH client, then the client MAY choose another authentication 243 methods defined in [RFC4251]. 245 The SSH client initiates an SSH session to the SSH server. The SSH 246 server upon receiving the connection request MUST initiate the EAP- 247 TLS authentication by sending an EAP identity request to the SSH 248 client. 250 The SSH client picks the common name from the user certificate and 251 sends that as the EAP identity back to the SSH server. 253 3.3. RADIUS Access Request 255 The SSH server constructs a RADIUS authentication request and MUST 256 set the service type = Cert Login. This service type will be an 257 indication to the RADIUS server to use EAP-TLS authentication method 258 for that SSH session. 260 The RADIUS server MUST use EAP-TLS authentication for this session. 261 RADIUS server sends a response back to the SSH server as Radius 262 Access Challenge(EAP-Message(Code=Request TYPE=TLS EAP(EAP-TLS))) 264 The SSH server strips the EAP message from the RADIUS packet received 265 and forwards it to the SSH client. The message is (EAP- 266 Message(Code=Request TYPE=TLS EAP(EAP-TLS)). 268 The SSH client starts the TLS handshake by sending the EAP- 269 Message(TLS Client Hello) to the SSH server. The SSH server takes 270 the EAP message received in the previous step and wraps it in the 271 RADIUS access request and sends it to the RADIUS server. The message 272 is Radius Access Request(EAP-Message(TLS Client Hello)). 274 Upon receipt of this message the RADIUS server processes the client 275 hello message and sends a reply back to the SSH server with server 276 hello, server certificate, server key exchange and certificate 277 request. The message is Radius Access Challenge(EAP-Message(Server 278 Hello, Server Certificate, Server Key exchange, Certificate 279 Request). 281 The SSH server strips the EAP message from the RADIUS packet received 282 in the previous step and forwards it to the SSH client. The message 283 is EAP-Message(Server Hello, Server Certificate, Server Key exchange, 284 Certificate Request). The SSH client validates the server root 285 certificate installed. The SSH client moves ahead in the TLS 286 handshake process and sends the client certificate in a message to 287 the SSH server EAP-Message(TLS Client Certificate, TLS Client key 288 exchange, TLS Certificate Verify)). 290 The SSH server takes the EAP message received in the previous step 291 and wraps it in the RADIUS access request and sends it to the RADIUS 292 server. The message is Radius Access Request(EAP-Message(TLS Client 293 Certificate, TLS Client key exchange, TLS Certificate Verify)). 295 The RADIUS server validates the client certificate using the root CA 296 certificate chain. RADIUS server sends a TLS finished message to the 297 SSH server. The message is Radius Access Challenge(EAP-Message(TLS 298 Finished)). 300 The SSH server strips the EAP message from the RADIUS packet received 301 in the previous step and forwards it to the SSH client. The message 302 is EAP-Message(TLS Finished). The SSH client moves ahead in the EAP 303 phase and sends the next message. The message is EAP- 304 Message(TYPE=EAP-TLS)). 306 The SSH server takes the EAP message received in the previous step 307 and wraps it in the RADIUS access request and sends it to the RADIUS 308 server. The message is Radius Access Request(EAP-Message(TYPE=EAP- 309 TLS)). 311 RADIUS server processes the previous request and at this the EAP 312 authentication is successful. The message sent back to the SSH 313 server is Radius Accept(EAP-Message(EAP-Success)). The SSH server 314 strips the EAP message from the RADIUS packet received in the 315 previous step and forwards it to the SSH client. The message is EAP- 316 Message(EAP-Success). 318 The SSH session is established at this point. A message to this 319 effect is sent to the SSH client from the SSH server. 321 3.4. Radius Accounting Request 323 Endpoint VNF/CNF Radius Server 324 (SSH Client) (SSH/EAP Server) (AAA Server) 325 +---+------+ +--------+-----+ +-------+---+ 326 | | | 327 | SSH Request to VM | | 328 |-------------------------->| | 329 | | | 330 | EAP Identity Request | | 331 |<--------------------------| | 332 | | | 333 | EAP Identity Response | | 334 | (CN from User Cert) | | 335 |-------------------------->| | 336 | | Radius Access Request | 337 | | (ST: Cert Login) | 338 | | EAP Msg: Identity | 339 | | (ID: CN from User Cert) | 340 | |------------------------>| 341 | | | 342 | | Radius Access Challenge | 343 | | (EAP Message | 344 | | RT: TLS EAP(EAP-TLS) | 345 | (EAP Message |<------------------------| 346 | RT: TLS EAP(EAP-TLS) | | 347 |<--------------------------| | 348 | | | 349 | EAP Message | | 350 | (TLS Client Hello) | | 351 |-------------------------->| | 352 | | Radius Access Request | 353 | | EAP-Message: | 354 | | (TLS client hello) | 355 | |------------------------>| 356 | | | 357 | | Cert Login |--+ 358 | | supported | | 359 | | |<-+ 360 | | | 361 | | Radius Access Challenge | 362 | | (EAP Message: | 363 | | Server Hello, | 364 | (EAP Message: | Server Cert, | 365 | Server Hello, | Key Exchange, | 366 | Server Cert, | Cert Request) | 367 | Key Exchange, |<------------------------| 368 | Cert Request) | | 369 |<--------------------------| | 370 | | | 371 |--+ Server Cert | | 372 | | Validation | | 373 |<-+ | | 374 | | | 375 | EAP message | | 376 | (TLS Client Certificate | | 377 | TLS Client Key Xchange | | 378 | TLS Cert Verify) | Radius Access Request | 379 |-------------------------->| (EAP message | 380 | | (TLS Client Certificate | 381 | | (TLS Client Key Xchange | 382 | | TLS Cert Verify) | 383 | |-------------------------| 384 | | | 385 | | Client Cert |--+ 386 | | Validated | | 387 | | |<-+ 388 | | | 389 | | | 390 | | Radius Access Challenge | 391 | | (EAP Message: | 392 | | TLS Finished) | 393 | |<------------------------| 394 | TLS Finished) | | 395 |<--------------------------| | 396 | | | 397 | EAP Message | | 398 | (Type: EAP-TLS) | | 399 |-------------------------->| | 400 | | Radius Access Request | 401 | | EAP Msg(Type: EAP-TLS) | 402 | |------------------------>| 403 | | | 404 | | Radius Access Accept | 405 | | (EAP Message: | 406 | | EAP-Success) | 407 | |<------------------------| 408 | EAP Success | | 409 |<--------------------------| | 410 | | | 411 | Session Established | | 412 |<--------------------------| | 413 | | | 415 Legends: CN: Common Name ST: Service Type RT: Request Type 417 Figure 2: Radius Accounting Request Flow 419 3.5. Radius Access Accept 421 As shown in Figure 2, when the Radius server supports the new 422 service-type, it sends a Radius Access Accept message. In case where 423 server does not support the certificate-based login type, it responds 424 with Radius Access Reject response indicating the new login not 425 supported. The corresponding call flow is shown in Figure 3. 427 Endpoint VNF/CNF Radius Server 428 (SSH Client) (SSH/EAP Server) (AAA Server) 429 +---+------+ +--------+-----+ +-------+---+ 430 | | | 431 | SSH Request to VM | | 432 |-------------------------->| | 433 | | | 434 | EAP Identity Request | | 435 |<--------------------------| | 436 | | | 437 | EAP Identity Response | | 438 | (CN from User Cert) | | 439 |-------------------------->| | 440 | | Radius Access Request | 441 | | (ST: Cert Login) | 442 | | EAP Msg: Identity | 443 | | (ID: CN from User Cert) | 444 | |------------------------>| 445 | | | 446 | | Radius Access Reject | 447 | | (Login Not Supported*) | 448 | (EAP Failure |<------------------------| 449 | Cert login Not Supported) | | 450 |<--------------------------| | 451 | | | 453 Legends: CN: Common Name ST: Service Type RT: Request Type 455 Figure 3: AAA Server Does not Support Service Type 457 4. Protocol Details 459 Operation is identical to that defined in [RFC2865], [RFC5216], and 460 [RFC4252]. 462 4.1. Packet Format 464 4.2. Packet Types 466 The RADIUS Packet type is determined by the 'Code' field in the first 467 octet of the packet. 469 4.2.1. Access Request 471 The Access-Request packet type is same as defined in [RFC2865]. Here 472 is a summary of the Access-Request packet format as shown in 473 Figure 4. The fields are transmitted from left to right. 475 0 1 2 3 476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Code | Identifier | Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 | Request Authenticator | 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Attributes ... 485 +-+-+-+-+-+-+-+-+-+-+-+-+- 487 Figure 4: Access Request Packet Format 489 Within the same framework, this draft adds a new service-type 490 attribute value that will be sent in the Access-Request packet. 492 4.3. Attributes 494 4.3.1. Service Type 496 The 'Type' attribute value will have the same format as the service- 497 type field defined in [RFC2865] and is shown in Figure 5. The fields 498 are transmitted from left to right. 500 0 1 2 3 501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type | Length | Value | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Value (cont.) | 506 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 5: Service Type Encoding 510 Type 512 o 6 for Service-Type 514 Length 516 o 6 bytes 518 Value: the current types supported are as follows. 520 o Login 521 o Framed 523 o Callback Login 525 o Callback Framed 527 o Outbound 529 o Administrative 531 o NAS Prompt 533 o Authenticate Only 535 o Callback NAS Prompt 537 o Call Check 539 o Callback Administrative 541 This draft introduces a new service-type value as below. 543 o Cert Login 545 The Cert Login value shall be used by AAA Client in an Access-Request 546 packet to indicate to the RADIUS server that EAP-TLS authentication 547 needs to be used for this session. It is recommended that the 548 endpoint shall have a client certificate installed and ready to be 549 used during the authentication. 551 5. IANA Considerations 553 This section provides guidance to the Internet Assigned Numbers 554 Authority (IANA) regarding registration of values related to the 555 RADIUS protocol, in accordance with [RFC8126]. 557 A new attribute is proposed to be added to the RADIUS Radius Access 558 Request in the Service-Type Enum. 560 6. Security Considerations 562 The user certificate used by the clients must be stored in a non- 563 shared location of the operating system. This will ensure that the 564 users on the same system are not able to use each other certificates. 566 All the security considerations apply from the RFC 2865 as well. 568 7. Summary 570 A scalable, centralized, and standard-based method for management of 571 user login authentication is described. The proposal comprise of an 572 enhancement to the RADIUS protocol message and certain server side 573 enhancements shall be required to support the new functionality. 574 Once implemented, the enhanced server shall provide an improved user 575 experience involving a high frequency and a high scale of user 576 authentication across a range of interconnected agents (e.g. client 577 and servers). The enhancement provides an improved configuration and 578 management of the authentication infrastructure and reduces the 579 overhead related to deployment of root and intermediate certificates 580 at individual network nodes. This enhancement not only makes the 581 initial setup easier, but also revocation check easier due to the 582 centralized design. Addition and retirement of root and intermediate 583 certificates are among the most time saving aspects of the proposed 584 enhancement. 586 8. Acknowledgments 588 We are grateful for the input from IESG members and from a number of 589 individual members of the IETF community who share our concern for 590 doing the right thing. 592 9. References 594 9.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 602 "Remote Authentication Dial In User Service (RADIUS)", 603 RFC 2865, DOI 10.17487/RFC2865, June 2000, 604 . 606 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 607 Levkowetz, Ed., "Extensible Authentication Protocol 608 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 609 . 611 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 612 Resource Identifier (URI): Generic Syntax", January 2005, 613 . 615 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 616 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 617 January 2006, . 619 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 620 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 621 January 2006, . 623 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 624 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 625 March 2008, . 627 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 628 Writing an IANA Considerations Section in RFCs", BCP 26, 629 RFC 8126, DOI 10.17487/RFC8126, June 2017, 630 . 632 9.2. Informative References 634 [RFC3987] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 635 Resource Identifier (URI): Generic Syntax", January 2005, 636 . 638 Authors' Addresses 640 Devendra Vishwakarma 641 Cisco Systems 642 Apex, North Carolina 27523 643 USA 645 Email: dvishwak@cisco.com 647 Prakash Suthar 648 Google Inc. 649 Mountain View, California 94043 650 USA 652 Email: psuthar@google.com 654 Vivek Agarwal 655 Cisco Systems 656 Apex, North Carolina 27523 657 USA 659 Email: vivagarw@cisco.com 660 Anil Jangam (editor) 661 Cisco Systems 662 San Jose, California 95134 663 USA 665 Email: anjangam@cisco.com