idnits 2.17.1 draft-vishwakarma-opsawg-ssh-cert-radius-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 December 2021) is 850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE-802' is mentioned on line 255, but not defined -- Duplicate reference: RFC3986, mentioned in 'RFC3987', was also mentioned in 'RFC3986'. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG WG Devendra Vishwakarma 3 Internet-Draft Cisco Systems 4 Intended status: Informational Prakash Suthar 5 Expires: 1 July 2022 Google Inc. 6 Vivek Agarwal 7 Anil Jangam, Ed. 8 Cisco Systems 9 28 December 2021 11 RADIUS Extension for Certificate-based SSH Authentication 12 draft-vishwakarma-opsawg-ssh-cert-radius-02 14 Abstract 16 A scalable and centralized mechanism is required for a certificate- 17 based administrative access to multitude of virtualized and physical 18 network functions. While there are mechanisms that exist today to 19 provide secure administrative command-line and API-based access, 20 there are certain management and maintenance overheads as well as 21 certain scalability challenges related to it. In this draft we 22 discuss these challenges and propose a standardized, centralized 23 server-based mechanism to authenticate a user over an SSH session 24 using its client certificate. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 1 July 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Centralized RADUIS Server based Solution . . . . . . . . 4 62 3. Operational Details . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Basic Setup . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. EAP TLS authentication . . . . . . . . . . . . . . . . . 7 65 3.3. RADIUS Access Request . . . . . . . . . . . . . . . . . . 7 66 3.4. Radius Accounting Request . . . . . . . . . . . . . . . . 9 67 3.5. Radius Access Accept . . . . . . . . . . . . . . . . . . 11 68 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11 69 4.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 11 70 4.2. Packet Types . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2.1. Access Request . . . . . . . . . . . . . . . . . . . 12 72 4.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.3.1. Service Type . . . . . . . . . . . . . . . . . . . . 12 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 9.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Conventions and Terminology 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 [RFC2119]. 89 This document uses the terminology of [RFC3987] and [RFC3986] for 90 RADIUS entities. 92 2. Introduction 94 With the pervasive use of virtualized infrastructure (e.g., 95 microservices-based application designs), a high magnitude of 96 individual and autonomous software application components are working 97 together to realize a complete system functionality. With a large 98 number of highly interacting agents, an authentication and 99 authorization mechanism which is scalable and flexible is very 100 critical for administrative access. A typical service authentication 101 and authorization (AAA) infrastructure comprise of an identity 102 management, verification and, validations functions. 104 In a typical day of an IT (Information Technology) enabled 105 organization, IT engineers often connect to many different servers 106 while carrying their tasks such as, change of configurations, write a 107 software code, save a file, fetch an image, etc. There are mainly 108 three different ways engineers can authenticate to the servers they 109 are connecting to. 111 * Password based 113 * RSA key based 115 * OpenSSH certificate based local authentication 117 While these methods are currently being used, they suffer from the 118 following limitations respectively. 120 * Password based: In this method, user needs to enter the username 121 and password each time it tries to login to a server. With the 122 increasing frequency and number of servers, the manual 123 configuration becomes untenable. While script-based automation is 124 an option, it is highly insecure as passwords are stored in 125 cleartext. Also, a frequent password changes and adherence to 126 complex password policies are required to prevent against any 127 misuse. A 2-factor authentication mechanism provides some 128 protection but it still involves a certain level of human 129 interaction, which is difficult to automate. 131 * The RSA key-based authentication requires a frequent copy of files 132 to each device, server, cloud-native network function (CNF), and 133 virtual network functions (VNFs) and hence is not scalable. In 134 addition, if a key gets compromised, the revocation of it from all 135 servers and VNFs involves a lot of effort. 137 * OpenSSH certificate based local authentication requires root 138 certification authority (CA) certificate to be copied to each 139 individual device, server, and the VNF. If the developers are 140 using client certificate from multiple certification authorities, 141 all of the certification authority (CA) root certificate and 142 intermediate certificate has to be installed on each of the 143 servers that's being accessed. Also, a connectivity to the 144 certificate revocation list (CRL) is required from all the 145 devices, servers, and VNFs to check for revoked certificates. In 146 a typical customer environment all the device, servers, and VNFs 147 do not have access to a public CRL location. Also, any changes in 148 the certificates (e.g. expiry or revocation) requires a manual or 149 a script based cleanup of certificates from all the servers. 151 In order to address these limitations and move towards a password- 152 less mechanism, we propose an approach that uses certificate based 153 SSH authentication using RADIUS protocol. The centralized server- 154 based system also helps solve all the above outlined limitations. 156 2.1. Centralized RADUIS Server based Solution 158 As shown in Figure 1, a method is devised to authenticate SSH 159 sessions using client certificates, where the device, server, VNF, 160 and CNF uses RADIUS protocol to validate the authenticity of the 161 certificate from a centralized RADIUS server. The RADIUS server will 162 get the username from the CN (common name) field in the client 163 certificate. 165 The benefits of using certificates for SSH session authentication are 166 as follows: 168 * It does not require a frequent client certificate replacement 169 (e.g., a certificate is typically valid for a year), which solves 170 the problem seen in the password-based authentications. 172 * It does not require client public keys to be copied to each 173 device, server, VNF, or CNF that needs to be accessed. 175 * It doesn't need any secondary out-of-band authentication like OTP 176 or a complex MFA (Multi-factor Authentication) solution. 178 * All the root certificates and intermediate certificates needs to 179 be installed on the RADIUS server only. This makes it easy for 180 many administrative tasks including initial setup, adding a new 181 CA, retiring of an old CA, certificate revocation check, and the 182 centralized access to the internet to download the revocation 183 list. 185 * Both the certificate validation and revocation check happen at a 186 centralized AAA server. 188 +----+ +----+ 189 |VNF1| |VNF2| 190 +--+-+ +--+-+ 191 +-----------+ ;-----; | | +---------------+ 192 | | / \ +--+--------+-+ | Radius Server | 193 | Endpoint |--->( Network )--->| NFVI |--->| (AAA Server) | 194 | | \ / +-------------+ +-------+-------+ 195 +-----------+ `-----' | 196 | 197 +--------------------+ | 198 | Service Provider |<------------+ 199 | Cert Authority (CA)| 200 +--------------------+ 202 Figure 1: Centralized RADIUS-based AAA System 204 3. Operational Details 206 Operation is identical to that defined in [RFC2865], [RFC5216], and 207 [RFC4252]. 209 3.1. Basic Setup 211 Analogous to 802.1X authentication where there is an EAP Supplicant 212 (also known as EAP peer), pass-through authenticator, and a RADIUS 213 server. This solution has an SSH client that is similar to EAP 214 supplicant, an SSH server similar to pass-through authenticator, and 215 a RADIUS server. The SSH transport protocol defined in RFC 4253 MUST 216 be used as the lower layer of the EAP. The SSH transport protocol 217 satisfies all the requirements of the EAP lower layer defined in the 218 section 3.1 of the RFC 3748. 220 * Unreliable transport: Even though the EAP assumes that the lower 221 layer can be a unreliable transport and has retransmission built 222 into EAP itself. The SSH transport protocol is a reliable 223 transport protocol and handles its own retransmission when used 224 over TCP/IP. RFC 793 section 3.7 has the details of data 225 communication and retransmission behavior of TCP. 227 * Lower layer error detection: Error detection must be provided by 228 the EAP lower layer and SSH TP does that using the sequence 229 numbers in the TCP packets. This is detailed in the section 3.3 230 of the RFC 793. 232 * Lower layer security: EAP does not require lower layers to provide 233 security services, however SSH TP over TCP provides for 235 * Data integrity: as detailed in section 6.4 of RFC 4253 and section 236 9.3.2 of RFC 4251 238 * Replay protection: as detailed in section 9.3.3 of RFC 4251 240 * Authentication: as detailed in section 9.4 of RFC 4251 242 * Confidentiality: as detailed in section 6.3 of RFC 4253 and 243 section 9.3.1 245 * Minimum MTU: EAP requires the lower layer to support 1020 bytes or 246 higher MTU. SSH TP satisfies this requirement. In a typical TCP/ 247 IP network the MTU is by default set to 1500 bytes which satisfies 248 the requirement for EAP. 250 * Possible duplication: while it is desirable that lower layers 251 provide for non-duplication, this is not a requirement. 253 * Ordering guarantees: Lower layer transports for EAP MUST preserve 254 ordering between a source and destination at a given priority 255 level (the ordering guarantee provided by [IEEE-802]). SSH TP 256 when used over TCP/IP guarantees ordered delivery of data from 257 source to destination. Section 2.6 of RFC 793 details the use of 258 sequence numbers in TCP. 260 The SSH client MUST support certificate-based authentication for the 261 SSH session. The SSH client MUST also have a X.509 client 262 certificate installed on the operating system. The client 263 certificate MUST have "client authentication" as value in the 264 enhanced key usage field of the certificate. This will ensure that 265 the client is ready to complete SSH authentication using the 266 installed X.509 client certificate. 268 The SSH server MUST be configured to send SSH authentication requests 269 to a RADIUS server. 271 The RADIUS server MUST have an X.509 server certificate installed on 272 the operating system. The server certificate MUST have ''server 273 authentication" as value in the enhanced key usage field of the 274 certificate. This will ensure that the RADIUS server is ready to 275 authenticate SSH clients using certificates. The RADIUS server MUST 276 also be configured to do EAP-TLS authentication as described in 277 [RFC3748]. 279 3.2. EAP TLS authentication 281 Although other inner methods of EAP could be supported for 282 authentication here such as EAP-MSCHAP, EAP-MD5 or EAP-FAST etc, 283 however they do not provide much benefit over the current password 284 based authentication that exist. This draft only focuses on the EAP- 285 TLS inner method as that gives the ability to allow certificate based 286 authentication. 288 The SSH client will initiate an SSH connection to the SSH server. 289 The SSH server drives the authentication by telling the SSH client 290 which authentication methods can be used during the session. 292 The SSH client MUST choose a client certificate installed in the 293 operating system as described in the section 2.1 Basic Setup. If 294 there are multiple client certificates then the SSH client SHOULD 295 choose a client certificate. If there is no certificate installed on 296 the SSH client, then the client MAY choose another authentication 297 methods defined in [RFC4251]. 299 The SSH client initiates an SSH session to the SSH server. The SSH 300 server upon receiving the connection request MUST initiate the EAP- 301 TLS authentication by sending an EAP identity request to the SSH 302 client. 304 The SSH client picks the common name from the user certificate and 305 sends that as the EAP identity back to the SSH server. 307 3.3. RADIUS Access Request 309 The SSH server constructs a RADIUS authentication request and MUST 310 set the service type = Cert Login. This service type will be an 311 indication to the RADIUS server to use EAP-TLS authentication method 312 for that SSH session. 314 The RADIUS server MUST use EAP-TLS authentication for this session. 315 RADIUS server sends a response back to the SSH server as Radius 316 Access Challenge(EAP-Message(Code=Request TYPE=TLS EAP(EAP-TLS))) 318 The SSH server strips the EAP message from the RADIUS packet received 319 and forwards it to the SSH client. The message is (EAP- 320 Message(Code=Request TYPE=TLS EAP(EAP-TLS)). 322 The SSH client starts the TLS handshake by sending the EAP- 323 Message(TLS Client Hello) to the SSH server. The SSH server takes 324 the EAP message received in the previous step and wraps it in the 325 RADIUS access request and sends it to the RADIUS server. The message 326 is Radius Access Request(EAP-Message(TLS Client Hello)). 328 Upon receipt of this message the RADIUS server processes the client 329 hello message and sends a reply back to the SSH server with server 330 hello, server certificate, server key exchange and certificate 331 request. The message is Radius Access Challenge(EAP-Message(Server 332 Hello, Server Certificate, Server Key exchange, Certificate 333 Request). 335 The SSH server strips the EAP message from the RADIUS packet received 336 in the previous step and forwards it to the SSH client. The message 337 is EAP-Message(Server Hello, Server Certificate, Server Key exchange, 338 Certificate Request). The SSH client validates the server root 339 certificate installed. The SSH client moves ahead in the TLS 340 handshake process and sends the client certificate in a message to 341 the SSH server EAP-Message(TLS Client Certificate, TLS Client key 342 exchange, TLS Certificate Verify)). 344 The SSH server takes the EAP message received in the previous step 345 and wraps it in the RADIUS access request and sends it to the RADIUS 346 server. The message is Radius Access Request(EAP-Message(TLS Client 347 Certificate, TLS Client key exchange, TLS Certificate Verify)). 349 The RADIUS server validates the client certificate using the root CA 350 certificate chain. RADIUS server sends a TLS finished message to the 351 SSH server. The message is Radius Access Challenge(EAP-Message(TLS 352 Finished)). 354 The SSH server strips the EAP message from the RADIUS packet received 355 in the previous step and forwards it to the SSH client. The message 356 is EAP-Message(TLS Finished). The SSH client moves ahead in the EAP 357 phase and sends the next message. The message is EAP- 358 Message(TYPE=EAP-TLS)). 360 The SSH server takes the EAP message received in the previous step 361 and wraps it in the RADIUS access request and sends it to the RADIUS 362 server. The message is Radius Access Request(EAP-Message(TYPE=EAP- 363 TLS)). 365 RADIUS server processes the previous request and at this the EAP 366 authentication is successful. The message sent back to the SSH 367 server is Radius Accept(EAP-Message(EAP-Success)). The SSH server 368 strips the EAP message from the RADIUS packet received in the 369 previous step and forwards it to the SSH client. The message is EAP- 370 Message(EAP-Success). 372 The SSH session is established at this point. A message to this 373 effect is sent to the SSH client from the SSH server. 375 3.4. Radius Accounting Request 377 Endpoint VNF/CNF Radius Server 378 (SSH Client) (SSH/EAP Server) (AAA Server) 379 +---+------+ +--------+-----+ +-------+---+ 380 | | | 381 | SSH Request to VM | | 382 |-------------------------->| | 383 | | | 384 | EAP Identity Request | | 385 |<--------------------------| | 386 | | | 387 | EAP Identity Response | | 388 | (CN from User Cert) | | 389 |-------------------------->| | 390 | | Radius Access Request | 391 | | (ST: Cert Login) | 392 | | EAP Msg: Identity | 393 | | (ID: CN from User Cert) | 394 | |------------------------>| 395 | | | 396 | | Radius Access Challenge | 397 | | (EAP Message | 398 | | RT: TLS EAP(EAP-TLS) | 399 | (EAP Message |<------------------------| 400 | RT: TLS EAP(EAP-TLS) | | 401 |<--------------------------| | 402 | | | 403 | EAP Message | | 404 | (TLS Client Hello) | | 405 |-------------------------->| | 406 | | Radius Access Request | 407 | | EAP-Message: | 408 | | (TLS client hello) | 409 | |------------------------>| 410 | | | 411 | | Cert Login |--+ 412 | | supported | | 413 | | |<-+ 414 | | | 415 | | Radius Access Challenge | 416 | | (EAP Message: | 417 | | Server Hello, | 418 | (EAP Message: | Server Cert, | 419 | Server Hello, | Key Exchange, | 420 | Server Cert, | Cert Request) | 421 | Key Exchange, |<------------------------| 422 | Cert Request) | | 423 |<--------------------------| | 424 | | | 425 |--+ Server Cert | | 426 | | Validation | | 427 |<-+ | | 428 | | | 429 | EAP message | | 430 | (TLS Client Certificate | | 431 | TLS Client Key Xchange | | 432 | TLS Cert Verify) | Radius Access Request | 433 |-------------------------->| (EAP message | 434 | | (TLS Client Certificate | 435 | | (TLS Client Key Xchange | 436 | | TLS Cert Verify) | 437 | |-------------------------| 438 | | | 439 | | Client Cert |--+ 440 | | Validated | | 441 | | |<-+ 442 | | | 443 | | | 444 | | Radius Access Challenge | 445 | | (EAP Message: | 446 | | TLS Finished) | 447 | |<------------------------| 448 | TLS Finished) | | 449 |<--------------------------| | 450 | | | 451 | EAP Message | | 452 | (Type: EAP-TLS) | | 453 |-------------------------->| | 454 | | Radius Access Request | 455 | | EAP Msg(Type: EAP-TLS) | 456 | |------------------------>| 457 | | | 458 | | Radius Access Accept | 459 | | (EAP Message: | 460 | | EAP-Success) | 461 | |<------------------------| 462 | EAP Success | | 463 |<--------------------------| | 464 | | | 465 | Session Established | | 466 |<--------------------------| | 467 | | | 469 Legends: CN: Common Name ST: Service Type RT: Request Type 470 Figure 2: Radius Accounting Request Flow 472 3.5. Radius Access Accept 474 As shown in Figure 2, when the Radius server supports the new 475 service-type, it sends a Radius Access Accept message. In case where 476 server does not support the certificate-based login type, it responds 477 with Radius Access Reject response indicating the new login not 478 supported. The corresponding call flow is shown in Figure 3. 480 Endpoint VNF/CNF Radius Server 481 (SSH Client) (SSH/EAP Server) (AAA Server) 482 +---+------+ +--------+-----+ +-------+---+ 483 | | | 484 | SSH Request to VM | | 485 |-------------------------->| | 486 | | | 487 | EAP Identity Request | | 488 |<--------------------------| | 489 | | | 490 | EAP Identity Response | | 491 | (CN from User Cert) | | 492 |-------------------------->| | 493 | | Radius Access Request | 494 | | (ST: Cert Login) | 495 | | EAP Msg: Identity | 496 | | (ID: CN from User Cert) | 497 | |------------------------>| 498 | | | 499 | | Radius Access Reject | 500 | | (Login Not Supported*) | 501 | (EAP Failure |<------------------------| 502 | Cert login Not Supported) | | 503 |<--------------------------| | 504 | | | 506 Legends: CN: Common Name ST: Service Type RT: Request Type 508 Figure 3: AAA Server Does not Support Service Type 510 4. Protocol Details 512 Operation is identical to that defined in [RFC2865], [RFC5216], and 513 [RFC4252]. 515 4.1. Packet Format 516 4.2. Packet Types 518 The RADIUS Packet type is determined by the 'Code' field in the first 519 octet of the packet. 521 4.2.1. Access Request 523 The Access-Request packet type is same as defined in [RFC2865]. Here 524 is a summary of the Access-Request packet format as shown in 525 Figure 4. The fields are transmitted from left to right. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Code | Identifier | Length | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | | 533 | Request Authenticator | 534 | | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Attributes ... 537 +-+-+-+-+-+-+-+-+-+-+-+-+- 539 Figure 4: Access Request Packet Format 541 Within the same framework, this draft adds a new service-type 542 attribute value that will be sent in the Access-Request packet. 544 4.3. Attributes 546 4.3.1. Service Type 548 The 'Type' attribute value will have the same format as the service- 549 type field defined in [RFC2865] and is shown in Figure 5. The fields 550 are transmitted from left to right. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Type | Length | Value | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Value (cont.) | 558 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 5: Service Type Encoding 562 Type 564 * 6 for Service-Type 566 Length 568 * 6 bytes 570 Value: the current types supported are as follows. 572 * Login 574 * Framed 576 * Callback Login 578 * Callback Framed 580 * Outbound 582 * Administrative 584 * NAS Prompt 586 * Authenticate Only 588 * Callback NAS Prompt 590 * Call Check 592 * Callback Administrative 594 This draft introduces a new service-type value as below. 596 * Cert Login 598 The Cert Login value shall be used by AAA Client in an Access-Request 599 packet to indicate to the RADIUS server that EAP-TLS authentication 600 needs to be used for this session. It is recommended that the 601 endpoint shall have a client certificate installed and ready to be 602 used during the authentication. 604 5. IANA Considerations 606 This section provides guidance to the Internet Assigned Numbers 607 Authority (IANA) regarding registration of values related to the 608 RADIUS protocol, in accordance with [RFC8126]. 610 A new attribute is proposed to be added to the RADIUS Radius Access 611 Request in the Service-Type Enum. 613 6. Security Considerations 615 The user certificate used by the clients must be stored in a non- 616 shared location of the operating system. This will ensure that the 617 users on the same system are not able to use each other certificates. 619 All the security considerations apply from the RFC 2865 as well. 621 7. Summary 623 A scalable, centralized, and standard-based method for management of 624 user login authentication is described. The proposal comprise of an 625 enhancement to the RADIUS protocol message and certain server side 626 enhancements shall be required to support the new functionality. 627 Once implemented, the enhanced server shall provide an improved user 628 experience involving a high frequency and a high scale of user 629 authentication across a range of interconnected agents (e.g. client 630 and servers). The enhancement provides an improved configuration and 631 management of the authentication infrastructure and reduces the 632 overhead related to deployment of root and intermediate certificates 633 at individual network nodes. This enhancement not only makes the 634 initial setup easier, but also revocation check easier due to the 635 centralized design. Addition and retirement of root and intermediate 636 certificates are among the most time saving aspects of the proposed 637 enhancement. 639 8. Acknowledgments 641 We are grateful for the input from IESG members and from a number of 642 individual members of the IETF community who share our concern for 643 doing the right thing. 645 9. References 647 9.1. Normative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, 651 DOI 10.17487/RFC2119, March 1997, 652 . 654 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 655 "Remote Authentication Dial In User Service (RADIUS)", 656 RFC 2865, DOI 10.17487/RFC2865, June 2000, 657 . 659 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 660 Levkowetz, Ed., "Extensible Authentication Protocol 661 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 662 . 664 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 665 Resource Identifier (URI): Generic Syntax", January 2005, 666 . 668 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 669 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 670 January 2006, . 672 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 673 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 674 January 2006, . 676 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 677 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 678 March 2008, . 680 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 681 Writing an IANA Considerations Section in RFCs", BCP 26, 682 RFC 8126, DOI 10.17487/RFC8126, June 2017, 683 . 685 9.2. Informative References 687 [RFC3987] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 688 Resource Identifier (URI): Generic Syntax", January 2005, 689 . 691 Authors' Addresses 693 Devendra Vishwakarma 694 Cisco Systems 695 Apex, North Carolina 27523 696 United States of America 698 Email: dvishwak@cisco.com 700 Prakash Suthar 701 Google Inc. 702 Mountain View, California 94043 703 United States of America 705 Email: psuthar@google.com 706 Vivek Agarwal 707 Cisco Systems 708 Apex, North Carolina 27523 709 United States of America 711 Email: vivagarw@cisco.com 713 Anil Jangam (editor) 714 Cisco Systems 715 San Jose, California 95134 716 United States of America 718 Email: anjangam@cisco.com