idnits 2.17.1 draft-vishwakarma-opsawg-ssh-cert-radius-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 04, 2021) is 1055 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE-802' is mentioned on line 256, 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: December 6, 2021 Google Inc. 6 Vivek Agarwal 7 Anil Jangam, Ed. 8 Cisco Systems 9 June 04, 2021 11 RADIUS Extension for Certificate-based SSH Authentication 12 draft-vishwakarma-opsawg-ssh-cert-radius-01 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 December 6, 2021. 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Centralized RADUIS Server based Solution . . . . . . . . 4 63 3. Operational Details . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Basic Setup . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. EAP TLS authentication . . . . . . . . . . . . . . . . . 7 66 3.3. RADIUS Access Request . . . . . . . . . . . . . . . . . . 7 67 3.4. Radius Accounting Request . . . . . . . . . . . . . . . . 9 68 3.5. Radius Access Accept . . . . . . . . . . . . . . . . . . 11 69 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11 70 4.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2. Packet Types . . . . . . . . . . . . . . . . . . . . . . 12 72 4.2.1. Access Request . . . . . . . . . . . . . . . . . . . 12 73 4.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.3.1. Service Type . . . . . . . . . . . . . . . . . . . . 12 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 9.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Conventions and Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 This document uses the terminology of [RFC3987] and [RFC3986] for 91 RADIUS entities. 93 2. Introduction 95 With the pervasive use of virtualized infrastructure (e.g., 96 microservices-based application designs), a high magnitude of 97 individual and autonomous software application components are working 98 together to realize a complete system functionality. With a large 99 number of highly interacting agents, an authentication and 100 authorization mechanism which is scalable and flexible is very 101 critical for administrative access. A typical service authentication 102 and authorization (AAA) infrastructure comprise of an identity 103 management, verification and, validations functions. 105 In a typical day of an IT (Information Technology) enabled 106 organization, IT engineers often connect to many different servers 107 while carrying their tasks such as, change of configurations, write a 108 software code, save a file, fetch an image, etc. There are mainly 109 three different ways engineers can authenticate to the servers they 110 are connecting to. 112 o Password based 114 o RSA key based 116 o OpenSSH certificate based local authentication 118 While these methods are currently being used, they suffer from the 119 following limitations respectively. 121 o Password based: In this method, user needs to enter the username 122 and password each time it tries to login to a server. With the 123 increasing frequency and number of servers, the manual 124 configuration becomes untenable. While script-based automation is 125 an option, it is highly insecure as passwords are stored in 126 cleartext. Also, a frequent password changes and adherence to 127 complex password policies are required to prevent against any 128 misuse. A 2-factor authentication mechanism provides some 129 protection but it still involves a certain level of human 130 interaction, which is difficult to automate. 132 o The RSA key-based authentication requires a frequent copy of files 133 to each device, server, cloud-native network function (CNF), and 134 virtual network functions (VNFs) and hence is not scalable. In 135 addition, if a key gets compromised, the revocation of it from all 136 servers and VNFs involves a lot of effort. 138 o OpenSSH certificate based local authentication requires root 139 certification authority (CA) certificate to be copied to each 140 individual device, server, and the VNF. If the developers are 141 using client certificate from multiple certification authorities, 142 all of the certification authority (CA) root certificate and 143 intermediate certificate has to be installed on each of the 144 servers that's being accessed. Also, a connectivity to the 145 certificate revocation list (CRL) is required from all the 146 devices, servers, and VNFs to check for revoked certificates. In 147 a typical customer environment all the device, servers, and VNFs 148 do not have access to a public CRL location. Also, any changes in 149 the certificates (e.g. expiry or revocation) requires a manual or 150 a script based cleanup of certificates from all the servers. 152 In order to address these limitations and move towards a password- 153 less mechanism, we propose an approach that uses certificate based 154 SSH authentication using RADIUS protocol. The centralized server- 155 based system also helps solve all the above outlined limitations. 157 2.1. Centralized RADUIS Server based Solution 159 As shown in Figure 1, a method is devised to authenticate SSH 160 sessions using client certificates, where the device, server, VNF, 161 and CNF uses RADIUS protocol to validate the authenticity of the 162 certificate from a centralized RADIUS server. The RADIUS server will 163 get the username from the CN (common name) field in the client 164 certificate. 166 The benefits of using certificates for SSH session authentication are 167 as follows: 169 o It does not require a frequent client certificate replacement 170 (e.g., a certificate is typically valid for a year), which solves 171 the problem seen in the password-based authentications. 173 o It does not require client public keys to be copied to each 174 device, server, VNF, or CNF that needs to be accessed. 176 o It doesn't need any secondary out-of-band authentication like OTP 177 or a complex MFA (Multi-factor Authentication) solution. 179 o All the root certificates and intermediate certificates needs to 180 be installed on the RADIUS server only. This makes it easy for 181 many administrative tasks including initial setup, adding a new 182 CA, retiring of an old CA, certificate revocation check, and the 183 centralized access to the internet to download the revocation 184 list. 186 o Both the certificate validation and revocation check happen at a 187 centralized AAA server. 189 +----+ +----+ 190 |VNF1| |VNF2| 191 +--+-+ +--+-+ 192 +-----------+ ;-----; | | +---------------+ 193 | | / \ +--+--------+-+ | Radius Server | 194 | Endpoint |--->( Network )--->| NFVI |--->| (AAA Server) | 195 | | \ / +-------------+ +-------+-------+ 196 +-----------+ `-----' | 197 | 198 +--------------------+ | 199 | Service Provider |<------------+ 200 | Cert Authority (CA)| 201 +--------------------+ 203 Figure 1: Centralized RADIUS-based AAA System 205 3. Operational Details 207 Operation is identical to that defined in [RFC2865], [RFC5216], and 208 [RFC4252]. 210 3.1. Basic Setup 212 Analogous to 802.1X authentication where there is an EAP Supplicant 213 (also known as EAP peer), pass-through authenticator, and a RADIUS 214 server. This solution has an SSH client that is similar to EAP 215 supplicant, an SSH server similar to pass-through authenticator, and 216 a RADIUS server. The SSH transport protocol defined in RFC 4253 MUST 217 be used as the lower layer of the EAP. The SSH transport protocol 218 satisfies all the requirements of the EAP lower layer defined in the 219 section 3.1 of the RFC 3748. 221 o Unreliable transport: Even though the EAP assumes that the lower 222 layer can be a unreliable transport and has retransmission built 223 into EAP itself. The SSH transport protocol is a reliable 224 transport protocol and handles its own retransmission when used 225 over TCP/IP. RFC 793 section 3.7 has the details of data 226 communication and retransmission behavior of TCP. 228 o Lower layer error detection: Error detection must be provided by 229 the EAP lower layer and SSH TP does that using the sequence 230 numbers in the TCP packets. This is detailed in the section 3.3 231 of the RFC 793. 233 o Lower layer security: EAP does not require lower layers to provide 234 security services, however SSH TP over TCP provides for 236 o Data integrity: as detailed in section 6.4 of RFC 4253 and section 237 9.3.2 of RFC 4251 239 o Replay protection: as detailed in section 9.3.3 of RFC 4251 241 o Authentication: as detailed in section 9.4 of RFC 4251 243 o Confidentiality: as detailed in section 6.3 of RFC 4253 and 244 section 9.3.1 246 o Minimum MTU: EAP requires the lower layer to support 1020 bytes or 247 higher MTU. SSH TP satisfies this requirement. In a typical TCP/ 248 IP network the MTU is by default set to 1500 bytes which satisfies 249 the requirement for EAP. 251 o Possible duplication: while it is desirable that lower layers 252 provide for non-duplication, this is not a requirement. 254 o Ordering guarantees: Lower layer transports for EAP MUST preserve 255 ordering between a source and destination at a given priority 256 level (the ordering guarantee provided by [IEEE-802]). SSH TP 257 when used over TCP/IP guarantees ordered delivery of data from 258 source to destination. Section 2.6 of RFC 793 details the use of 259 sequence numbers in TCP. 261 The SSH client MUST support certificate-based authentication for the 262 SSH session. The SSH client MUST also have a X.509 client 263 certificate installed on the operating system. The client 264 certificate MUST have "client authentication" as value in the 265 enhanced key usage field of the certificate. This will ensure that 266 the client is ready to complete SSH authentication using the 267 installed X.509 client certificate. 269 The SSH server MUST be configured to send SSH authentication requests 270 to a RADIUS server. 272 The RADIUS server MUST have an X.509 server certificate installed on 273 the operating system. The server certificate MUST have ''server 274 authentication" as value in the enhanced key usage field of the 275 certificate. This will ensure that the RADIUS server is ready to 276 authenticate SSH clients using certificates. The RADIUS server MUST 277 also be configured to do EAP-TLS authentication as described in 278 [RFC3748]. 280 3.2. EAP TLS authentication 282 Although other inner methods of EAP could be supported for 283 authentication here such as EAP-MSCHAP, EAP-MD5 or EAP-FAST etc, 284 however they do not provide much benefit over the current password 285 based authentication that exist. This draft only focuses on the EAP- 286 TLS inner method as that gives the ability to allow certificate based 287 authentication. 289 The SSH client will initiate an SSH connection to the SSH server. 290 The SSH server drives the authentication by telling the SSH client 291 which authentication methods can be used during the session. 293 The SSH client MUST choose a client certificate installed in the 294 operating system as described in the section 2.1 Basic Setup. If 295 there are multiple client certificates then the SSH client SHOULD 296 choose a client certificate. If there is no certificate installed on 297 the SSH client, then the client MAY choose another authentication 298 methods defined in [RFC4251]. 300 The SSH client initiates an SSH session to the SSH server. The SSH 301 server upon receiving the connection request MUST initiate the EAP- 302 TLS authentication by sending an EAP identity request to the SSH 303 client. 305 The SSH client picks the common name from the user certificate and 306 sends that as the EAP identity back to the SSH server. 308 3.3. RADIUS Access Request 310 The SSH server constructs a RADIUS authentication request and MUST 311 set the service type = Cert Login. This service type will be an 312 indication to the RADIUS server to use EAP-TLS authentication method 313 for that SSH session. 315 The RADIUS server MUST use EAP-TLS authentication for this session. 316 RADIUS server sends a response back to the SSH server as Radius 317 Access Challenge(EAP-Message(Code=Request TYPE=TLS EAP(EAP-TLS))) 319 The SSH server strips the EAP message from the RADIUS packet received 320 and forwards it to the SSH client. The message is (EAP- 321 Message(Code=Request TYPE=TLS EAP(EAP-TLS)). 323 The SSH client starts the TLS handshake by sending the EAP- 324 Message(TLS Client Hello) to the SSH server. The SSH server takes 325 the EAP message received in the previous step and wraps it in the 326 RADIUS access request and sends it to the RADIUS server. The message 327 is Radius Access Request(EAP-Message(TLS Client Hello)). 329 Upon receipt of this message the RADIUS server processes the client 330 hello message and sends a reply back to the SSH server with server 331 hello, server certificate, server key exchange and certificate 332 request. The message is Radius Access Challenge(EAP-Message(Server 333 Hello, Server Certificate, Server Key exchange, Certificate 334 Request). 336 The SSH server strips the EAP message from the RADIUS packet received 337 in the previous step and forwards it to the SSH client. The message 338 is EAP-Message(Server Hello, Server Certificate, Server Key exchange, 339 Certificate Request). The SSH client validates the server root 340 certificate installed. The SSH client moves ahead in the TLS 341 handshake process and sends the client certificate in a message to 342 the SSH server EAP-Message(TLS Client Certificate, TLS Client key 343 exchange, TLS Certificate Verify)). 345 The SSH server takes the EAP message received in the previous step 346 and wraps it in the RADIUS access request and sends it to the RADIUS 347 server. The message is Radius Access Request(EAP-Message(TLS Client 348 Certificate, TLS Client key exchange, TLS Certificate Verify)). 350 The RADIUS server validates the client certificate using the root CA 351 certificate chain. RADIUS server sends a TLS finished message to the 352 SSH server. The message is Radius Access Challenge(EAP-Message(TLS 353 Finished)). 355 The SSH server strips the EAP message from the RADIUS packet received 356 in the previous step and forwards it to the SSH client. The message 357 is EAP-Message(TLS Finished). The SSH client moves ahead in the EAP 358 phase and sends the next message. The message is EAP- 359 Message(TYPE=EAP-TLS)). 361 The SSH server takes the EAP message received in the previous step 362 and wraps it in the RADIUS access request and sends it to the RADIUS 363 server. The message is Radius Access Request(EAP-Message(TYPE=EAP- 364 TLS)). 366 RADIUS server processes the previous request and at this the EAP 367 authentication is successful. The message sent back to the SSH 368 server is Radius Accept(EAP-Message(EAP-Success)). The SSH server 369 strips the EAP message from the RADIUS packet received in the 370 previous step and forwards it to the SSH client. The message is EAP- 371 Message(EAP-Success). 373 The SSH session is established at this point. A message to this 374 effect is sent to the SSH client from the SSH server. 376 3.4. Radius Accounting Request 378 Endpoint VNF/CNF Radius Server 379 (SSH Client) (SSH/EAP Server) (AAA Server) 380 +---+------+ +--------+-----+ +-------+---+ 381 | | | 382 | SSH Request to VM | | 383 |-------------------------->| | 384 | | | 385 | EAP Identity Request | | 386 |<--------------------------| | 387 | | | 388 | EAP Identity Response | | 389 | (CN from User Cert) | | 390 |-------------------------->| | 391 | | Radius Access Request | 392 | | (ST: Cert Login) | 393 | | EAP Msg: Identity | 394 | | (ID: CN from User Cert) | 395 | |------------------------>| 396 | | | 397 | | Radius Access Challenge | 398 | | (EAP Message | 399 | | RT: TLS EAP(EAP-TLS) | 400 | (EAP Message |<------------------------| 401 | RT: TLS EAP(EAP-TLS) | | 402 |<--------------------------| | 403 | | | 404 | EAP Message | | 405 | (TLS Client Hello) | | 406 |-------------------------->| | 407 | | Radius Access Request | 408 | | EAP-Message: | 409 | | (TLS client hello) | 410 | |------------------------>| 411 | | | 412 | | Cert Login |--+ 413 | | supported | | 414 | | |<-+ 415 | | | 416 | | Radius Access Challenge | 417 | | (EAP Message: | 418 | | Server Hello, | 419 | (EAP Message: | Server Cert, | 420 | Server Hello, | Key Exchange, | 421 | Server Cert, | Cert Request) | 422 | Key Exchange, |<------------------------| 423 | Cert Request) | | 424 |<--------------------------| | 425 | | | 426 |--+ Server Cert | | 427 | | Validation | | 428 |<-+ | | 429 | | | 430 | EAP message | | 431 | (TLS Client Certificate | | 432 | TLS Client Key Xchange | | 433 | TLS Cert Verify) | Radius Access Request | 434 |-------------------------->| (EAP message | 435 | | (TLS Client Certificate | 436 | | (TLS Client Key Xchange | 437 | | TLS Cert Verify) | 438 | |-------------------------| 439 | | | 440 | | Client Cert |--+ 441 | | Validated | | 442 | | |<-+ 443 | | | 444 | | | 445 | | Radius Access Challenge | 446 | | (EAP Message: | 447 | | TLS Finished) | 448 | |<------------------------| 449 | TLS Finished) | | 450 |<--------------------------| | 451 | | | 452 | EAP Message | | 453 | (Type: EAP-TLS) | | 454 |-------------------------->| | 455 | | Radius Access Request | 456 | | EAP Msg(Type: EAP-TLS) | 457 | |------------------------>| 458 | | | 459 | | Radius Access Accept | 460 | | (EAP Message: | 461 | | EAP-Success) | 462 | |<------------------------| 463 | EAP Success | | 464 |<--------------------------| | 465 | | | 466 | Session Established | | 467 |<--------------------------| | 468 | | | 470 Legends: CN: Common Name ST: Service Type RT: Request Type 471 Figure 2: Radius Accounting Request Flow 473 3.5. Radius Access Accept 475 As shown in Figure 2, when the Radius server supports the new 476 service-type, it sends a Radius Access Accept message. In case where 477 server does not support the certificate-based login type, it responds 478 with Radius Access Reject response indicating the new login not 479 supported. The corresponding call flow is shown in Figure 3. 481 Endpoint VNF/CNF Radius Server 482 (SSH Client) (SSH/EAP Server) (AAA Server) 483 +---+------+ +--------+-----+ +-------+---+ 484 | | | 485 | SSH Request to VM | | 486 |-------------------------->| | 487 | | | 488 | EAP Identity Request | | 489 |<--------------------------| | 490 | | | 491 | EAP Identity Response | | 492 | (CN from User Cert) | | 493 |-------------------------->| | 494 | | Radius Access Request | 495 | | (ST: Cert Login) | 496 | | EAP Msg: Identity | 497 | | (ID: CN from User Cert) | 498 | |------------------------>| 499 | | | 500 | | Radius Access Reject | 501 | | (Login Not Supported*) | 502 | (EAP Failure |<------------------------| 503 | Cert login Not Supported) | | 504 |<--------------------------| | 505 | | | 507 Legends: CN: Common Name ST: Service Type RT: Request Type 509 Figure 3: AAA Server Does not Support Service Type 511 4. Protocol Details 513 Operation is identical to that defined in [RFC2865], [RFC5216], and 514 [RFC4252]. 516 4.1. Packet Format 518 4.2. Packet Types 520 The RADIUS Packet type is determined by the 'Code' field in the first 521 octet of the packet. 523 4.2.1. Access Request 525 The Access-Request packet type is same as defined in [RFC2865]. Here 526 is a summary of the Access-Request packet format as shown in 527 Figure 4. The fields are transmitted from left to right. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Code | Identifier | Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | | 535 | Request Authenticator | 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Attributes ... 539 +-+-+-+-+-+-+-+-+-+-+-+-+- 541 Figure 4: Access Request Packet Format 543 Within the same framework, this draft adds a new service-type 544 attribute value that will be sent in the Access-Request packet. 546 4.3. Attributes 548 4.3.1. Service Type 550 The 'Type' attribute value will have the same format as the service- 551 type field defined in [RFC2865] and is shown in Figure 5. The fields 552 are transmitted from left to right. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type | Length | Value | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Value (cont.) | 560 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 5: Service Type Encoding 564 Type 566 o 6 for Service-Type 568 Length 570 o 6 bytes 572 Value: the current types supported are as follows. 574 o Login 576 o Framed 578 o Callback Login 580 o Callback Framed 582 o Outbound 584 o Administrative 586 o NAS Prompt 588 o Authenticate Only 590 o Callback NAS Prompt 592 o Call Check 594 o Callback Administrative 596 This draft introduces a new service-type value as below. 598 o Cert Login 599 The Cert Login value shall be used by AAA Client in an Access-Request 600 packet to indicate to the RADIUS server that EAP-TLS authentication 601 needs to be used for this session. It is recommended that the 602 endpoint shall have a client certificate installed and ready to be 603 used during the authentication. 605 5. IANA Considerations 607 This section provides guidance to the Internet Assigned Numbers 608 Authority (IANA) regarding registration of values related to the 609 RADIUS protocol, in accordance with [RFC8126]. 611 A new attribute is proposed to be added to the RADIUS Radius Access 612 Request in the Service-Type Enum. 614 6. Security Considerations 616 The user certificate used by the clients must be stored in a non- 617 shared location of the operating system. This will ensure that the 618 users on the same system are not able to use each other certificates. 620 All the security considerations apply from the RFC 2865 as well. 622 7. Summary 624 A scalable, centralized, and standard-based method for management of 625 user login authentication is described. The proposal comprise of an 626 enhancement to the RADIUS protocol message and certain server side 627 enhancements shall be required to support the new functionality. 628 Once implemented, the enhanced server shall provide an improved user 629 experience involving a high frequency and a high scale of user 630 authentication across a range of interconnected agents (e.g. client 631 and servers). The enhancement provides an improved configuration and 632 management of the authentication infrastructure and reduces the 633 overhead related to deployment of root and intermediate certificates 634 at individual network nodes. This enhancement not only makes the 635 initial setup easier, but also revocation check easier due to the 636 centralized design. Addition and retirement of root and intermediate 637 certificates are among the most time saving aspects of the proposed 638 enhancement. 640 8. Acknowledgments 642 We are grateful for the input from IESG members and from a number of 643 individual members of the IETF community who share our concern for 644 doing the right thing. 646 9. References 648 9.1. Normative References 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, 652 DOI 10.17487/RFC2119, March 1997, 653 . 655 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 656 "Remote Authentication Dial In User Service (RADIUS)", 657 RFC 2865, DOI 10.17487/RFC2865, June 2000, 658 . 660 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 661 Levkowetz, Ed., "Extensible Authentication Protocol 662 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 663 . 665 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 666 Resource Identifier (URI): Generic Syntax", January 2005, 667 . 669 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 670 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 671 January 2006, . 673 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 674 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 675 January 2006, . 677 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 678 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 679 March 2008, . 681 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 682 Writing an IANA Considerations Section in RFCs", BCP 26, 683 RFC 8126, DOI 10.17487/RFC8126, June 2017, 684 . 686 9.2. Informative References 688 [RFC3987] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 689 Resource Identifier (URI): Generic Syntax", January 2005, 690 . 692 Authors' Addresses 694 Devendra Vishwakarma 695 Cisco Systems 696 Apex, North Carolina 27523 697 USA 699 Email: dvishwak@cisco.com 701 Prakash Suthar 702 Google Inc. 703 Mountain View, California 94043 704 USA 706 Email: psuthar@google.com 708 Vivek Agarwal 709 Cisco Systems 710 Apex, North Carolina 27523 711 USA 713 Email: vivagarw@cisco.com 715 Anil Jangam (editor) 716 Cisco Systems 717 San Jose, California 95134 718 USA 720 Email: anjangam@cisco.com