search

haussli / draft-dahm-opsawg-tacacs-tls13

IETF draft for tacacs+ TLS 1.3 support
1 stars 0 forks source link

Minor changes + break out operators section. #6

Closed dcmgashcisco closed 1 year ago

dcmgashcisco commented 1 year ago

Sorry for the poor diff, its probably better to put the files into a graphical differ:

80,82c80,82 < 2.2. Peer . . . . . . . . . . . . . . . . . . . . . . . . . . 3 < 2.3. TLS Connection . . . . . . . . . . . . . . . . . . . . . 3 < 2.4. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 3

 2.2.  TLS Connection  . . . . . . . . . . . . . . . . . . . . .   3
 2.3.  Peer  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.4.  Obfuscation . . . . . . . . . . . . . . . . . . . . . . .   4

85c85 < 3.2. TLS Connection . . . . . . . . . . . . . . . . . . . . . 4

 3.2.  TLS Connection  . . . . . . . . . . . . . . . . . . . . .   5

91,99c91,99 < 5.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 < 5.1.1. TLS Use . . . . . . . . . . . . . . . . . . . . . . . 7 < 5.1.2. TLS 0-RTT . . . . . . . . . . . . . . . . . . . . . . 7 < 5.1.3. TLS PSK . . . . . . . . . . . . . . . . . . . . . . . 8 < 5.1.4. TLS Options . . . . . . . . . . . . . . . . . . . . . 8 < 5.1.5. Unreachable Certificate Authority (CA) . . . . . . . 8 < 5.1.6. TLS Server Name Indicator (SNI) . . . . . . . . . . . 8 < 5.2. Well-Known TCP/IP Port . . . . . . . . . . . . . . . . . 8 < 6. Operator Considerations . . . . . . . . . . . . . . . . . . . 9

 5.1.  TLS Options . . . . . . . . . . . . . . . . . . . . . . .   7
 5.2.  TLS 0-RTT . . . . . . . . . . . . . . . . . . . . . . . .   8
 5.3.  TLS PSK . . . . . . . . . . . . . . . . . . . . . . . . .   8

  1. Operator Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. TLS Use . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Migration to TLS . . . . . . . . . . . . . . . . . . . . 8 6.3. Downgrade attacks in TLS . . . . . . . . . . . . . . . . 9 6.4. Unreachable Certificate Authority (CA) . . . . . . . . . 9 6.5. TLS Server Name Indicator (SNI) . . . . . . . . . . . . . 9 101,103c101,104 < 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 < 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 < 10. Informative References . . . . . . . . . . . . . . . . . . . 11

  2. Discussion on Separate port vs Negotiated TLS . . . . . . . . 9
  3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
  4. Normative References . . . . . . . . . . . . . . . . . . . . 10
  5. Informative References . . . . . . . . . . . . . . . . . . . 11 110a112 Dahm, et al. Expires 7 December 2023 [Page 2] 112,113d113 < Dahm, et al. Expires 6 December 2023 [Page 2] <

139,140c139,140 < is fully applicable here and will not be repeated, though might be < augmented. The following terms are also used in this document.

is fully applicable here and will not be repeated. The following terms are also used in this document. 149,151c149 < 2.2. Peer < < This refers to a TACACS+ Server or Client.

2.2. TLS Connection 153,154d150 < 2.3. TLS Connection < 156,157c152,154 < encryption used by TACACS+ for transport, similar to a Connection as < defined in TACACS+ Protocol [RFC8907].

encryption used by TACACS+ for transport. The TLS Connection for TACACS+ is always between one Client and one Server as defined in TACACS+ Protocol [RFC8907]. 159c156 < 2.4. Obfuscation

2.3. Peer 161,163c158,160 < Inferior form of encryption used in TACACS+, referred to as < obfuscation in [RFC5425], Section 5.2 to indicate that it is not < encryption and is utterly insufficient.

In the context of a TLS Connection, the peer of a TACACS+ Client is the Server, and the peer is the TACACS+ Server is the Client. Together, the ends of a TLS Connection are referred as the peers. 168d164 < Dahm, et al. Expires 6 December 2023 [Page 3] 169a166,169

Dahm, et al. Expires 7 December 2023 [Page 3]

172a173,178

2.4. Obfuscation

Inferior form of encryption used in TACACS+, referred to as obfuscation in [RFC5425], Section 5.2 to indicate that it is not encryption and is utterly insufficient.

206c212 < deployment, see (Section 5.2). TACACS+ TLS will therefore follow

deployment, see (Section 8). TACACS+ TLS will therefore follow 212c218 < though Section 5.2 should still be considered.

though Section 8 should still be considered. 214d219 < 3.2. TLS Connection 216,220d220 < A TACACS+ Client initiates a TLS connection by making a TCP < connection to a configured Server on the TACACS+ TLS well-known port < ([TBD]) (Section 3.1). Once the TCP connection is established, the < Client MUST immediately begin the TLS negotiation before sending any < TACACS+ protocol data. 224c224 < Dahm, et al. Expires 6 December 2023 [Page 4]

Dahm, et al. Expires 7 December 2023 [Page 4] 228a229,236 3.2. TLS Connection

A TACACS+ Client initiates a TLS connection by making a TCP connection to a configured Server on the TACACS+ TLS well-known port ([TBD]) (Section 3.1). Once the TCP connection is established, the Client MUST immediately begin the TLS negotiation before sending any TACACS+ protocol data.

267,271d274 < < Unless disabled by configuration, a Peer MUST disconnect a Peer that < offers an invalid TLS Certificate. < < 3.2.2.1. TLS Certificate Path Verification 273,274d275 < Implementations MUST support certificate Path verification as < described in [RFC5280]. 278a280 Dahm, et al. Expires 7 December 2023 [Page 5] 280,281d281 < Dahm, et al. Expires 6 December 2023 [Page 5] <

284a285,292

Unless disabled by configuration, a Peer MUST disconnect a Peer that offers an invalid TLS Certificate.

3.2.2.1. TLS Certificate Path Verification

Implementations MUST support certificate Path verification as described in [RFC5280].

320a329,340

Dahm, et al. Expires 7 December 2023 [Page 6]

Internet-Draft TACACS+ TLS 1.3 June 2023

334,340d353 < < < Dahm, et al. Expires 6 December 2023 [Page 6] <

< Internet-Draft TACACS+ TLS 1.3 June 2023 < < 347,348c360,361 < behavior corresponds to the behavior defined in RFC8907 Section 4.5. < Data Obfuscation [RFC8907] for TAC_PLUS_UNENCRYPTED_FLAG or key

behavior corresponds to that defined in RFC8907 Section 4.5. Data Obfuscation [RFC8907] for TAC_PLUS_UNENCRYPTED_FLAG or key 357,358d369 < 5.1. TLS < 363,365c374,376 < That role is to diligently follow current best practices for < maintaining the integrity of network devices and selection of TLS key < and encryption algorithms.

That role is to follow current best practices for maintaining the integrity of network devices and selection of TLS key and encryption algorithms. 367c378 < 5.1.1. TLS Use

5.1. TLS Options 369,375c380,386 < TLS encryption SHOULD be used in deployments when both the Clients < and Servers support it. Servers that support TLS encryption MAY be < configured to allow Unsecure Connections when TLS encryption is not < supported by the Client, but this is NOT RECOMMENDED because of the < threat of downgrade attacks, as described in Section 5.2. Unsecure < Connections would be better served by separate Servers from the TLS < Servers.

No single and timely TLS recommendations document exists. Therefore, implementers and operators SHOULD refer to TLS RFCs to ensure the versions are current and which algorithms should be supported, deprecated, obsoleted, or abandoned, in the absence of updates to this document. Useful examples are the TLS specifications themselves (TLS 1.3 [RFC8446]), which prescribes mandatory support in Section 9, and TLS Recommendations [RFC7525]. 377,379d387 < It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication < and encryption, including TLS using the NULL algorithm, except for < within test and debug environments. Also see [RFC3365]. 381d388 < 5.1.2. TLS 0-RTT 382a390,398

Dahm, et al. Expires 7 December 2023 [Page 7]

Internet-Draft TACACS+ TLS 1.3 June 2023

5.2. TLS 0-RTT

389a406 5.3. TLS PSK 391,398d407 < < Dahm, et al. Expires 6 December 2023 [Page 7] <

< Internet-Draft TACACS+ TLS 1.3 June 2023 < < < 5.1.3. TLS PSK < 407,415c416 < 5.1.4. TLS Options < < Unfortunately, no single and timely TLS recommendations document < exists. Therefore, implementers and operators SHOULD make use of the < various RFCs to determine which TLS versions and algorithms should be < supported, deprecated, obsoleted, or abandoned, in the absence of < updates to this document. Useful examples are the TLS specifications < themselves (TLS 1.3 [RFC8446]), which prescribes mandatory support in < Section 9, and TLS Recommendations [RFC7525].

  1. Operator Considerations 417c418,420 < 5.1.5. Unreachable Certificate Authority (CA)

    This section outlines considerations which are specific to operators. It is important that operators ensure their deployments address the considerations in Section 5. 419,424c422 < Operators SHOULD be cognizant of the potential of Server and/or < Client isolation from their Peer's CA by network failures. Isolation < from a public key certificate's CA will cause the verification of the < certificate to fail and thus TLS authentication of the Peer to fail. < Operators SHOULD consider loading certificate chains on devices and < servers to avoid this failure.

    6.1. TLS Use 426,428c424,428 < Certificate caching and Raw Public Keys [RFC7250] are other methods < to help address this, but both are out of scope for this document. < Certificate fingerprints are another option.

    TLS encryption SHOULD be used in deployments when both the Clients and Servers support it. In order to prevent downgrade attacks, Servers SHOULD keep separate and disjoint lists of clients supporting TLS and Unsecure Connections. Unsecure Connections would be better served by separate Servers from the TLS Servers. 430c430,432 < 5.1.6. TLS Server Name Indicator (SNI)

    It is NOT RECOMMENDED to deploy TACACS+ without TLS authentication and encryption, including TLS using the NULL algorithm, except for within test and debug environments. Also see [RFC3365]. 432,434c434 < Operators SHOULD be aware that the TLS SNI extension is part of the < TLS client hello, and is therefore subject to eavesdropping. Also < see [RFC6066], Section 11.1.

    6.2. Migration to TLS 436c436,438 < 5.2. Well-Known TCP/IP Port

    When Migrating from legacy service to TLS, any mixture of Unsecure Connected Servers and TLS-Protected Servers in the same redundant lists on clients SHOULD be minimised. 438,439c440,441 < A new port is considered appropriate and superior to a "STARTTLS" < command or other negotiation method because it allows:

    After migration, the production deployment SHOULD NOT mix Legacy and TLS-Protected Servers within Server lists configured on clients. 441,442d442 < * ease of blocking the unobfuscated or obfuscated connections by the < TCP/IP port number, 448c448 < Dahm, et al. Expires 6 December 2023 [Page 8]

    Dahm, et al. Expires 7 December 2023 [Page 8] 453,454c453 < * passive Intrusion Detection Systems (IDSs) monitoring the < unobfuscated to be unaffected by the introduction of TLS,

    6.3. Downgrade attacks in TLS 456,457c455,457 < * avoidance of Man in the Middle (MitM) attacks that can interfere < with STARTTLS,

    All clients and servers in a deployment should be configured with consistent algorithm and cypher options Section 5.1 to prevent harm from downgrade attacks. 459,479c459 < * and helps prevent the accidental exposure of sensitive information < due to misconfiguration. < < However, co-existence of inferior authentication and obfuscated, < whether an Unsecure Connection or deprecated parts that compose TLS, < also presents opportunity for down-grade attacks. Causing failure of < connections to the TLS-enabled service or the negotiation of shared < algorithm support are two such down-grade attacks. < < Servers and Clients could maintain a cache of Peers that have engaged < in TACACS+ TLS connections and demand TLS from that point forward. < However, this too has potential to be a Denial of Service (DoS) < vector, whereby an attacker causes a server to believe that a client < that does not support TLS has successfully connected with TLS. < < The simplest way to address exposure from Unsecure Connection methods < is to refuse Unsecure Connections at the server entirely, perhaps < using separate servers for Unsecure Connections and TLS. < < Another approach is mutual configuration that requires TLS. Clients < and Servers SHOULD support configuration that requires Peers,

    Clients and Servers SHOULD support configuration that requires Peers, 484c464 < 6. Operator Considerations

    6.4. Unreachable Certificate Authority (CA) 486,489c466,471 < Operational and deployment considerations are spread throughout the < document. While avoiding repetition, it is useful for the impatient < to direct particular attention to Section 5.2 and Section 5.1.5. < However, it is important that the entire Section 5 is observed.

    Operators SHOULD be cognizant of the potential of Server and/or Client isolation from their Peer's CA by network failures. Isolation from a public key certificate's CA will cause the verification of the certificate to fail and thus TLS authentication of the Peer to fail. Operators SHOULD consider loading certificate chains on devices and servers to avoid this failure. 490a473,482 Certificate caching and Raw Public Keys [RFC7250] are other methods to help address this, but both are out of scope for this document. Certificate fingerprints are another option.

6.5. TLS Server Name Indicator (SNI)

Operators SHOULD be aware that the TLS SNI extension is part of the TLS client hello, and is therefore subject to eavesdropping. Also see [RFC6066], Section 11.1.

500c492 < known port name. This allocation is justified in Section 5.2.

known port name. This allocation is justified in Section 8. 501a494,495 RFC EDITOR: this port number should replace "[TBD]" and the service name should replace "[TBDN]" within this document. 502a497

  1. Discussion on Separate port vs Negotiated TLS 504c499,500 < Dahm, et al. Expires 6 December 2023 [Page 9]

    The authors concluded that a new port is considered superior to negotiation of TLS using "STARTTLS" command because: 505a502,505

Dahm, et al. Expires 7 December 2023 [Page 9]

509,510c509,510 < RFC EDITOR: this port number should replace "[TBD]" and the service < name should replace "[TBDN]" within this document.

  • it allows easy blocking the unobfuscated or obfuscated connections by the TCP/IP port number, 512c512,514 < 8. Acknowledgments

  • passive Intrusion Detection Systems (IDSs) monitoring the unobfuscated deployments will be unaffected by the introduction of TLS, 513a516,523

  • Man in the Middle (MitM) attacks that can interfere with STARTTLS will be avoided

  • helps prevent the accidental exposure of sensitive information due to misconfiguration.

  1. Acknowledgments

519c529 < 9. Normative References

  1. Normative References 544a555,564

Dahm, et al. Expires 7 December 2023 [Page 10]

Internet-Draft TACACS+ TLS 1.3 June 2023

555,564d574 < < < < < < Dahm, et al. Expires 6 December 2023 [Page 10] <

< Internet-Draft TACACS+ TLS 1.3 June 2023 < < 576c586 < 10. Informative References

  1. Informative References 602a613,620

Dahm, et al. Expires 7 December 2023 [Page 11]

Internet-Draft TACACS+ TLS 1.3 June 2023

613,620d630 < < < < Dahm, et al. Expires 6 December 2023 [Page 11] <

< Internet-Draft TACACS+ TLS 1.3 June 2023 < < 662,672c672 < < < < < < < < < < < Dahm, et al. Expires 6 December 2023 [Page 12]

Dahm, et al. Expires 7 December 2023 [Page 12]